After https://github.com/reanahub/reana/issues/532, the administrators will be able to choose which locally mounted volumes are OK to be used for workflow workspace storage, for example /var/reana/, /mybigextenaldisk/myworkflows, or /eos/home.
The goal of this issue is to extend validation to say whether a particular workspace value is allowed or not. For example, if a user would like to use /usr/share/, the reana-client command should report that this is not allowed, and the validation should fail.
Note that one REANA instance can allow one set of workspace prefixes, whilst another REANA instance can allow another set of workspace prefixes. Hence the list of allowed ones are not static, but depend on the given REANA cluster instance that the REANA client talks to. This means that we may need a new REST API on the REANA server side so that client can interrogate the given cluster instance in order to discover which values are allowed and which are not. The new REST API endpoint can simple return list of allowed values for workspaces. We could (Alternatively, the workspace validation request could be dispatched to the server-side.)
After https://github.com/reanahub/reana/issues/532, the administrators will be able to choose which locally mounted volumes are OK to be used for workflow workspace storage, for example
/var/reana/,/mybigextenaldisk/myworkflows, or/eos/home.After https://github.com/reanahub/reana-client/issues/545, the users will be able to select which workspace they would like to run a particular workflow on, for example
mybigextenaldisk/myworkflows.The goal of this issue is to extend validation to say whether a particular workspace value is allowed or not. For example, if a user would like to use
/usr/share/, thereana-clientcommand should report that this is not allowed, and the validation should fail.Note that one REANA instance can allow one set of workspace prefixes, whilst another REANA instance can allow another set of workspace prefixes. Hence the list of allowed ones are not static, but depend on the given REANA cluster instance that the REANA client talks to. This means that we may need a new REST API on the REANA server side so that client can interrogate the given cluster instance in order to discover which values are allowed and which are not. The new REST API endpoint can simple return list of allowed values for workspaces. We could (Alternatively, the workspace validation request could be dispatched to the server-side.)