Closed espenfl closed 4 years ago
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.
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.
I've looked back into the "current user" issue now - TLDR: the issue is still there.
current_user
roleOutput 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!)
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?
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 theguest
(both using the Vagrant setup)?
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.
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
.
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
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.
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
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
?
Not sure why the idempotent tests fails honestly. Maybe you can have a look @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
Almost there!
Since I added the switch to geerlingguy's images, I'll take it from here
Perfect.
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
foransible_env.HOME
etc. Not sure if you guys agree, if not, happy to put it back again.