To work with “children” the group names would have to be unique in the whole tree. So “web” would break this up.
Wouldn’t it be nice to use something like that?
{
“server”
{ “atlanta” { “web” {“hosts”: [ “web1” ] } } },
{ “raleigh” { “web” {“hosts”: [ “web2” ] } } }
}
I came up with this by using a KeePass database as inventory source: https://github.com/escoreal/ansible_kdb_inventory
Here I have to build the tree for each host and add it to all parents. But this doesn’t scale to well.
We are working on the same problem. Right know we are using a custom piece of python code with nested dicts to represent our group and return them as json.
You can write a dynamic inventory script which allows you to specify the inventory in another format, or fetch it from a configuration management database.
I’m not sure if this is exactly what you want, but I wrote one that lets you specify servers and which parent groups they belong in; basically the inverse of the normal inventory. The code is here https://github.com/pmarkham/ansible-inventory-inverted.
yes, I did likely the same but used a KeePass 2 database instead of an ini file as inventory source. So here we have similar thoughts (if you are using KeePass 2 you should try my script ). Adding each host to his parents is possible. But apart from the scaling problem you would have trouble with group_vars for non unique group names in different branches. And I guess there are a lot more users which manage their inventory as tree.
I think that this is a more natural way of specifying it rather than the sectioning of ini files. The group_vars/group1, group_vars/group2, … files (or dirs) could be used to specify common attributes, the dynamic inventory script could read these and output just the right information
Of course this create yet another config file format but that is just because I’m comparing to a tool where I found the inventory management to be somewhat working. When dealing with manual inventory management (of course going for larger numbers of servers nothing beats an actuall automated inventory)
I originally had the inventory in yaml format, but changed to ini format for some reason (which I can’t remember). The clusterssh format would work well if you just wanted the host and group relationships, but I also wanted to support host and group variables like the default static inventory format does.
Ideally a CMDB of some sort would be used, but we don’t have one so we need to maintain a manual inventory.
Fortunately they’ve made it flexible enough to support whatever format you want to use; I’m currently playing with getting the inventory from etcd so we can dynamically add and remove hosts.
yes the host and group variables are the most important thing and I’d personally go and separate them out to the group_vars/… and host_vars/… directories. That is just a matter preference.
I have no emotional attachement to the the file format. I’m just saying that I saw this format working and it was working very convenient to work with.
I think a large part of the way will be discussing this as it is nearly infinitely more complicated to create something that is then very simple to use
you are right. Supporting a tree structure for this with plain files/directories (group_vars…) wouldn’t be that nice. And it is very sensible at the moment.
But I made this work for me by resolving the group_vars in the tree directly to host_vars. So group names don’t have to be unique in the inventory. And now I am very happy with the combination of Ansible and KeePass…
If someone is interested in this topic:
Now, I use the name and the UUID of the groups (name_uuid) to build up the tree (children, group_vars…). So group names don’t have to be unique and performance and scaling isn’t a problem anymore…
If you use a CMDB your groups usually would have some IDs, too.
If someone come up with a solution (like a dynamic inventory script that reads some inverted inventory dsl), please share, I would be very interested!
I see the need for such inverted inventory in the case, where I have a lot of interconnected services, where number of services is really large. This is how hadoop environment looks like with tens of different services.
Thanks,
Krzysztof
W dniu poniedziałek, 7 września 2015 21:10:15 UTC+2 użytkownik esco real napisał:
). Adding each host to his parents is possible. But apart from the scaling problem you would have trouble with group_vars for non unique group names in different branches. And I guess there are a lot more users which manage their inventory as tree.