# Group/host vars files proposal.

**URL:** <https://forum.ansible.com/t/group-host-vars-files-proposal/12674>\
**Category:** Ansible Project\
**Created:** [April 12, 2013, 2:22pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674 "2013-04-12T14:22:19Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [April 12, 2013, 2:22pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/1 "2013-04-12T14:22:19Z")

</div>

So this is silly, but I'd like it and be willing to submit the pull  
request --- won't bother if it's not wanted, though.

I was wondering if it would be reasonable to allow files in group\_vars/  
and host\_vars/ to be have a '.yml' or '\*.yaml' extension.

My reasoning --- and here comes the silly --- is that folks' editors can  
then format the files appropriately without resorting to modelines.

It's a simple patch and shouldn't (I think) have any unforeseen  
consequences (the logic seems to be limited to  
'ansible.inventory.vars\_plugins.VarsModule.run').

Let me know if this seems copacetic.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 12, 2013, 2:51pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/2 "2013-04-12T14:51:09Z")

</div>

+1

I am fine with code that would ignore the extensions when matching altogether.

---

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [April 12, 2013, 3:05pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/3 "2013-04-12T15:05:12Z")

</div>

Excerpts from Michael DeHaan's message of 2013-04-12 10:51:09 -0400:

> I am fine with code that would ignore the extensions when matching  
> altogether.

Any preference on how to handle multiple conflicting files, like  
'group\_vars/foo' and 'group\_vars/foo.yaml' both existing? Raising an  
error sound reasonable?

Also, re: another thread, I can roll the patch to load files in  
subdirectories into this. Also, how should I handle the conflict where  
both 'group\_vars/foo' and 'group\_vars/bar/foo' exist?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 12, 2013, 3:10pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/4 "2013-04-12T15:10:30Z")

</div>

They are dictionary, so it could just override all of them in order, like so?

dictionary\_result.update(loaded\_dictionary)

I suspect not too many people will be organizing this way, so it might not be super important to make a really complex solution for it.

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 12, 2013, 3:12pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/5 "2013-04-12T15:12:47Z")

</div>

​I'm also fine with that, as long as it's predictable, and it's documented  
in what order it's parsed en what files gets precedence.

&nbsp;&nbsp;&nbsp;Serge​

---

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [April 12, 2013, 3:19pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/6 "2013-04-12T15:19:11Z")

</div>

Excerpts from Michael DeHaan's message of 2013-04-12 11:10:30 -0400:

> They are dictionary, so it could just override all of them in order, like  
> so?
> 
> dictionary\_result.update(loaded\_dictionary)
> 
> I suspect not too many people will be organizing this way, so it might not  
> be super important to make a really complex solution for it.

The override sounds good, but I wonder if there's any reasonable way to  
choose the precedence?

It seems like for nested subdirectories, we could simply override the  
top-level vars file ('group\_vars/foo') by the deeper vars files, in  
order of depth (the deepest-nested file wins).

For extensions, however, I can't imagine any reasonable precedence  
order that wouldn't be a surprise.

I'd also worry, in the case of some inheritance schema, about folks  
trying to leverage it to implement some strange behavior instead of  
using it as a convenience.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 12, 2013, 3:55pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/7 "2013-04-12T15:55:14Z")

</div>

I do not want any sort of defined precedence.

I am generally just saying we make this ‘work’ and not really document it as being a feature or anything like that, to avoid the questions altogether 🙂

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 12, 2013, 5:10pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/8 "2013-04-12T17:10:49Z")

</div>

> The override sounds good, but I wonder if there's any reasonable way to  
> choose the precedence?
> 
> It seems like for nested subdirectories, we could simply override the  
> top-level vars file ('group\_vars/foo') by the deeper vars files, in  
> order of depth (the deepest-nested file wins).

It's not the aim of this setup to have different same group vars files, so  
I agree with Michael we shouldn't bother too much about it.​​  
Fact remains, you have to choose something 🙂

I'd consider the full path to the group file, and when there are more than  
1, just sort them alfabetically, and let the first precede.

For extensions, however, I can't imagine any reasonable precedence

> order that wouldn't be a surprise.

Well, here you could enforce to have only one of the two options: with the  
yml extension, and without.  
If both exist, exit 1. At least when it comes to 1 particular group file in  
whatever directory.  
​​

> I'd also worry, in the case of some inheritance schema, about folks  
> trying to leverage it to implement some strange behavior instead of  
> using it as a convenience.

​Enforcing to avoid that, you could limit the plugin to only parse the  
first (full-path-alfabetically) found​ group file, for a particular group.

That way, there allways is only 1 group file that gets parsed.

&nbsp;&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [April 12, 2013, 5:50pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/9 "2013-04-12T17:50:01Z")

</div>

Not 100% on the logic, but here's a pull request:  
&nbsp;&nbsp;&nbsp;&nbsp;\<[https://github.com/ansible/ansible/pull/2664&gt](https://github.com/ansible/ansible/pull/2664&gt);

Any suggestions are welcome.

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 12, 2013, 5:52pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/10 "2013-04-12T17:52:36Z")

</div>

> I do not want any sort of defined precedence.

Agreed. Just have a simple logic in the code. As I said, I'd go for the  
first full-path alphabetically found file.  
​​

> I am generally just saying we make this 'work' and not really document it  
> as being a feature or anything like that, to avoid the questions altogether  
> 🙂

I don't believe in this, in this case, unless 'just works' is well  
defined​​. Questions are still going to assault you 🙂  
I propose "only the first full-path alphabetically found file, out of [  
group, group.yml ]. Only one can exist, don't care which.

&nbsp;&nbsp;&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 12, 2013, 8:11pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/11 "2013-04-12T20:11:15Z")

</div>

When you document some confusing fringe use case, that’s when questions assault you. In this case, what you are asking to do is not something most people are going to want to do, and if I think you have to explain “what is the variable precedence merging order when organizing variables in subdirectories”, versus it just doing the most perfectly logical thing, that’s when you’ve failed on the mission of making a more simple system.

It needs to merge all variables, because that’s what most people would expect. First found leaves you in hell when you can’t tell which one it loaded.

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 12, 2013, 8:28pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/12 "2013-04-12T20:28:39Z")

</div>

​OK, seems you are right. One still needs to now which simple precedence is  
used in the case of different same group vars files​..

&nbsp;&nbsp;&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![Lorin\_Hochstein1](https://avatars.discourse-cdn.com/v4/letter/l/ce73a5/32.png) [@Lorin\_Hochstein1](https://forum.ansible.com/u/Lorin_Hochstein1)\
**Post date:** [April 12, 2013, 9:09pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/13 "2013-04-12T21:09:25Z")

</div>

This may be bikeshedding, but I can imagine two possible scenarios:

1. The user deliberately created two files with the same name but different extension, for some reason.

2. The user accidentally created a second file with the same name and different extension. For example, he had foo open in his text editor editor, and then renamed it to foo.yaml, made some changes, and then his editor told him that “foo” has unsaved changes instead of mentioning that it had been deleted out from under him (I’m looking at you, Sublime Text), and then he saved “foo”, and now there’s foo and foo.yaml, and they’re slightly different.

I’d wager that scenario 2 is about 100 times more likely to occur than scenario 1, in which case it’s going to be very difficult for the user to figure out what’s wrong when there’s a variable set unexpectedly.

So I would recommend _disallowing_ having two files with the same name but different extensions, and have ansible fail with an error saying “files foo and foo.yaml have the same name and different extensions, this is not allowed”.

Lorin

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 12, 2013, 9:24pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/14 "2013-04-12T21:24:04Z")

</div>

​Yes, that was one of my first ideas.​ It would help avoiding name  
collision.  
But I'd limit the 'extension' to 'yml', which is what this was all about in  
the first place.

Other wise you could have bad clashes like:

.me is a top level domain.  
.me.uk is also a top level domain....

​ Serge​

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [April 13, 2013, 12:35am UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/15 "2013-04-13T00:35:34Z")

</div>

Do we really want to add this complexity ? I'd say use group\_vars/ and host\_vars/ for the simple cases and if you need something more complex, look at writing an inventory script that does exactly what you need.

Wasn't that our credo a few months ago ? 😉

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 13, 2013, 1:29am UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/16 "2013-04-13T01:29:09Z")

</div>

Actually yes, I think Dag’s right.

When I originally built inventory scripts, that was the purpose… if you need a better way to organize, make a better/different variation, and we can let people know about it.

–Michael

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 13, 2013, 6:50pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/17 "2013-04-13T18:50:39Z")

</div>

​I'd like to come back to this:​  
​​

> Actually yes, I think Dag's right.
> 
> Do we really want to add this complexity ? I'd say use group\_vars/ and
> 
> > host\_vars/ for the simple cases and if you need something more complex,  
> > look at writing an inventory script that does exactly what you need.

​I totally agree that we shouldn't have the complexity of elaborating on  
the logic of precedence in various vars\_files.​  
Unortunately Morgan and me got to that "bikeshedding" point because we had  
too choose a logic.

All this complexity disappears if we don't allow multiple files for the  
same host or group.

I updated Morgan's patch to implement this, and I think this is clean and  
simple. It also considers file with and without the yml or yaml extension.

serge@cyberlab:~/tmp$ cat inventory  
[group]  
localhost

[project1]  
localghost ansible\_ssh\_host=localhost

[staging[  
localpc ansible\_ssh\_host=localhost  
localdev ansible\_ssh\_host=localhost

serge@cyberlab:~/tmp$ tree  
.  
├── group\_vars  
│ ├── group  
│ ├── group.yml  
│ ├── production  
│ │ └── project1  
│ └── project1  
├── host\_vars  
│ ├── localpc.yaml  
│ └── project1  
│ └── localpc  
│ └── localdev  
├── inventory  
└── vars\_plugins -\> ../src/ansible/lib/ansible/inventory/vars\_plugins/

serge@cyberlab:~/tmp$ ../src/ansible/bin/ansible -i inventory all -m debug  
-o

localpc | FAILED =\> Found more than one file for host 'localpc':  
['host\_vars/localpc.yaml', 'host\_vars/project1/localpc']  
localghost | FAILED =\> Found more than one file for group 'project1':  
['group\_vars/production/project1', 'group\_vars/project1']  
localhost | FAILED =\> Found more than one file for group 'group':  
['group\_vars/group', 'group\_vars/group.yml']  
localdev | success \>\> {"msg": "Hello world!"}

​Anyway, I issued a PR for review:  
[https://github.com/ansible/ansible/pull/2675​](https://github.com/ansible/ansible/pull/2675%E2%80%8B)

&nbsp;&nbsp;&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [April 13, 2013, 8:11pm UTC](https://forum.ansible.com/t/group-host-vars-files-proposal/12674/18 "2013-04-13T20:11:00Z")

</div>

The subdir logic I think is a slippery slope, reminescent of when we also supported inventory in a YAML format.

This should, I think, be implemented as an external inventory script.

In general, things that are hard to explain _why_ you need them, or make it hard to find where the file that controls X really is (and can you be sure that’s really the one?) seem like bad ideas for the general application to me.

It’s fine for specific use cases, though, which is why the system is pluggable.
