[WIP] Add new provisioner: Ansible on the Guest VM

[gildegoma]

@mitchellh @sethvargo Here is my attempt to implement #2103. My idea is to try to get it merged into 1.8 Milestone.

I created the branch directly in original repository, so that you can directly add things by your own (especially to quickly fix my English and Ruby mistakes, sorry in advance 😅). I am looking forward to receiving your comments 😀 !

The ansible_local Provisioner (new feature)

I'd be very thankful to the interested Vagrant users to check the current design and report as soon as possible if their needs wouldn't be satisfied, so we can adapt before this first release.

Note that the Ansible Installation Capability is already available for the following platforms (using the distribution package system (e.g. apt, yum, pacman, freebsd pkg, etc):

• Debian 6+ (package is officially available as of jessie, with backports for wheezy. Older versions won't be supported).
• Ubuntu 12.04+ (package is officially available as of Trusty, but it is preferable to use the official PPA from Ansible Inc.)
• RedHat-6+ family via EPEL repository (validated on Fedora20, CentOS 6 & 7, OracleLinux 6 & 7)
• ArchLinux (package is officially available)
• OpenSUSE 13.2+ (package is officially available as of 13.2)
• FreeBSD 10+ (package is officially available as of 10.0)

Open Questions

Discussed via code comments on this GitHub pull request.

Missing Features

The following functions are intentionally not developed in this initial version (but might be considered in future development iterations):

• Automated installation of a specific Ansible version (e.g. via pip packaging).

  Reasons: Lack of user feedback, experience to confirm this need. User still can build their own base box.

The ansible Provisioner

By keeping the existing unit test coverage almost unchanged, I'm quite confident that the refactored ansible provisioner still behave the same (a.k.a free from new bugs!). I only added a few minor things that I hit on my coding path (Windows warning, and a buggy behavior when VAGRANT_LOG is not defined).

The Documentation

Many changes are also proposed here. I mainly tried to cut the things in four separate pages with the goal to help user to quickly find the relevant information:

• a common page to introduce how Ansible is integrated in Vagrant (ansible_intro)
• a common page to list the common options (ansible_common)
• a short page to quick start with ansible provisioner, with specific tips and tricks
• a short page to quick start with ansible_local provisioner, with specific tips and tricks

Like for the code, I'm open to any other way to organize the things... just let me know what do you think.

Finalization Check-List

• Ansible-Galaxy Integration #2718: Add Galaxy Support
• Reintegrate changes related to Vagrant doesn't propagate --no-color option to ansisble provisioner #5531, Allow Ansible provisioner to run reliably in parallel #5551, Impossible to hide ansible-playbook command details in console output #5803, Store the first SSH private key in generated Ansible inventory #5765, Fix invalid ini entry error when ansible_ssh_private_key_file contains spaces #6209, Absolutely force the Ansible remote (ssh) user to correspond to Vagrant ssh user  #6348
• Integration/Regression Tests on Linux, Mac and Windows hosts
• Documentation reviewed 🛂
• All open questions and doubts are closed.
• Freeze provisioner naming: ansible_local, or ansible_on_guest, or ...?
• Improve/Align Ruby style
• Remove all TODOs (fix them or create new GitHub issues for later work)
• Code freeze and add the new unit tests, (for ansible_local coverage, following http://betterspecs.org styling?)

CHANGELOG entries

## 1.8.0 (unreleased)

FEATURES:

  - provisioners/ansible_local: New provisioner to execute Ansible from the guest machine [GH-5340]

IMPROVEMENTS:

  - provisioners/ansible: Warn when running from a Windows Host [GH-5292]

BUGS:

  - provisioners/ansible: don't show the `ansible-playbook` command when verbose option is an empty string

[gildegoma]

The name ansible_local corresponds to Packer's ansible-local, but following underscore style used in Vagrant (e.g. chef_solo,...).

Note that this new provisioner is potentially able to also execute Ansible against remote machines (see the trick in ansible_local.html.md), and I personally would find a bit more correct to name it ansible_on_guest (or something similar). What do you think?

[QWp6t]

The use of the term local in ansible_local is consistent with local-exec for vagrant push. (But obviously the naming schemes differ in other ways, such as - vs _ and whether local comes first or second.)

[gildegoma]

We actually could add here a little notice to propose to use ansible_local provisioner instead...

[tknerr]

You might also want to check the https://github.com/vovimayhem/vagrant-guest_ansible plugin which does roughly the same.

Also this Gist might be helpful:
https://gist.github.com/tknerr/291b765df23845e56a29

[warrenseine]

Any update about merging this upstream?

[cweagans]

I think it's reasonable to leave out the Ansible auto install bit. Personally, I don't like that Vagrant installs crap in my VM in other situations. Any progress on getting this merged? I've had to basically use the shell provisioner to SSH into the VM and run the playbooks there. It's kind of a not-very-good process, and I'd love to use the legit ansible_local provisioner.

I'd suggest changing the name, however. ansible_local could be construed to mean that Ansible will be run locally (i.e. on the host), as opposed to inside the guest VM. Perhaps ansible_guest or ansible_nonlocal or ansible_vm or something like that?

[gildegoma]

Sorry, I have not time now to answer in details to all the above questions, but I try to address some parts below:

• Ansible autosetup is an optional feature (useful for beginners). Advanced users might certainly prefer to opt-out autosetup and ship their own Vagrant box (e.g. built by Packer) including the exact version and setup of Ansible they want.
• Ansible autosetup via PIP was explicitly excluded from this initial PR, because I'm (maybe wrongly) afraid to mix up things (e.g. break the environment for Python developers). For an exact version, we also could install from git source in the future, etc. But, I think that having some basic defaults is fair enough (to begin at least). Of course, I am open to propositions after the initial release of this provisioner, but I don't want to deal with these questions in this first iteration, and give priority to more critical points.
• The provisioner naming is in the final checklist. For the moment, ansible_local (or maybe ansible-local) might be preferred for "historical" reasons as it corresponds to the Packer naming. But I agree, that something like ansible_on_guest or ansible_guest, ... is more self-explanatory, as "local" is quite relative as @cweagans mentioned.

For the next steps:

• Sadly, I won't have time to re-work this provisioner before August (need to integrate the changes done for 1.7.3, polish, maybe integrate galaxy, add unit test coverage, ...).
• My own idea is still to introduce this feature in Vagrant 1.8.0, if the release schedule is not too short. I defer to @mitchellh or @sethvargo to confirm the roadmap.

PS: I might close this PR and start a new one, based on a new freshly rebased branch. I feel that some people have been using this branch to run self-patched version of Vagrant. If yes, please let us a not here and we won't delete this branch until this feature is officially released, thanks!

[mkuzmin]

@gildegoma, next Vagrant release will take many months, or maybe a year. Your plugin is incomplete, but it's already useful, even in its current state.

Can you publish it as a standalone Vagrant plugin? That would allow my developers start using it right now, you'll get more feedback, and I will be able to help with pull requests.

[gildegoma]

@mkuzmin I understand your point, but at the moment I unfortunately don't have time (i.e. no urgent need) to extract and maintain it as a plugin. By DRY'ing the code with the current remote provisioner, it also closely link this development to the Vagrant core project. Of course, if you (or someone else) want to use this codebase to create a plugin, feel free and let us know to see how we can help in the future).

So, meanwhile, I see the following variants (the first one is quite easy to setup actually):

• Use a shell provisioner with script in charge to locally install and run Ansible on the target VM (e.g. look at https://github.com/Phansible/phansible implementation for Windows host)
• Try https://github.com/jaugustin/vagrant-ansible-local
• Try https://github.com/vovimayhem/vagrant-guest_ansible

Sorry for the delays!

[gildegoma]

Closed in favour of #6500.

[gildegoma]

Please note that the branch gildegoma/2103-ansible-local will be kept alive until #6500 is merged.

[gildegoma]

This is a friendly (pedantic) reminder:

The gildegoma/2103-ansible-local branch will be deleted at the end of the month. All the features are now merged in master and will be available in upcoming Vagrant 1.8.0.