In 2017, Vagrant was updated to work better with the Ansible provisioner, and a new setting, compatibility_mode, was added to the Ansible provisioner, for example:
config.vm.provision "ansible" do |ansible|
ansible.compatibility_mode = "2.0"
ansible.playbook = "main.yml"
ansible.inventory_path = "inventory"
ansible.limit = "all"
end
If you don't add the ansible.compatibility_mode setting, you get warnings like:
Vagrant has automatically selected the compatibility mode '2.0'
according to the Ansible version installed (2.6.3).
Alternatively, the compatibility mode can be specified in your Vagrantfile:
https://www.vagrantup.com/docs/provisioning/ansible_common.html#compatibility_mode
This clutters up terminal output, and IMO there are two reasons to drop requiring ansible.compatibility_mode to be set to 2.0 at this point:
Can we just default to the 2.0 mode and drop that warning? That way I don't have to keep editing all my various Vagrantfiles and adding the extra line that seems pointless to me.
Vagrant 2.2.7
macOS Catalina
(various)
N/A
N/A
N/A
N/A
I'm not sure how @gildegoma feels about this, but I am :+1: , especially if we time it with the 2.3.0 release.
Can we just default to the 2.0 mode and drop that warning?
As it is planned to introduce a new compatibility mode ("2.9" to handle ansible-galaxy command to install ansible collections, #10958), it is quite better to stick to auto-detection of the compatibility mode (same principle will also apply in the future for any possible needs for new compatibility modes).
It's really annoying to have five lines of output
But that said, I totally agree that this notice is less important as when we introduced the compatibility_mode behaviors, and of low value as it is now a _well-known_ feature. I propose to convert this warning into an INFO log output, so it doesn't appear by default.
@geerlingguy @briancain What do you think?
P.S. Dropping compatibility mode "1.9" will be probably done after (or as part of) #10958 implementation.
(P.S.2. @briancain please rename the issue title if we all agree on the log level change proposal)
Hey @gildegoma - that makes sense to me. I'll go ahead and change the issue title :+1: Edit: sorry, assuming everyone else is on board with this change since it looks like dropping ansible 1.9 is happening in a different issue.
@briancain Yes the removal of "1.8" compatibility mode will be handled in a different issue (still to be created though).
I renamed the issue, and the trivial change will be to modify this statement to call @logger.info(...) instead.
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.
Most helpful comment
I'm not sure how @gildegoma feels about this, but I am :+1: , especially if we time it with the
2.3.0release.