So… some questions have been asked about the YAML inventory format. Now, I’ll prefix these questions with this. If it ever becomes complicated enough so it’s not intuitive how something works, we need to make things simpler. Some of the things asked risk building an interest in a complex system, which it is the explicit goal of Ansible to NOT create.
I think rather than accommodating patches peace meal to YAML inventory we should talk about it and figure it out, and then maybe different people can work on different parts of it if they are interested – but we’ll at least have a uniform vision of what the YAML inventory file should do. This will also make my job for documenting how it works easier.
Some of the questions are:
- if I have multiple groups, does one group override the variables set by the other group if I use the same variable name twice (currently answer: yes)… but we could also have arrays add to each other and hashes hash merge… or it could raise an error! Raising an error would be simplest, I don’t know. I took the “blend” approach for Cobbler, but Cobbler was treeish, and these are not treeish.
PROPOSAL: we make variables override one another, since there is not a really good use case for building up and merging array content yet, and we document that this is the way it works.
- If I have variables set in the YAML inventory file and also the playbook, which wins? IMHO, the playbook should win, and I’m pretty sure it presently does, but maybe it should try to blend hashes and arrays. On the other hand, I’m also of the opinion that nested data in variables is a sign that something is too complicated and maybe we shouldn’t worry about it. Most people aren’t using nested data.
PROPOSAL: we document that the playbook wins
- can I specify a default port for everything in the YAML inventory file. currently no. Should we? Well, it takes a list, and we have to extend things to be reasonably backward compatible, don’t we? Currently you would have to define this per group.
PROPOSAL: we document that YAML inventory is for setting variables that apply to particular hosts or groups of hosts, and anything global should be set in your particular plays. Set the port with each group if you need to.
- can I specify default sudo for everything? current answer: no. I’m not even sure this is a good idea. Part of the reason I developed sudo support was so I could do some things on the host sudo and some things NOT as sudo, so IMHO I think a playbook should still be setting sudo.
PROPOSAL: Sudo is set in the playbook because it’s not true that you would want to run every operation on the system as root.
- can I have groups of groups. current answer: no, but I’d really like this.
PROPOSAL: we have an RFE open here. no discussion required but we should have this.
- can I have include files to specify hosts in other files, smaller files, etc. current answer: no, and I’m not sure we need it.
PROPOSAL: we don’t implement this, because it’s never going to be terribly large. Worry about this later.
Let’s solve all of this together maybe, and decide how we want things to work, and then it will be clear about what they do and where we want things to go.
–Michael