# Multiple inventory sources **URL:** \ **Category:** Ansible Developer\ **Created:** [November 14, 2014, 2:19pm UTC](https://forum.ansible.com/t/multiple-inventory-sources/16787 "2014-11-14T14:19:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Thomas\_Quinot](https://avatars.discourse-cdn.com/v4/letter/t/ecd19e/32.png) [@Thomas\_Quinot](https://forum.ansible.com/u/Thomas_Quinot)\ **Post date:** [November 14, 2014, 2:19pm UTC](https://forum.ansible.com/t/multiple-inventory-sources/16787/1 "2014-11-14T14:19:15Z")
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. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [November 14, 2014, 6:03pm UTC](https://forum.ansible.com/t/multiple-inventory-sources/16787/2 "2014-11-14T18:03:30Z")
Please direct this question to ansible-project list. Thanks! ---
**Author:** ![Toshio\_Kuratomi](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Toshio\_Kuratomi](https://forum.ansible.com/u/Toshio_Kuratomi)\ **Post date:** [November 17, 2014, 4:11pm UTC](https://forum.ansible.com/t/multiple-inventory-sources/16787/3 "2014-11-17T16:11:31Z")
> \* 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 ---
**Author:** ![Thomas\_Quinot](https://avatars.discourse-cdn.com/v4/letter/t/ecd19e/32.png) [@Thomas\_Quinot](https://forum.ansible.com/u/Thomas_Quinot)\ **Post date:** [November 18, 2014, 10:04am UTC](https://forum.ansible.com/t/multiple-inventory-sources/16787/4 "2014-11-18T10:04:20Z")
\* 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.