Vagrant: Ignores ansible configuration

[eggsby]

_Background:_

ansible supports configuration through a ansible.cfg file next to the playbook, or through ~/.ansible.cfg to provide default configuration values.

_Bug:_

All configuration options set through the ansible provisioner plugin (inventory file, host key checking, etc) currently blow away any configuration the user has provided through other means.

The most glaring case is the inventory file -- the plugin auto-generates an inventory file to use if one isn't provided, overriding the hostfile preference set in ansible.cfg.

_Use case:_

My inventory file is a script which happens to know about vagrant. I don't want to specify the path to that script in every Vagrantfile since I already specify it in my ansible.cfg

_Possible resolution:_

I think that there should be a config option like ansible.generate_inventory = false as an alternative to setting the inventory path.

-- Thanks,
Thomas

[mitchellh]

/cc @commandtab What do you think here?

[command-tab]

This is an interesting one. I don't think having a separate inventory file or script that knows about Vagrant is a very common use case, but I can see why it's an issue in this instance. It's difficult because Vagrant needs to do different things depending on the presence or absence of an inventory file, and specifying it in ansible.cfg doesn't do Vagrant much good, short of parsing that file and doing the right thing — too much magic for my liking.

@mitchellh, would it be reasonable to add that config option to opt out of all inventory related code paths? Or, better put, is there concern over having an over-abundance of provisioner options?

[ex-nerd]

It would be useful to allow some of the values in ansible.cfg to be used. I find myself needing to use hash_behavior=merge and other config settings which vagrant doesn't know about, and which can't be provided at runtime via ansible.raw_arguments.

I would expect vagrant to allow me to override ansible config, but the whole point of using something like ansible is to keep all of my config management defaults in a single place. Playbook is always something that must be specified explicitly, and in Vagrant's case, the inventory file could be considered "special" -- everything else makes sense to allow entirely within ansible,

[command-tab]

It would be useful to allow some of the values in ansible.cfg to be used.

Aside from the settings that Vagrant sets like inventory file (cf. the original issue above), my understanding is that other ansible.cfg settings are left intact and respected by Vagrant-initiated ansible-playbook calls.

I would expect vagrant to allow me to override ansible config

Ansible only looks in these places for ansible.cfg:

• /etc/ansible/ansible.cfg
• ~/.ansible.cfg
• ansible.cfg (in the current directory)

It's not ideal, but you might be able to use the Ansible provisioner's raw_arguments config options to set ansible.cfg options. It gets added here: https://github.com/mitchellh/vagrant/blob/042a8d6428a83a6c5bea2d2421eeb5ed33927155/plugins/provisioners/ansible/provisioner.rb#L14

[ex-nerd]

Ah, that may explain it. ansible.cfg lives in my playbook directory (ansible-config repo), but the Vagrantfile lives in my main web code repo. Would be nice of ansible could also search in #{playbook_dir}/ansible.cfg

[ex-nerd]

Unfortunately, it doesn't looks like ansible-playbook has an option for specifying the config file.

[gildegoma]

Yep, a local ansible.cfg has to sit in the same folder as Vagrantfile, which corresponds to the ansible-playbook _current directory_ in Vagrant execution context.

That's not too restrictive in my opinion, but we maybe could avoid (a bit) this confusion by adding a note in the docs. I'll try to propose something via #2658...

[MiLk]

In the same way, if you change the ssh_options in your ansible config file (editing ConstrolPersist value by example), it will be rewritten by vagrant.

[gildegoma]

@MiLk That's correct that since #2952, Vagrant will _under certain conditions_ use ANSIBLE_SSH_ARGS environment variable, which has higher priority than ssh_args setting in ansible configuration file.

In your case, I see two possible solutions:

• Define all your SSH settings via Vagrant's ansible.raw_ssh_args option.

or

• Ensure that Vagrant does not export ANSIBLE_SSH_ARGS variable, so that your ansible.cfg settings are applied. You'll have to redefine things like SSH forwarding in the ansible config file...

Back to original request discussion, I'm open to evaluate a possible feature to tell Vagrant to give priority to ansible.cfg file (e.g. by not exporting ANSIBLE_SSH_ARGS, not passing inventory, not setting host key checking flag, etc.). At first glance, it sounds a bit tricky (and overkill) to me, but why not... other thoughts?

[MiLk]

config.ssh.forward_agent was defined in my Vagrantfile, I didn't see it. Thank you.

[eggsby]

While ansible doesn't support a command line argument for a config file it does support the environment variable ANSIBLE_CONFIG with a path to the ansible.cfg file.

[gildegoma]

The usage of ANSIBLE_CONFIG environment variable is documented as of Vagrant 1.5.0.

@eggsby can we try to re-formulate together the feature request(s), maybe by closing this issue and open some new one(s).

My rough summary is:

• ability to disable some default behaviours (e.g. disable inventory generation, without having to provide a static inventory)
• ability to indicates the path to an ansible.config_file, and let vagrant export ANSIBLE_CONFIG accordingly.

I think that both features should not be coupled.
@eggsby Do you agree on this wish list? Is there something else?

[eggsby]

@gildegoma et al,

I will close this issue as the documentation changes and existing provisioner behavior are enough to solve the original issue I encountered.

Adding the capability to configure these sorts of things through the Vagrantfile would be wonderful.

In regard to inventory generation & dynamic inventory scripts, as hinted at in the documentation I have taken to putting my scripts in .vagrant/provisioners/ansible/inventory which then gets merged with the vagrant generated hostgroup by ansible.

The existing functionality works well for my use case, it was just maybe a little non-obvious to come across.

Cheers,
Thomas

[gildegoma]

@eggsby glad to see your positive feedbacks, thanks for such a quick and informative reply :)

To make it clear to the user community, pull requests for the following features are very welcome (but no active development has started yet):

• ability to disable some default behaviours (e.g. disable inventory generation, without having to provide a static inventory)
• ability to indicates the path to an ansible.config_file, and let vagrant export ANSIBLE_CONFIG accordingly.

If interested, please create a new issue referencing to this comment.

[ayen-tibco]

Please re-open as Vagrant's ansible integration still overrides ansible.cfg settings for example "--timeout=30" is hard hard coded into the ansible plugin. My workaround was to specify via the raw arguments in the Vagrantfile. Even though ansible-playbook was able to locate and read my ansible.cfg when I did a 'vagrant provision --provision-with ansible', the initial ansible-playbook launch by Vagrant contained hard coded ssh and timeout settings from the plugin.

ansible.raw_arguments = ["--timeout=120"]

[siwyd]

I can confirm this, it doesn't seem to be picking up the specified ansible.cfg file.

[gildegoma]

@ayen-tibco @SimonWydooghe Thank you for your feedbacks!

As of Vagrant 1.9.0 you can optionally specify where the ansible.cfg is located with the config_file provisioner option. If not specified, only an ansible.cfg file in the same directory as the Vagrantfile might be considered (in addition to user or system wide config file).

That said, the config_file option will not help to override some command line arguments generated by the Ansible provisioners (e.g. the hardcoded timeout parameter). For these non-frequent cases, the raw_arguments is your friend ;-) We might improve the documentation regarding this though... All nice ideas are welcome 😻.

I'm locking this thread, but please feel free to report bugs, engage discussion about new possible change requests (via the Google Mailing list or with new GitHub issues).