tiborsimko on maint-0.7
docs: readme badge typo requirements: remove legacy sql… requirements: update dependenci… (compare)
dependabot[bot] on pip
Another trick that I'm using is sharing /var/reana
with host. I.e. you can create empty /var/reana
on your host, and use:
reana-dev cluster-delete
reana-dev run-ci -m /var/reana:/var/reana --exclude-components=r-ui,r-a-vomsproxy -c r-d-helloworld
In this way Kind will host-mount /var/reana
to the cluster, so there will be less demands on Docker volume disk space, and you'll be able to access /var/reana/... workspaces comfortably from within your host.
reana-dev cluster-delete
enough?
Hi. I'm trying to set up a mini REANA cluster on CERN Openstack following this tutorial: https://reana-cluster.readthedocs.io/en/latest/gettingstarted.html
Other than a few minor things, I managed to get right down to the last command before encountering an error:
$ reana-cluster -f reana-cluster-CERN.yaml init
Error: Couldn't load repositories file (/afs/cern.ch/user/a/admorris/.helm/repository/repositories.yaml).
You might need to run `helm init` (or `helm init --client-only` if tiller is already installed)
[ERROR] Traefik initialization failed
Command '['helm', 'repo', 'add', 'stable', 'https://kubernetes-charts.storage.googleapis.com/']' returned non-zero exit status 1..
[ERROR] Command '['helm', 'repo', 'add', 'stable', 'https://kubernetes-charts.storage.googleapis.com/']' returned non-zero exit status 1.
I documented what I did, and the output, as I went along:
https://codimd.web.cern.ch/7jlGFHh1Sh6vKmG7NGsPTg/
helm init
and waited a while. Now I have (without the traceback):$ reana-cluster -f reana-cluster-CERN.yaml init
Error: This command needs 1 argument: chart name
[ERROR] Traefik initialization failed
Command '['helm', 'install', 'reana-traefik', 'stable/traefik', '--namespace', 'kube-system', '--values', '/afs/cern.ch/work/a/admorris/reana/reana/lib/python3.6/site-packages/reana_cluster/configurations/helm/traefik/minikube.yaml']' returned non-zero exit status 1..
[ERROR] Command '['helm', 'install', 'reana-traefik', 'stable/traefik', '--namespace', 'kube-system', '--values', '/afs/cern.ch/work/a/admorris/reana/reana/lib/python3.6/site-packages/reana_cluster/configurations/helm/traefik/minikube.yaml']' returned non-zero exit status 1.
This is where I am with the NFS provisioner: https://codimd.web.cern.ch/s/ryXsju3gw#NFS-share
I feel like I'm missing something. When I describe
pods, the one called db
is in a crash loop, and both the NFS provisioner and REANA server
pod have warnings about pod has unbound immediate PersistentVolumeClaims
ok, I'm stuck. Could someone check that CodiMD link ^ and tell me where I've gone wrong?
I have an OpenStack volume connected to a PersistentVolume
. The NFS provisioner is running and the PersistentVolumeClaim
created by REANA is attached successfully.
The db
pod is still in a crash loop, while the server
and workflow-controller
pods are stuck in ContainerCreating
reana.cern.ch
instance? There is a possibility to access restricted resources via keytab if you wish, we have some ATLAS and CMS examples. We could perhaps talk in CERN's REANA Mattermost channel about your particular use case? (2) Concerning supporting EOS, it is currently necessary to have some Ceph/NFS shared storage for cluster nodes indeed. One can do stage-in/stage-out of data from/to EOS already, but this is not practical to do for all the workflow steps... We are planning to look into a possibility of running user workflows directly on the user EOS workspace; that might perhaps be of interest?
flask user-create
) as needed. Does user-create
allow the assignment of a web-ui password? Also, is there a way for users to change their password via the web interface?
reanahub/reana-job-controller
image (working only with Kubernetes) by the one that contains CERN HPC/HTC support. IOW, one would basically use the same Helm deployment recipe, only change the image. WRT adding support for the NYU cluster, it should be possible by sub-classing the abstract job controller class and overriding methods to use NYU specifics instead of CERN specifics, see Figure 2 in the cited PDF mini-paper. This was done successfully by the SCAILFIN@NotreDame team for the VC3, so I guess the abstraction of the design is tested to be relatively CERN-agnostic already. If you also use Kerberos kinit for NYU Slurm, it should not be that difficult an adaptation I guess... Perhaps just to replace the name of the head node etc... We could take this as an occasion to better parametrise Slurm backend
@mdehollander Hi and sorry for the late reply! We've been in touch with RENKU in the past, exactly around the idea of running CWL workflows produced by RENKU on the REANA backend... but we haven't pursued the discussions lately. REANA focuses mostly on running the batch workflows, so the support for running interactive notebooks is a bit "secondary" there. The current aim is basically to allow people to open a notebook alongside running batch workflow for some quick explorations of intermediate data on the workflow's workspace. Kind of getting a remote shell on the workspace, if you will... That said, it might be interesting to bridge the notebook world and the workflow world better, e.g. to allow dispatching REANA workflows directly from the notebook, for those users who use notebooks as the main entry interface. We plan to enrich web interface with some R/W features in 2021, so we could perhaps revive this topic soon!
Thanks for the update @tiborsimko
is there a way to disable the sign-up functionality on the web interface?
@hollowec We have just released REANA 0.7.2 which has a deployment option to disable the sign-up functionality. Please see https://blog.reana.io/posts/2021/reana-0.7.2/
detailed procedure to change the configuration to configure other Compute Backends using other HTCondor environments
Hello @jordidem. To have your own HTCondor support you would have to subclass the JobManager
class, you can find a detailed explanation on how it works in this paper http://cds.cern.ch/record/2696223/files/CERN-IT-2019-004.pdf. Probably there will be many commonalities with the CERN implementation, in that case, we could have a look at it and perhaps create a superclass with the common code?
Do we need to install HTCondor packages and daemons to convert our reana on a submit machine?
Yes, that is the other part that needs extension. As an example, at CERN we build REANA Job Controller with the htcondorcern
build alrgument and that includes the necessary packages to submit jobs to CERN HTCondor, in your case you would have to add the instructions to install the packages you need.