Closed tiborsimko closed 4 years ago
generally I think it would be useful if those commands had a --format json
option so that the output could be machine-processed e.g. with jq
We already have a --json
option :wink: but the output is not so rich... Basically like the text one.
So this issue is about nicely enhancing the output with more information and prettifying it.
Here's the current JSON output (with cut values):
$ reana-client logs -w roofit --json | jq -S | less
{
"engine_specific": null,
"job_logs": {
"09c02de8-85d6-48fb-b96e-bfffe8572304": "job: \n ...",
"3aad152f-c087-4fc3-ab0e-1c2ee5fb74ed": "job: \n \n",
"4923b0fa-217b-4f28-9f54-5a19a081d70c": "job: \n ...",
},
"workflow_logs": ""
}
awesome!
On Mon, Jan 13, 2020 at 6:04 PM Tibor Šimko notifications@github.com wrote:
We already have a --json option 😉 but the output is not so rich... Basically like the text one. So this issue is about nicely enhancing the output with more information and prettifying it.
Here's the current JSON output (with cut values):
$ reana-client logs -w roofit --json | jq -S | less { "engine_specific": null, "job_logs": { "09c02de8-85d6-48fb-b96e-bfffe8572304": "job: \n ...", "3aad152f-c087-4fc3-ab0e-1c2ee5fb74ed": "job: \n \n", "4923b0fa-217b-4f28-9f54-5a19a081d70c": "job: \n ...", }, "workflow_logs": "" }
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/reanahub/reana-client/issues/348?email_source=notifications&email_token=AARV6A3N2W6LQQNIAA36U2TQ5SNIXA5CNFSM4KGFKJ22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZPYSI#issuecomment-573766729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARV6A3JOPMOSOT7IZW4TRDQ5SNIXANCNFSM4KGFKJ2Q .
Closing once https://github.com/reanahub/reana-workflow-controller/pull/282 is merged :)
Motivation
It would be nice to enrich the output of
reana-client logs
so that the logs would include important information of interest to the user, such as command to run and the execution environment, so that the user won't have to do it separately. Basically thelogs
command could gather this information from the workflow runtime execution context and then aggregate it for the end user into a rich log output.Current behaviour
Currently, the logs for the RooFit example show:
This prints internal job ID (that is useful for debugging, but mostly for developers only) and the output of commands (that is useful for users, but it does not show which command run and where).
Expected behaviour
Since the workflow definition in richer, it would be good to see which command run, in which compute environment, right with the logs, something like:
Basically, the REST API returning workflow run logs would enrich the current job-oriented reply with whatever can be gathered from the workflow engine execution runtime context.
(just an idea for illustration; the output format is subject to change)
Complexity
Beware of the JSON output mode. It would be good if this is nicely processable too by various clients. (including UI later)
Serial is different than CWL is different than Yadage, but some commonalities exist. We can define a nice common denominator and start with Serial.
See also engine-specific progress logs and friends. This issue is not about nice live streaming of progress, but about richer exposure of logs of what wealready have logged on the system. But it does not hurt to keep an eye on a future live log streaming, e.g. in a
--follow
kind of way.Future outlook
This could lead to a future rich search syntax to extract only parts of log, such as:
Also, if we have inputs/outputs for Serial one day, the output could show full path to output files generated by each step:
Listing these future outlook thoughs here for the sake of a broad overview of where this might be going; the follow-ups will be separate issues once we have the basic functionality nailed down.