Open jlemesh opened 3 days ago
Actually a new command could create confusion to the users by offering another choice. I think it's better to be clear towards users interface-wise, i.e. offering one logs
command, and deal with any hidden implementation complexity (checking optional flag compatibility) on our end.
This would offer logs --follow
which is similar to what people might be used to from tail -f
, kubectl logs -f
, etc. That was one of our design motives for ls
, rm
etc.
So I'd say let's rather implement reana-client logs -f
and our function would deal with checking options internally, reporting that -f
is not compatible with -x
or some other option, as needed.
For example, regarding --step
, we already have logs --filter step=gendata
, so we could simply use that. And if people would like to follow and don't provide step, we can explain that this option is mandatory. (Until we implement later down the line some intelligent follow that would analyse current job, follow it, and when it finishes, follow another.... Even though that could leave some jobs out when many concurrent jobs are running, such a default follow might be already useful to some people with low job concurrency, and would work perfectly for mostly linear workflows. But that's something for later.)
reana-client logs
command currently displays all available logs, with an option to use pagination (which seems to not work?). To retrieve newest logs, user would need to run the command multiple times. If all logs are returned at once, and with running the command multiple times, there would be a lot of duplicated command line output.Create new command
reana-client follow-logs
that would continuously poll for new logs and append new data to the existing output, i. e. similar totail -f
. It would follow only one workflow or one job, not both and not multiple.I think it's better to create new command instead of reusing
reana-client logs
because both commands would have different flags except for-w
(there would be confusion regarding which flags affect which behavior), and code would look more complicated.Implementation: essentially just create a
while True
loop that requests logs data (either workflow or job), calculates a diff between previous and new logs and prints the diff. If workflow or job status becomesfinished
,failed
, etc., stop the polling and exit. Otherwise sleep for--interval
seconds and repeat.Will need to implement for both Python and Go.