cephfs: make ceph details (monitors, mounts, user, secret-name) confugurable

[lukasheinrich]

To make REANA deployable at other site, details of the shared data mount for jobs need to be configurable. Probably a configuration file attached as a secret + a env var specifying that file is best.

[tiborsimko]

Do you mean to deploy only reana-job-controller component alone, or deploy the whole REANA ecosystem at another site?

If the latter case, we should rather muse about this in the REANA umbrella repository. E.g. in the longer term we'd aim for something like pip install reana[k8s,yadage,airflow] which will install all the necessary components for the given deployment scenario the use has in mind. Sharing configuration amongst REANA components would be easier in that way, indeed via configuration files and environment variables and friends.

[lukasheinrich]

no for now I want to deploy the entire REANA ecosystem on my own cluster that is

1. a kubernetes cluster based on openstack magnum
2. has a CephFS share (with its own credentials, i.e. username and auth key) based on OpenStack Manila

this is probably a setup that people will have on which to deploy the REANA infrastructure. Possibly it could be even more generalized to any kind of storage:

1. just one host directory in case all pods live on the same host
2. various shared volume drivers that kubernetes suppots
   • Ceph
   • EOS
   • Google Persistent Disk

Kubernetes already factors out the notion of a volume nicely. This issue was about carrying this factorization into REANA as well.

[tiborsimko]

Good, so this issue should really go to the REANA umbrella repository rather than here. @diegodelemos started to work on parametrisable Kubernetes resources reanahub/reana-resources-k8s#18 but this is a work-in-progress still. The volume sharing would go naturally together....

[lukasheinrich]

ok so should this be merged with #18 The scope is a bit larger because beyond generating k8s manifests this also requires some code changes to the actual services.