Ansible provisioner should allow an array value for the inventory_path option

[Ernest0x]

ansible-playbook command can take multiple -i arguments for accessing multiple inventory paths. So, the ansible provisioner in vagrant should also allow an array value for the inventory_path option.

[gildegoma]

I must say that I am not very convinced by the advantage/utility of this addition. For me it sounds more like an invitation to makes things more complicated than necessary.

@Ernest0x In the context of Vagrant use cases, I am curious why you would really need to refer to more than one location for your static inventory/ies? Are you aware that you can specify the path to folder that can contain multiple inventory files? And if you still need multiple inventory paths, you can always rely on the raw_arguments option to pass more -i arguments. Thank you in advance for bringing a few more details about your exact needs, so that we don't add "unnecessary code/behaviours".

@soapy1 @chrisroberts @briancain Are you okay to wait+agree on the rationale for this enhancement before merging #11480 ?

[Ernest0x]

@gildegoma A common pattern is to have multiple inventory sources, e.g. for production, staging and development hosts. So, if you need to provision a host with vagrant and its ansible plugin, it could be the case that this host needs to be deployed with access to variables coming from multiple inventory sources. For example, a staging name server that is going to serve names for all hosts (production, staging and development). Another use case is when you have to provision a host defined in a static, directory/file-based inventory with variables coming from a dynamic, script-based inventory.

[soapy1]

@gildegoma good catch about raw_arguments. @Ernest0x could a solution like this work for you:

Vagrant.configure("2") do |config|
  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "playbook.yml"
    ansible.inventory_path = "common/inv"
   ansible.raw_arguments = [
       "-i=prod/inv",
       "-i=staging/inv",
       "-i=dev/inv",
   ]
  end
end

[Ernest0x]

@soapy1 It would work but it is not intuitive

Also, @gildegoma I think that #11480 answers to your concern about complexity. For me, it does not add any. It's pretty straightforward.

[gildegoma]

@Ernest0x Thank you for taking time to add your inputs. Usually Vagrant-based project should be "self-contained" (i.e. everything should be stored in - or fetched into - its code main directory/repository). This means that there should be nothing to prevent you to locate all the ansible inventory sources in common directory (see proposed example below).

For me it sounds more like an invitation to makes things more complicated than necessary.

I was not talking about adding vagrant code complexity (although it's always a concern to keep in mind, of course), but about Vagrant goals. Vagrant Ansible provisioners are not intended to support every possible usage of Ansible commands. If you're interested for more details, please have a look at #3396 thread, where trade-off/decision guidelines were documented.

So, in my opinion, most "multiple inventories" inventory_path project should be similar to the following layout example.

Files Structure:

Vagrantfile
playbook.yml
inventory/
  01-dynamic.py # executable file
  02-common
  03-dev
  04-staging
  05-prod
  group_vars/
    all.yml             # assign variables to all hosts

Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "playbook.yml"
    ansible.inventory_path = "inventory"
  end
end

If the above structure doesn't fit your needs and you really need to refer to some "external" inventory sources, then using the raw_arguments option is a good way to go as well.

For all these reasons, I am not convinced it is worth to make this change (low demand). I let @soapy1 @chrisroberts @briancain decide, and won't block anything as I could bring my two cents :)

References:

• Ansible Docs - Using multiple inventory sources

• 3396

[briancain]

I agree with @gildegoma here. I'm not totally convinced that it makes sense for someone to have inventory paths coming from different parts of your system outside of your Vagrant project. Typically your Vagrant project should be fairly isolated, and therefore it would make sense to have a simple folder like mentioned above to include. It looks like the ansible docs also recommend this pattern. If you really need them scattered about, you could use raw_arguments, I think that is the way to go if you really need these to be in different locations on your computer. Otherwise I think the supported case for ansbile is what was mentioned above.

[Ernest0x]

So, in my opinion, most "multiple inventories" inventory_path project should be similar to the following layout example.

I respect your opinion, but people should choose what suits best to their needs. Having separate directories is also a pattern to use. And a tool like vagrant should make it intuitive to support both cases. In fact, an advantage of separating your environments into multiple inventory directories is that you can have separate group_vars directories for each directory/environment.

I was not talking about adding vagrant code complexity (although it's always a concern to keep in mind, of course), but about Vagrant goals. Vagrant Ansible provisioners are not intended to support every possible usage of Ansible commands. If you're interested for more details, please have a look at #3396 thread, where trade-off/decision guidelines were documented.

I don't see how allowing Vagrant's ansbile provisioner to target multiple inventory paths instead of just one is againt Vagrant goals. It is just an enhanchment to make it more straightforward using multiple ansible inventory paths.

It looks like the ansible docs also recommend this pattern

Not really. The single directory pattern is mentioned as another way to setup your multiple inventory sources. Actually, the docs start first with the pattern of multiple inventory paths and how you can target them with multiple -i parameters (with a given example too). Between the two methods there is no a recommended one in the ansible docs.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.