cli: show workspace retention rules to the users

[VMois]

According to our plans in #617, the MVP version of the workspace retention rules feature for reana-client is completed. We have create and validation parts finished.

As noted by @mdonadoni, there is no way to see retention rules using CLI. You can only use the web page. It would be beneficial to allow the same for CLI.

We can display retention rules alongside files in ls or du commands as described in #617, but it might be complicated. The simpler version can be a new command that lists retention rules for a specific workflow like this:

$ reana-client retention-rules-show
RULE    DAYS   APPLY_ON 
**/*    365    <date>

Whatever approach we choose is something to decide on, but it would be good to have some way of displaying retention rules in CLI.

[VMois]

Some observations regarding the "showing rules alongside ls/du command". The files listing is implemented in r-workflow-controller, but a lot of logic regarding workspace retention rules is contained in r-server.

[tiborsimko]

I think we have basically three-four options here:

(1) If a user would like to consult the retention rules for a given workflow, the first and easiest instinct would be to read them from reana.yaml. (This can be done easily locally by the user, but for already-run remote workflows, and for sites who may decide on various local configurations, it would not be enough to consult only reana.yaml. This will be part of later options in this list.) Still, one issue here is that we don't publish reana.yaml to remote workspace by default, and so it may be "harder" for user to read this info, as user would need to get the JSON specs. (Possible over Web UI, hard over CLI.) Personally I have been advising users to always include reana.yaml in their inputs.files clause, so that REANA specs can be directly seen in the workspace, both on Web and CLI, downloaded, etc. Plus it helps admins to debug possible mishaps on the cluster-side. So, as a first mini project, I think it would be useful to modify reana-client to always upload reana.yaml by default, even if user did not specify it in their input.files directive. (This could be done as a prelude to reanahub/reana-db#162).

(2) The above facet won't help users who would like to know the site-wide defaults configured by the admins. Here I would suggest to modify reana-client info to include as much user-oriented public information as possible. Currently, the only useful information there is the list of supported computing backends. I think we should show there the default memory limit, the default retention period, etc. Every public information that is user-oriented and that helps people to know the context under which their workflows will be run. (Perhaps even number of nodes, since we expose it in the cluster health web page anyway.)

(3) If we go into implementing a new command, such as reana-client retention-period-show -w myanalysis.42 proposed above, then this would make sense essentially when we shall accompany it with other useful CLI commands, such as retention-period-extend to ask for extending retention period a posteriori. However, this would go clearly beyond the scope of this sprint. So I think a new CLI command of this kind can wait, if we only display retention rules, because they could be read from reana.yaml as suggested in 1 and 2 above. So I would rather advocate to wait with 3 and rather think about the next option 4.

(4) The most interesting to the users would be the direct information in the file listing next to each concrete file, such as:

$ reana-client ls -w myanalysis.42
NAME                                       SIZE      LAST-MODIFIED          RETAINED-UNTIL
merge/merged.root                          14471     2022-06-14T11:54:03    2022-06-29T00:00:01
hepdata/data1.yaml                         8141      2022-06-14T11:55:38    2023-06-15T00:00:01
hepdata/submission.zip                     3003      2022-06-14T11:55:38    2023-06-15T00:00:01
hepdata/submission.yaml                    696       2022-06-14T11:55:38    2023-06-15T00:00:01

This would allow for easy filtering options to detect files which are first to expire, etc. This functionality should be optional, because it may be very slow to compute retention deadline for each file in the workspace, if the workspace contains many hundreds or thousands of files. Note that if we go this way, we should do it on the server-side, so that we can reuse the cronjob logic, and so that both the Python client and the Go client can remain "thin" and only show, sort and filter the information coming from the server.

[tiborsimko]

Note: This won't be implemented during the initial Workspace-Retention sprint, but we may get to this soon when enriching other file attributes, such as exposing regular files vs links.