As far as I understand the current state of source code, ansible_hosts
can be:
* the path to a dynamic inventory program
* the path to a static inventory file
* the path to an inventory directory, from which dynamic inventory
scripts and static inventory files are launched
* a comma-separated list of host names
In my usage context, several distinct applications are managed through
Ansible, each with its own subset of hosts, and its own host grouping
needs. So, I would like to have a two-level inventoy with:
* a shared, company one inventory listing all hosts and setting
common host variables
* AND an application specific inventory for each application,
providing additional application specific host groups (and
possibly variables).
I think it would be possible to implement that with minimal fuss
by minimally tweaking the semantics of ansible_hosts so that it could
be:
* the path to a dynamic inventory program
* the path to a static inventory file
* the path to an inventory directory, from which dynamic inventory
scripts and static inventory files are launched
* a host name
OR * a comma-separated list of /any of the above/
I could thus set in a shared configuration:
ansible_hosts=/path/to/companywide/inventory,appspecific_inventory
where /path/to/companywide/inventory would be the company-wide
shared inventory, and "appspecific_inventory", being a relative path,
would be interpreted relative to the current directory and contain the
application specific data.
Thoughts?
Thomas.
Please direct this question to ansible-project list.
Thanks!
* Toshio Kuratomi, 2014-11-16 :
> I've just been thinking about this but didn't get further than this
> problem: how would we differentiate between hostnames and relative
> filenames?
I was thinking of a simple and straightforward approach: if the file
exists, then assume the user means that, else treat as host name
(possibly also checking whether hostname resolves). A possible
alternative would be to check for presence of a / in the name, and
treat any name with '/' as a filename, anything else as a host name.
This would still allow relative filenames to be designated as ./file,
but I find this more awkward and less natural.
One of these strategies might work.
Thinking of this as a config file, I like "./filename" most. It seems
more standard (for instance, the PATH variable) and it's explicit.
However, it is less backwards compatible unless we also hack the
heuristic to treat a string with no commas as a filename. Special
cases make learning a user interface harder for future users.
Checking for file existence seems more backwards compatible without a
special case. But I still worry about a user who might, for instance,
have directories named after hosts (each dir holds some data specific
to the host, for instance). If the user ran ansible from that
directory they'd unexpectedly get something different than if they ran
it from another filesystem location. This probably also widens the
possibility of an attacker trying to inject inventory files that cause
bad things to happen.
-Toshio
* Toshio Kuratomi, 2014-11-17 :
Thinking of this as a config file, I like "./filename" most. It seems
more standard (for instance, the PATH variable) and it's explicit.
However, it is less backwards compatible unless we also hack the
heuristic to treat a string with no commas as a filename. Special
cases make learning a user interface harder for future users.
Checking for file existence seems more backwards compatible without a
special case. But I still worry about a user who might, for instance,
have directories named after hosts (each dir holds some data specific
to the host, for instance). If the user ran ansible from that
directory they'd unexpectedly get something different than if they ran
it from another filesystem location. This probably also widens the
possibility of an attacker trying to inject inventory files that cause
bad things to happen.
One possibility is to check for both file existence and host name
existence, and display a warning (or even bail out) in case there
is an ambiguity (file exists and host name resolves).
Thomas.