Misunderstanding about host + var + group_vars

Archives Ansible Project
1

I’ve seen others post similar experiences, but I can never quite get my head around it. If someone could explain the following behaviour that would be great.

So i have mydev.yml and mylive.yml

They look something like:

mydev.yml

`

  • hosts: dev_place
    sudo: no

`

mylive.yml

`

  • hosts: live_place
    sudo: no

`

hosts

`
[dev_place]
10.10.10.10

[dev_place:vars]
ansible_private_key_file=/home/dev_user/.ssh/key

[live_place]
10.10.10.10

[live_place:vars]
ansible_private_key_file=/home/live_user/.ssh/key

`

Both hosts point to the same server but reference different paths for their keys. This is because I can run locally on my vagrant or run it on a live server - both need to talk to the same server.

So I run this locally:

ansible-playbook mydev.yml-i hosts -vvv

From the printout, I can see it is using live_place vars

I’ve tried removing the :vars from here, and adding:

`
group_vars.dev_place.yml
group_vars.live_place.yml

`

So then these would have the relative variables, but again it would be using which ever hosts are listed last.

So if I swap dev_place and live_place around in the hosts file, it will then take dev_place vars.

I know ansible has a specific way of how it deals with vars, but I’m really struggling to understand.
What’s the point of passing a config name if it’s just going to grab the last vars from somewhere else…?

I apologise for my misunderstanding on this stuff.

2

You are not passing a config name, you are passing a group name,
groups in Ansible are used for 2 things:

- a way to target hosts
- a way to bulk assign variables to a host

As such variables are not assigned to the group when you target it in
the play, only the host, since the same host is member of 2 groups it
inherits the variables from both, not just the one you target in the
play. Since there is a conflict the 'last one merged wins', groups are
evaluated by child/parent relationship and then by name. (in 2.4 we
introduce priorities to give you fine grained control ... docs
pending).

For your situation, I would either use 2 different inventories, (live
and dev) or key that variable via extra vars or vars_files.