[nfs-cluster-clients : Create mountable directory] FAILED!

[stephane54]

hi,

We are installing openminted the full stack (swarm mode) and Logs indicated a problem during the creation on mountable directory {"msg": "The task includes an option with an undefined variable.} Can you tell us more about thoses variables : location where the variables are set , supposed value ...

More informations in this attached file : omtd_full_stack_deploy06-11.txt

In addition, it would be great to have the size of each nfs mount point.

And finally, a diagram offering a simple view of the technical architecture could help us

Thanks

[saxtouri]

Hi,

Looks like the importand error message in your feedback is : 'list object' has no attribute 'data_share'.

The data_share variable helps connect the execution VMs with the Galaxy executor VM through NFS. It was supposed to have been set by ansible (site.yml:26). I susspect it has to do with the order of execution.

Here is what you can try:

• open site.yml with an editor. You can see it consists of blocks of yaml code, its block starting with - hosts: <some host variable>.
• swap the cluster_nodes (lines 22 to 32) block with the executor block (lines 34 to 40). Plese, make sure you swap the whole blocks, not just the first line.

Let us know how it went.

[galanisd]

Hi,

We are installing openminted the full stack (swarm mode)

Swarm is the cluster in which the Registry part of the whole infra is deployed (Registry, Storage Service, Content Service etc). I think (not 100% sure) that Swarm is always used; there is no option for installing Registry in a different way (e.g. without Swarm).

The https://github.com/openminted/omtd-stack-setup.git that you have used installs the full workflow execution backend stack; e.g. Mesos nodes, Mesos master nfs clients etc. I had issues installing this version (as you do). However a limited worfklows execution backend is also available. The standalone setup (https://github.com/openminted/omtd-standalone-setup) is much easier and just installs Galaxies (executor, editor).

@rbossy I thought that all participants were interested in the standalone setup.

And finally, a diagram offering a simple view of the technical architecture could help us

More info on the architecture of OpenMinTeD infra can be found in the respective deliverables. http://openminted.eu/wp-content/uploads/2018/06/D6.3-PlatformArchitecturalSpecification-v2.0.pdf http://openminted.eu/wp-content/uploads/2016/12/OpenMinTeD_D6.8-Platform-services-distribution-specification-v.1.0.pdf

For example in D6.8 (section 2.4.1 - "General overview") you will find a diagram that presents an overview of the architecture.

[rbossy]

@rbossy I thought that all participants were interested in the standalone setup.

That's what I though. Apparently @stephane54 has finished the standalone but is suck with the deployment of the registry.

[galanisd]

Nope. From the log file that he sent it seems that he is trying to install the mesos-based worfklows execution backend.

[Sy-Po]

hi, my name is Sylvain and i work with Stephane. i did swap the cluster_nodes (lines 22 to 32) block with the executor block (lines 34 to 40) and ran into another error. I managed the new error moving the line "- geerlingguy.apache" before "- role: executor" line in the executor block (site.yaml) Now i got this one : TASK [executor : Install extra packages in virtualenv] **** [DEPRECATION WARNING]: Invoking "pip" only once while using a loop via squash_actions is deprecated. Instead of using a loop to supply multiple items and specifying name: {{ item }}, please use name: [u'watchdog', u'chronos-python'] and remove the loop. This feature will be removed in version 2.11. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. failed: [192.168.128.220] (item=[u'watchdog', u'chronos-python']) => {"changed": false, "item": ["watchdog", "chronos-python"], "msg": "No setuptools found in remote host, please install it first."}

[rbossy]

@galanisd Nope. From the log file that he sent it seems that he is trying to install the mesos-based worfklows execution backend.

Apparently they successfully installed the standalone setup. But when they started installing the registry, it seems that the procedure references elements requires a full-stack setup. The registry install procedure is apparently redundant with the full-stack setup...

Pingback: @stephane54 @Sy-Po

Maybe of interest to: @antleb @Jodee90

[saxtouri]

@rbossy Yes, the registry install procedure, as well as about half of the workflow setup procedure is "redundant" in the sense that it is required in both installation options.

[galanisd]

My guess is that they are still trying this one (https://github.com/openminted/omtd-stack-setup/) which is the second option (full blown installation) in https://github.com/openminted/install-tutorial#workflow-execution .... however I might miss something. @stephane54 @Sy-Po ?

[Sy-Po]

@saxtouri We first installed the standalone : https://github.com/openminted/omtd-standalone-setup on ONE vm (http /executor & /editor seems OK) + we tried to install the registry on another VM and failed at the nfs.yml script,

I didn't understand why in the registry install there was nfs and swarm as its standalone. Are these components (nfs & swarm, etc) part of the standalone + registry setup ?

@galanisd
Actually, and my previous posts are related to this case, we are installing the full blow/stack whatever, on 10 (other) VMs (5 working nodes setup)

[galanisd]

We first installed the standalone : https://github.com/openminted/omtd-standalone-setup on ONE vm (http /executor & /editor seems OK) + we tried to install the registry on another VM and failed at the nfs.yml script,

I didn't understand why in the registry install there was nfs and swarm as its standalone. Are these components (nfs & swarm, etc) part of the standalone + registry setup ?

If the first two steps of https://github.com/openminted/install-tutorial#installation-steps were successful ("Workflow execution", "Configure Workflow execution") and you have a problem in the third one (https://github.com/openminted/install-tutorial#registry) then @Jodee90 is the right person to ask.

Actually, and my previous posts are related to this case, we are installing the full blow/stack whatever, on 10 (other) VMs (5 working nodes setup)

The logs that you sent were for this scenario. It was not clear that you were also installing standalone execution.

---

• In both scenarios (standalone, full stack) NFS is used for the communication between Registry and the Galaxies. I.e. Registry generates a Galaxy XML wrapper file for each registered Text and Data Mining component and puts it at the Galaxy server(s) via NFS.

• In the full stack scenario NFS is also used for transferring files beetween the Galaxy executor and the Mesos slaves.

• As far as I know and as already said Swarm is the cluster that Registry uses for installing/managing several services; Registry, Storage Service, Content Service. @Jodee90 & @antleb can provide more info on this.