Ansible Provisioner: Support Guidelines for ansible-playbook options

[gildegoma]

With current open issues like

• Support Ansible “Local Playbooks” #2103 (running ansible-playbook on the guest machine)
• Non-private prompts in Ansible not working #2924 (support of interactive prompts)
• Integration with ansible vault #3241 / Ansible Vault support #3338 (support of vault options)
• provisioners/ansible: Move connection options to inventory #3431 (include vagrant default SSH identity into generated inventory)
• Why not deprecate/drop "official support" of paramiko mode?
  • Ansible provisioner doesn't quite use same SSH settings as vagrant ssh #3900: tricky to be potentially ready for smart mode (aka paramiko or ssh)
  • ssh is needed by Ansible provisioner with Docker provider #4071, ssh-forwarding, multiple ssh identities
  • smart mode corresponds to ssh in a large majority of vagrant setups
• support of new options introduced in Ansible 1.5.x (e.g. --su-user)

I think it is now necessary to clarify what the Ansible provisioner can/should offer, according to following facts:

• With Host-based provisioning, people might want to manually execute ansible-playbook or ansible commands against the Vagrant VMs.
• Guest-based provisioning cannot support interactive prompts (in Vagrant 1.x at least)
• Provisioner Advanced/Expert modes are not necessarily supported (especially if the integration is difficult to implement or use)
• ansible.raw_arguments, ansible.raw_ssh_args and an Ansible configuration file (e.g. local ansible.cfg) can be easily used to customize a lot of things.

The idea is here to establish a simple check-list to take decision about adding (or removing) support of provisioner options, being at maximum "user friendly and backward compatible". Feel free to bring your thoughts!

[geerlingguy]

I think, as long as there's a clear listing of what's supported and what's not supported, then support requests (and frustrations in general with the ansible provisioner) would die down. I'd love to see everything work out of the box, of course, but failing that, I'm happy to know at least private prompts, raw_arguments, and a couple other things work well enough.

[mitchellh]

👍

[gildegoma]

Integration of interactive prompts is definitely tough. If interested, please have a look at #2924 story. As Vagrant is first about automation, I personally don't consider as a big issue to put vars_prompt on the list of Ansible features that are "not officially supported".

/cc @maspwr

[gildegoma]

This issue will be closed with the release of Vagrant 1.7. I'll put a check-list summary soon, and would love to get your feedbacks.

[sethvargo]

@gildegoma close?

[gildegoma]

For Support Questions:

• Unlike other Vagrant provisioner, ansible provisioner is host-based, which means that vagrant and ansible must be installed on the host. This means that the Ansible installation requirements are applied, and that currently Windows host is not supported.
• the Vagrant provisioner now prints out the complete ansible-playbook command that is used behind the scene. For debugging purpose, it can be requested to the user to execute the same command from a shell and compare the results. The idea is also to quickly identify whether the problem can also be reproduced without Vagrant integration.
• For specific Vagrant/Ansible usage or integration issues, please provide the following details in your problem report:
  • Host Operating System version
  • Vagrant basebox details (e.g. box identifier in atlas.hashicorp.com repository or operating system version)
  • Vagrant Version
  • Ansible Version
  • your Vagrantfile
  • enable ansible.verbose option to provide the copy the ansible-playbook command being used by Vagrant.
  • an Ansible playbook that can be used to reproduce the problem
  • any other relevant log output that can help us to better figure out what is happening

For Feature Requests:

To better drive our maintenance decision, I propose to use the following "guide lines":

• Don't try too hard: if for some technical reasons, the integration of an Ansible option is too difficult (a.k.a impossible with current stable designs of Vagrant and Ansible).
• Keep it simple: the vagrant provisioners do not aim at supporting all functionalities of the integrated CM tools, but the most relevant to automatically build a development environment. Avoiding uncommon special cases or extra code complexity for little added value can be an argument to reject a feature request. The Vagrant provisioner provides two special options (raw_aguments and raw_ssh_args) that can be useful to "extend" the provisioner behavior and work around some issues.
• Favor full automation: Following the Vagrant core principle: Run a single command — vagrant up — and sit back as Vagrant puts together your complete development environment. So anything that is needed to achieve that goal is given higher priority, and anything that is not necessary for this goal is given lower priority.

To illustrate the above guidelines, here are some examples of decisions we took:

• the integration of non-private prompts is almost impossible (Non-private prompts in Ansible not working #2924) without requesting some implementation changes in Ansible side. As this feature request is not required for a automated process, while very hard to implement, it won't be integrated into Vagrant provisioner. Note that as Vagrant maintainers, we won't start a discussion with the Ansible project for a possible change request.
• Ansible provisioner doesn't quite use same SSH settings as vagrant ssh #3900 was not simple to solve as long as Vagrant had to deal with paramiko and/or ssh connection modes (due to smart mode logic).
  1. In a first step, we invited users to rely on a raw_ssh_args workaround and asked ansible project about possibly simplify these configuration aspects.
  2. Ansible project rejected the request and it sounds to us too complex to support both paramiko and ssh, for very little added value.
  3. Finally, we decided to officially claim that Vagrant provisioner only supports ssh connection mode as of Vagrant 1.7, which makes lots of sense (vagrant core relies on OpenSSH as well) and allows us to resolve Ansible provisioner doesn't quite use same SSH settings as vagrant ssh #3900 in simpler way (without changes in Ansible side). Note that this transition was not a big-bang breaking change, because almost no users of Vagrant are using an host operating system where Ansible smart mode would fall back to paramiko mode.

I do hope taht the above stuff is clear enough, and I close this issue. But please feel free to add your comments as "guidelines" are living documents :)