I've just merged a very nice patch set from @dhozac that enables the
inventory file to be a directory
If it is a directory, it operates much like a traditional "conf.d"
structure, except it allows both inventory files and
inventory scripts to be comingled.
This means that you can use EC2 and physical-file-based inventory
together, and then specify a "-i" inside the
directory to specifically target one and not the other.
When using this, the patch is structured such that "group_vars" and
"host_vars" structures live *inside* the directory, so it's always
going to work whether you use the whole directory of inventroy sources
or just one file on the inside.
I know this was a much requested feature so this is great to see...
multiple dynamic inventory sources at once, conf.d files,
or both, at the same time in any combination you want!
So thanks to Daniel for this one. It will be up on the documentation
pages eventually.
Prod thru Dev all need to refer to database machine held in the CommonClusterInventory – so naturally, I often want playbooks to refer to machine groups in, say ,ProdClusterInventory and CommonClusterInventory.
ansible -i appears to only allow a single inventory file to be specified. Using -i to refer to a directory:
DevCluster/
DevInventory
CommonInventory
means that CommonInventory is duplicate many times. (And I can’t commit symlinks to our source control)
Ideally (I think), I should be able to say an inventory file includes another.
“means that CommonInventory is duplicate many times. (And I can’t commit symlinks to our source control)”
It sounds like you need to better arrange groups such that you can specify groups, rather than breaking them up into seperate inventories maybe.
Though for larger cases or if you want something more custom, inventory scripts are useful, and if using directories, you can even do things like speak dynamically to Rackspace and EC2 and GCE all in the same call.
“means that CommonInventory is duplicate many times. (And I can’t commit symlinks to our source control)”
It sounds like you need to better arrange groups such that you can specify groups, rather than breaking them up into seperate inventories maybe.
Possibly, the good advice in your best practices document is to separate production/staging/qa/dev …
I think this is essential for us.
Though for larger cases or if you want something more custom, inventory scripts are useful, and if using directories, you can even do things like speak dynamically to Rackspace and EC2 and GCE all in the same call.
Yes – looking at that route. Now, hacking ec.py to provide a limited view of all our ec2 instances.