./elasticluster.sh setup NAME PATH/TO/PLAYBOOK

[Tomasz Skowron]

Hi,

I am in the process of developing application specific playbook to further customise deployed cluster manually.

According to the example playbook, below should be sufficient to run:

# This playbook should be run *after* ElastiCluster has set up the
# cluster, for instance using::
#
#         elasticluster setup mycluster -- /path/to/this/playbook.yml

however an example dummy playbook fails to run. Part of the verbose output below.

2021-03-17 18:16:45 2711fe1b9a20 elasticluster[1] DEBUG Running Ansible command `ansible-playbook --private-key=/home/tuhuhuh/.ssh/id_rsa /home/elasticluster/share/playbooks/main.yml --inventory=/home/tuhuhuh/.elasticluster/storage/slurm-clean.inventory --become --become-user=root -vv /home/elasticluster/share/playbooks/customisations/debug.yml -e @extra_vars.yml` ...
usage: ansible-playbook [-h] [--version] [-v] [-k]
                        [--private-key PRIVATE_KEY_FILE] [-u REMOTE_USER]
                        [-c CONNECTION] [-T TIMEOUT]
                        [--ssh-common-args SSH_COMMON_ARGS]

....

 2021-03-17 18:16:45 2711fe1b9a20 elasticluster[1] ERROR Command `ansible-playbook --private-key=/home/tuhuhuh/.ssh/id_rsa /home/elasticluster/share/playbooks/main.yml --inventory=/home/tuhuhuh/.elasticluster/storage/slurm-clean.inventory --become --become-user=root -vv /home/elasticluster/share/playbooks/customisations/debug.yml -e @extra_vars.yml` failed with exit code 2.

setup command succeeds to redeploy if no custom playbook is specified.

debug.yml contains:

- name: Mount volume on head node
  tags:
    - after
    - local
  # change this with `gridengine_master` if you're using GridEngine
  # instead of SLURM
  hosts: slurm_master

  vars:
    # mount point for the filesystem
    mountpoint: '/data'
    - name: Ensure mountpoint directory exists
      file:
        dest: '{{ mountpoint }}'
        state: directory

am I missing anything important here?

[Tomasz Skowron]

---
# This is a post deployment playbook to be run if needed to confugire deployed cluster further.

#
#         elasticluster setup mycluster -- /path/to/this/playbook.yml

- name: Mount volume on head node
  tags:
    - after
    - local
  # change this with `gridengine_master` if you're using GridEngine
  # instead of SLURM

  hosts: slurm_master, slurm_worker

  vars:
    # mount point for the filesystem
    mountpoint: '/data'

  tasks:

    - name: Ensure mountpoint directory exists
      file:
        dest: '{{ mountpoint }}'
        state: directory

Additionally, I am able to run the task independently of the elasticluster environment:

ansible-playbook --private-key=/home/tuhuhuh/.ssh/id_rsa elasticluster/share/playbooks/customisations/debug.yml --inventory=/home/tuhuhuh/.elasticluster/storage/slurm-clean.inventory --become --become-user=root

Would the error be related to the fact that both main.yml and custom playbooks are passed through in the elasticluster triggered run?

[Riccardo Murri]

Hello Tomasz,

I think the issue is that elasticluster.sh runs ElastiCluster in a
Docker container, which has no access to the host filesystem (where
your additional playbook is located) -- that also explains why you get
the same error regardless of whether the file exists or not. A
similar issue exists if you try to run `./elasticluster.sh sftp`.

At the moment, additional playbooks will only work if you install from sources.

As for the future, I can see a couple of options:

1. Designate a special directory in the filesystems where additional
playbooks should be located (e.g., `$HOME/.elasticluster/playbooks`),
which could be automatically made visible to the Docker container by
`./elasticluster.sh`. Doing so wouldn't fix the issue with SFTP
though.

2. Make the entire host filesystem available in the Docker container
under a special directory `/host`. Doing so would make all files
available, but the paths would need to change (you have to prefix them
with `/host`) which I think would be counter-intuitive to most people.

3. Scan command-line arguments: those that match existing file names
are made available to the Docker container ad-hoc. Doing so would be
mostly transparent but brittle: if a playbook tries to copy a file,
that file won't be found (because it's not mentioned on the command
line, only the playbook is) leading to a puzzling error.

Any comments or thoughts? Solution 1. is the easiest to implement so I
would probably go with that, but please chime in if you have other
ideas or suggestions.

The problem is effectively unsolvable, in that Docker *wants* to
isolate container filesystems. Perhaps Snap or Flatpak could be
better positioned for this use case but I don't know them nearly as
well and I'm not sure how good is their support across different Linux
distributions.

Ciao,
R

[Alex Loew]

I think version 1 could be smart. Or has any one requirements to pass on more stuff into the docker container?

Kind regards

Alex

--
You received this message because you are subscribed to the Google Groups "elasticluster" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticluste...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticluster/CAJGE3zXkS%3DX8e19M1wFf42fzvadXcHg9FNGvizJKKx2e%3DPw%3DPw%40mail.gmail.com.