# Task/inventory option preference

**URL:** <https://forum.ansible.com/t/task-inventory-option-preference/19596>\
**Category:** Ansible Project\
**Created:** [October 23, 2015, 3:30pm UTC](https://forum.ansible.com/t/task-inventory-option-preference/19596 "2015-10-23T15:30:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jonas.haag](https://avatars.discourse-cdn.com/v4/letter/j/f07891/32.png) [@jonas.haag](https://forum.ansible.com/u/jonas.haag)\
**Post date:** [October 23, 2015, 3:30pm UTC](https://forum.ansible.com/t/task-inventory-option-preference/19596/1 "2015-10-23T15:30:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [October 23, 2015, 4:04pm UTC](https://forum.ansible.com/t/task-inventory-option-preference/19596/2 "2015-10-23T16:04:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jonas.haag](https://avatars.discourse-cdn.com/v4/letter/j/f07891/32.png) [@jonas.haag](https://forum.ansible.com/u/jonas.haag)\
**Post date:** [October 30, 2015, 10:08am UTC](https://forum.ansible.com/t/task-inventory-option-preference/19596/3 "2015-10-30T10:08:42Z")

</div>

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](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”).