ansible_local provisioner can't detect ansible 2.0 install due to changed exit codes

[nigelgbanks]

ansible_local provisioner can't detect ansible 2.0 install due to changed exit codes.

Code Responsible:
https://github.com/mitchellh/vagrant/blob/25ff027b08582978981ed28754a3fed21953a90e/plugins/provisioners/ansible/provisioner/guest.rb#L35-L65

Example Ansible 1.9.4

ansible --version && ansible-galaxy --help 2>1 > /dev/null && echo $? && ansible-playbook --help 2>1 1> /dev/null && echo $? 

ansible 1.9.4
configured module search path = None
0
0

Example Ansible 2.0.0

ansible --version && ansible-galaxy --help 2>1 > /dev/null && echo $? && ansible-playbook --help 2>1 1> /dev/null && echo $?

ansible 2.0.0 (devel a2120a3d63) last updated 2016/01/02 21:06:18 (GMT +000)
lib/ansible/modules/core: (detached HEAD 5777c28f50) last updated 2016/01/02 21:06:25 (GMT +000) lib/ansible/modules/extras: (detached HEAD 14b81df29c) last updated 2016/01/02 21:06:29 (GMT +000)
config file = /etc/ansible/ansible.cfg
configured module search path = /opt/ansible/library

[gildegoma]

@nigelgbanks Thanks for reporting this integration issue (which is still present in Ansible 2.0.0.rc3)

This problem is actually caused by a bug in Ansible 2.0 (beta): ansible/ansible#12004.

Most probably this issue won't be resolved for the Ansible 2.0.0, so we might have to adopt a safer (more resilient) way to sanity-check the Ansible installation...

[gildegoma]

Less "critical" issue, because ansible/ansible#12020 has been merged right now :)

@nigelgbanks please give a try with latest state of devel branch, or with upcoming Ansible 2.0 RC4.

[nigelgbanks]

Will do!

On Wednesday, January 6, 2016, Gilles Cornu [email protected]
wrote:

Less "critical" issue, because ansible/ansible#12020
ansible/ansible#12020 has been merged right now
:)

@nigelgbanks https://github.com/nigelgbanks please give a try with
latest state of devel branch, or with upcoming Ansible 2.0 RC4.

—
Reply to this email directly or view it on GitHub
#6793 (comment).

Nigel Banks
[email protected]

[gildegoma]

ansible/ansible#12020 has been reverted due to annoying side effect: ansible/ansible#13743

Problem not solved yet.

@NigelBanks hold on with tests ;)

[gildegoma]

Since Ansible 2.0.x has landed with this behavior (code 5 returned), vagrant should be adapted.

The fix proposed by @mintwax (ansible-galaxy setup --help via #6858) sounds go to me, and I added it to #6800 (marked for Vagrant 1.8.2)

[fquffio]

Sorry, I just opened and self-closed the third clone for this issue. I came here just to say "me too!", and to point out that this issue is the same for both host.rb and guest.rb, hence both ansible and ansible_local providers are affected, right now. 😄

[gildegoma]

@fquffio no worries :)

[geerlingguy]

Another 'me too', but the ansible provider has been working for me without issue—it just seems ansible_local is throwing people for a loop.

[pedrotypes]

Another 'me too'. I've been scratching my head all day around an unchanged Vagrantfile and playbook which suddenly stopped working. Glad you folks found the issue!

[pedrotypes]

So this is hacky and inelegant, and I'll be improving it, but for now it got me out of a tight spot:

In my Vagrantfile, I install pip and in turn use it to install ansible 1.9.2, which works fine:

config.vm.provision "shell", inline: "sudo apt-get install -y python-pip python-dev && sudo pip install ansible==1.9.2 && sudo cp /usr/local/bin/ansible /usr/bin/ansible"

Hope it's of use to someone. Cheers!

[gildegoma]

Thanks for all the comments above!

@geerlingguy you're right, this only affects ansible_local provisioner (the ansible remote provisioner doesn't check in such details the Ansible setup on the Vagrant host system).

I picked the #6869 fix into my #6800 "ansible bug fixes" general PR (I'll do some more stuff in this branch for 1.8.2).

[gildegoma]

@geerlingguy Sorry I don't have any information about the release due date. I can only recommend you to take contact with Hashicorp support.

I know that many Ansible/Vagrant users are now awaiting for Vagrant 1.8.2, but I just like to stress that this situation is originally caused by an unexpected breaking change in Ansible 2.0.0.0. Fixing ansible/ansible#12004 should also receive enough attention in my opinion.

[Jeewes]

Milestone 1.8.2 seems to be completed by this PR. When can we expect 1.8.2 version to be released?

[ShenZhouHong]

I can confirm that the issue exists for vagrant version 1.8.1 running on an OSX host machine. I wish you luck in fixing this issue soon. I tried to use @MasonM's workaround and it generated the following output, and does not work :(

==> default: Running provisioner: shell...
    default: Running: inline script
==> default: stdin: is not a tty
==> default: Running provisioner: ansible_local...
    default: Installing Ansible...
The Ansible software could not be found! Please verify
that Ansible is correctly installed on your guest system.

If you haven't installed Ansible yet, please install Ansible
on your Vagrant basebox, or enable the automated setup with the
`install` option of this provisioner. Please check
https://docs.vagrantup.com/v2/provisioning/ansible_local.html
for more information.

I made sure to add the snippet before any other provisoners, as mentioned.

[ilyapoz]

Can you please summarize: for which combinations of vagrant/ansible versions this is reproducible and what is the official workaround for this? I will try downgranding ansible via ansible.version =, but not sure whether this will succeed.
upd: noo good, ubuntu/trusty64 box only cotnains ansible 1.7.2 besides 2.0.1.0 which is too old I guess

[ilyapoz]

Ok. I read the thread a bit more carefully.
Patching vagrant goes against "vagrant up is enough" idea, which I think is very important, so not an option. Ansible 1.9 turned out to be not an option for me because I depend on some 2.0's modules.
MansonM's workaround I don't see working because it should be run after installing ansible but before running it, so I came up with this workaround (tested for ubuntu/trusty64 box):

config.vm.provision :shell, inline: <<SCRIPT
GALAXY=/usr/local/bin/ansible-galaxy
echo '#!/usr/bin/env python2
import sys
import os

args = sys.argv
if args[1:] == ["--help"]:
  args.insert(1, "info")

os.execv("/usr/bin/ansible-galaxy", args)
' | sudo tee $GALAXY
sudo chmod 0755 $GALAXY
SCRIPT

put before ansible provision

[dacodekid]

For ansible_local the provided info patch didn't work for me. When I tried running the command alone on the VM, receiving the below error (which might be Ansible issue I assume)

╰─$ ansible-galaxy info --help
  File "/usr/local/bin/ansible-galaxy", line 2
    import sys
    ^
IndentationError: unexpected indent

So, I just commented the whole block instead.

# @machine.communicate.execute(
#   "ansible-galaxy info --help && ansible-playbook --help",
#   :error_class => Ansible::Errors::AnsibleNotFoundOnGuest,
#   :error_key => :ansible_not_found_on_guest)

UPDATE: Recreated the VM & this time there was no "unexpected indent" error.

[saumets]

@ilyapoz Thanks! This helped us.

We streamlined it a little more with simple bash in case it helps anyone else:

config.vm.provision :shell, inline: <<SCRIPT
  GALAXY=/usr/local/bin/ansible-galaxy
  echo '#!/usr/bin/env bash
  /usr/bin/ansible-galaxy "$@"
  exit 0
  ' | sudo tee $GALAXY
  sudo chmod 0755 $GALAXY
SCRIPT

[likwid]

That doesn't work for me for whatever reason, I had to use this syntax for heredoc:

config.vm.provision :shell, inline: <<-SCRIPT
  GALAXY=/usr/local/bin/ansible-galaxy
  echo '#!/usr/bin/env bash
  /usr/bin/ansible-galaxy "$@"
  exit 0
  ' | sudo tee $GALAXY
  sudo chmod 0755 $GALAXY
SCRIPT

[janzenz]

@likwid Thanks this worked for me. I'm on OSX El Capitan.

[robr3rd]

@janzenz (and for those wondering, such as I was): The difference between the "simple bash" scripts provided by @skalfyfan and the updated one from @likwid + the reason why only the one from @likwid would work for you is that @skalfyfan used the Ruby Heredoc syntax that MUST be ended at the beginning of a newline (<<SCRIPT), whereas @likwid's (<<-SCRIPT, note the hyphen) could be ended at any point on a line.

The most likely scenario that I can imagine here would be that this would present itself if these are nested (i.e. indented) at all in your Vagrantfile, so if you're closing the non-hyphen <<SCRIPT Heredoc and it is not at the beginning of a new line (i.e. if you have it indented at all) then it is technically a Ruby Heredoc syntax error and therefore would not work properly.

FWIW, I immediately put the content of that Heredoc into a standalone Bash script and provided it as a file to the Shell provisioner rather than doing it inline as it was cleaner in my particular implementation. Notably, doing it this way I avoided any such Heredoc issues since I was able to strip them out and just add the raw Bash.

[jeremyn]

This is a note for people who come here through a web search. I want to use Ubuntu 16.04 as both host and guest with the official-repository-provided Vagrant v1.8.1 and Ansible v2.0.0.2, which means I get the problem described in this issue if I use the Ansible Local provisioner.

The following snippet using the Shell provisioner approximates the Ansible Local provisioner:

  $inline_script = <<-INLINE_SCRIPT
    sudo apt-get install -y ansible
    cd /vagrant
    ANSIBLE_FORCE_COLOR=true ansible-playbook --inventory="localhost," playbook.yml
  INLINE_SCRIPT
  config.vm.provision "shell", inline: $inline_script, privileged: false, keep_color: true

You can find something like this used in one of my projects here. ANSIBLE_FORCE_COLOR is discussed here.

[jswetzen]

Your snippet wasn't working for me @jeremyn, because the guest couldn't ssh to itself. I modified it to work without ssh, with -c local.

  $inline_script = <<-INLINE_SCRIPT
    sudo apt-get install -y ansible
    cd /vagrant
    ANSIBLE_FORCE_COLOR=true ansible-playbook -i="localhost," -c local playbook.yml
  INLINE_SCRIPT
  config.vm.provision "shell", inline: $inline_script, privileged: false, keep_color: true

[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.