Task/inventory option preference

Archives Ansible Project
1

Hi everyone,

what is the expected preference of options like “become” when they are defined both in the inventory and a task?

More specifically, I connect to my Vagrant machines using the “vagrant” user, then become root by having this in the inventory:

vagrant-machine ansible_become=yes ansible_become_method=sudo ansible_become_user=root

For a single task I need to NOT become root, so I added “become: False” to that task. By a lot of debugging I found out that inventory options are always preferred over task options. Is this expected behaviour? Why would you want to have this?

Thanks
Jonas

2

connection and privilege escalation variables in inventory override
play/task ones because we consider the host information to be more
specific and the only way to handle scenarios in a heterogeneous setup
in which the login/sudo/su information is different from host to host.

It is rare to see ansible_become=yes in the vars, but that might be
needed in some cases, most users would set it in ansible.cfg to allow
for easy override at play/task level.

For that task you might just need to override ansible_become in the play.

3

Brian, thanks for the clarification. Do you happen to know if there’s some way to make sure in a task that we’re NOT connected with become=yes?

The reason I started this conversation is because I faced issues with debops/ansible-core, which expects some task to be execute without become. I wanted to contribute a patch there to prevent other people from hitting the same issue and not knowing what’s going wrong. The task I’m talking about is https://github.com/debops/ansible-core/blob/d07d9e71e6a25656df8c4111b3f46f0edb30942c/tasks/main.yml#L19.

I thought about first using whoami on the remote machine to ensure we’re not root. But you’d have to be more general than comparing with “root” because people might become some other user as well. This approach could work if there’s some way in the task to read out ansible_become_user (which is, to some extent, the generalization of “root”).