Add support for RHEL systems

[espenfl]

Added support for RHEL systems which required some minor modifications.

Would it be possible to get rid of the current_user extension or does it cover some scenarios that I fail to see?

I also replaced the $HOME for ansible_env.HOME etc. Not sure if you guys agree, if not, happy to put it back again.

[ltalirz]

Hi @espenfl , thanks a lot for this contribution!

Would it be possible to get rid of the current_user extension or does it cover some scenarios that I fail to see? I also replaced the $HOME for ansible_env.HOME etc. Not sure if you guys agree, if not, happy to put it back again.

The reason for both of these was the following: When running the playbook for Quantum Mobile to create the Virtualbox image, it is much more convenient to run the whole playbook using the already existing vagrant user. For most roles this is fine, since they mainly install things system-wide.

The AiiDA role is a bit special, since AiiDA should be installed for a particular user. So, the AiiDA role is run as follows:

    - role: marvel-nccr.aiida
      tags: aiida
      become: true
      become_user: "{{ vm_user }}"
      vars:
         ...

where {{ vm_user }} is "max". The problem: ansible_env.HOME inside the AiiDA role will still point to the home of the vagrant user, not to the home of the max.

It used to be a limitation of ansible that you could not determine the {{ vm_user }} using built-in variables (thus these workarounds with current_user / $HOME) but before you change everything back, I'll have a quick look whether this issue has been resolved now.

[ltalirz]

In the meanwhile, would you mind fixing the linter issues reported by the travis build?

The previous build was failing, but only at the stage of the idempotence check - some aiida plugins had differing dependencies, so this would have been very difficult to fix. Now that we have the "clean" option, you could set it to true and the build should run through.

[ltalirz]

I've looked back into the "current user" issue now - TLDR: the issue is still there.

• original reason for creating the current_user role
• the [unresolved ansible issue]() describing this (which has been closed, and even limited comments to contributors...)
• some workaround posted on Stackoverflow

Output of different solutions suggested on SO:

- name: test lookup
  debug:
    var: "lookup('env','HOME')"

- name: test ansible_env
  debug:
    var: "ansible_env.HOME"

- getent:
    database: passwd
    key: "{{ vm_user }}"
    split: ":"

- name: test getent
  debug:
    msg: "{{ getent_passwd[vm_user][4] }}"

- user:
    name: "{{ vm_user }}"
    state: present
  register: current_user

- name: test ansible user module
  debug:
    msg: "{{ current_user['home'] }}"

Which prints

$ ansible-playbook user.yml

PLAY [set up the VM] ******************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [default]

TASK [import global variables] ********************************************************
ok: [default]

TASK [test : test lookup] *************************************************************
ok: [default] =>
  lookup('env','HOME'): /Users/leopold

TASK [test : test ansible_env] ********************************************************
ok: [default] =>
  ansible_env.HOME: /home/vagrant

TASK [test : getent] ******************************************************************
ok: [default]

TASK [test : test getent] *************************************************************
ok: [default] =>
  msg: /home/max

TASK [test : user] ********************************************************************
ok: [default]

TASK [test : test ansible user module] ************************************************
ok: [default] =>
  msg: /home/max

PLAY RECAP ****************************************************************************
default                    : ok=8    changed=0    unreachable=0    failed=0

I do like the approach via the ansible user module - i.e. you could replace the dependency on the current_user role with the more compact:

- user:
    name: "{{ vm_user }}"
    state: present
  register: current_user

# now use
# "{{ current_user['name'] }}"
# "{{ current_user['home'] }}"

However, this cannot be used in role defaults.yml, which is why we'll still need to live with ${HOME} there (@espenfl unless you have a better suggestion, of course!)

[espenfl]

The reason for both of these was the following: When running the playbook for Quantum Mobile to create the Virtualbox image, it is much more convenient to run the whole playbook using the already existing vagrant user. For most roles this is fine, since they mainly install things system-wide.

@ltalirz do you here mean running Ansible from the host or on the guest using the Vagrant setup?

[espenfl]

The reason for both of these was the following: When running the playbook for Quantum Mobile to create the Virtualbox image, it is much more convenient to run the whole playbook using the already existing vagrant user. For most roles this is fine, since they mainly install things system-wide.

@ltalirz do you here mean running Ansible from the host or on the guest (both using the Vagrant setup)?

[ltalirz]

For Quantum Mobile we run ansible from the host.

Since Vagrant already sets up an SSH key for the vagrant user, everything is provisioned through the vagrant user, while we become_user: "{{ vm_user}}" for provisioning AiiDA.

[espenfl]

I am certainly not very familiar with Vagrant. Any reason except not installing ansible on the guest why we would not run ansible-local? And if we can/want to do this, am I right that the user issue would then not be present? We would then just have whatever users we create using Vagrant, i.e. root and max.

[ltalirz]

Any reason except not installing ansible on the guest why we would not run ansible-local?

While one can use ansible to provision the host it is running on (and can make sense e.g. to create docker images etc.), it is not the default way of using ansible. E.g. if you want to provision more than one server using the same playbook and you have to ssh into each server individually to provision it, that becomes tedious.

I had a quick look at the CI and noticed that the test now exits with success directly at the start of the role (where it detects that it is running on python 2.7). Could you please fix this before I do the review? https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/636227349#L523

[espenfl]

Any reason except not installing ansible on the guest why we would not run ansible-local?

While one can use ansible to provision the host it is running on (and can make sense e.g. to create docker images etc.), it is not the default way of using ansible. E.g. if you want to provision more than one server using the same playbook and you have to ssh into each server individually to provision it, that becomes tedious.

I had a quick look at the CI and noticed that the test now exits with success directly at the start of the role (where it detects that it is running on python 2.7). Could you please fix this before I do the review? https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/636227349#L523

Sure, but with this: https://www.vagrantup.com/docs/provisioning/ansible_local.html I think you could easily batch as you would if you did it on the host? Maybe not. Never tried it myself.

[ltalirz]

By the way, I'm trying to switch to a different docker image, which will easily enable us to add debian, centos etc. (preparing a PR)

In this, I'm running in an UTF8 encoding issue upon "pip install aiida-core": https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/636328648#L548

Since this seems to be working fine here, I was just wondering whether you encountered this and did something to fix this issue, or whether this somehow comes from the switch of the image

[espenfl]

By the way, I'm trying to switch to a different docker image, which will easily enable us to add debian, centos etc. (preparing a PR)

In this, I'm running in an UTF8 encoding issue upon "pip install aiida-core": https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/636328648#L548

Since this seems to be working fine here, I was just wondering whether you encountered this and did something to fix this issue, or whether this somehow comes from the switch of the image

Running tests on CentOS would be great. This would be more representable than Ubuntu for production environments. Also adding Fedora would be sweet so that we know it also works on a more bleeding RHEL distro. Yes, I have seen this on CentOS, but do not quite remember what it was. Nothing on Fedora 30/31 though. Maybe:

export LC_CTYPE=en_US.UTF-8 export LANG=en_US.UTF-8

?

[espenfl]

Not sure why the idempotent tests fails honestly. Maybe you can have a look @ltalirz ?

[ltalirz]

Somehow aiida-bigdft is not skipped, this might be why idempotency fails https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/636462609#L738

I'm sure this is easy to fix

[ltalirz]

Almost there!

[ltalirz]

Since I added the switch to geerlingguy's images, I'll take it from here

[espenfl]

Perfect.