mvidalgarcia on maint-0.7
helm: expose user_confirmation … (compare)
diegodelemos on maint-0.7
helm: control ui signup form vi… (compare)
yay -S kind-binon Arch Linux and you are ready to go. In order to have the very latest bleeding-edge REANA cluster, you can proceed in a CI style as follows: (note that it may take up to half an hour to build everything from scratch the first time)
# create Python virtual environment mkvirtualenv reana # clone reana sources cdvirtualenv && mkdir src && cd src git clone -b kind --depth 1 https://github.com/reanahub/reana cd reana # install reana-dev helper script pip install . # clone the other necessary REANA sources reana-dev git-clone -u anonymous -c CLUSTER -c CLIENT -c r-d-helloworld # deploy REANA cluster and run hello world example reana-dev run-ci --exclude-components=r-ui,r-a-vomsproxy -c r-d-helloworld
eval $(reana-dev client-setup-environment)and use
reana-client run -w myanalysison your analyses, as with Minikube. (note the slight syntax change: "reana-dev client-setup-environment")
reana-dev run-ci…is creating it, I see
@tiborsimko the error:
[2020-07-10T20:38:10] reana: kind load docker-image kozea/wdb:3.2.5 Image: "kozea/wdb:3.2.5" with ID "sha256:8e49b70c16baa5f079863ae94d732a6aa0ab5f103ef72d0db050b5a0e6c3de77" not yet present on node "kind-control-plane", loading... ERROR: failed to load image: command "docker exec --privileged -i kind-control-plane ctr --namespace=k8s.io images import -" failed with error: exit status 1 Command Output: unpacking docker.io/kozea/wdb:3.2.5 (sha256:eae1d26ddf8624a951e1444f462ef0b0a3ca078dda987257a40f9528691cb24f)...time="2020-07-10T17:39:00Z" level=info msg="apply failure, attempting cleanup" error="failed to extract layer sha256:fa0c3f992cbd10a0569ed212414b50f1c35d97521f7e4a9e55a9abcf47ca77e2: write /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/64/fs/usr/lib/python2.7/collections.py: no space left on device: unknown" key="extract-102132277-rjAc sha256:2d9c829ae3f7ff3e148e5c7c3a1cf378b0f90b79035e2fe9a8d78c63ccde4c89" time="2020-07-10T17:39:00Z" level=warning msg="extraction snapshot removal failed" error="write /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db: no space left on device: unknown" key="extract-102132277-rjAc sha256:2d9c829ae3f7ff3e148e5c7c3a1cf378b0f90b79035e2fe9a8d78c63ccde4c89" ctr: failed to extract layer sha256:fa0c3f992cbd10a0569ed212414b50f1c35d97521f7e4a9e55a9abcf47ca77e2: write /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/64/fs/usr/lib/python2.7/collections.py: no space left on device: unknown [2020-07-10T20:38:10] reana: Command 'kind load docker-image kozea/wdb:3.2.5' returned non-zero exit status 1. [2020-07-10T20:37:54] reana: Command 'reana-dev kind-load-docker-image -c reana' returned non-zero exit status 1. [2020-07-10T20:34:05] reana: Command 'reana-dev cluster-create' returned non-zero exit status 1.
there is plenty of RAM and SSD space on my machine
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.
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:
helm initand 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.
db pod is still in a crash loop, while the
workflow-controller pods are stuck in
reana.cern.chinstance? 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-createallow 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-controllerimage (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