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

nigelgbanks opened this Issue Jan 4, 2016 · 26 comments


None yet

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

Code Responsible:

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

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

@nigelgbanks nigelgbanks added a commit to nigelgbanks/vagrant that referenced this issue Jan 5, 2016
@nigelgbanks nigelgbanks Support Ansible 2.0 detection using ansible_local provisioner.
Addresses issue: mitchellh#6793

Now ansible_local provisioner can detect ansible 2.0 install.

Changed to the conditional check to look for the commands rather than execute them.

@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 gildegoma self-assigned this Jan 6, 2016
@gildegoma gildegoma added this to the 1.8.2 milestone Jan 6, 2016

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.


Will do!

On Wednesday, January 6, 2016, Gilles Cornu

Less "critical" issue, because ansible/ansible#12020
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.

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

Nigel Banks


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

Problem not solved yet.

@nigelbanks hold on with tests ;)


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 commented Jan 13, 2016

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


@fquffio no worries :)


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.


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!


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 gildegoma added a commit that referenced this issue Jan 13, 2016
@gildegoma gildegoma update CHANGELOG for GH-6793 e5e5057

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 gildegoma added bug has-pr and removed thinking labels Jan 13, 2016
@gildegoma gildegoma closed this in c2c1a44 Jan 13, 2016

Possible Workarounds for ansible_local provisioner (until Vagrant 1.8.2 is released) are the following:

  • Manually apply the patch to your Vagrant 1.8 installation
  • Use Vagrant box with a preinstalled version of Ansible 1.9.x
MasonM commented Jan 18, 2016

Here's another workaround that you can put in your Vagrantfile that patches /usr/bin/ansible-galaxy so it doesn't require an action. It's a horrible hack, but it's easier than patching Vagrant or making a custom box. Make sure it comes before any other provisioners.

# Patch for
config.vm.provision "shell" do |s|
    s.inline = '[[ ! -f $1 ]] || grep -F -q "$2" $1 || sed -i "/__main__/a \\    $2" $1'
    s.args = ['/usr/bin/ansible-galaxy', "if sys.argv == ['/usr/bin/ansible-galaxy', '--help']: sys.argv.insert(1, 'info')"]

edit: Update so it doesn't error if you don't have Ansible installed. In that case, you'll have to provision twice for this to work.


Thanks @pgscandeias and @MasonM for the workarounds! I also ran into this issue today.


@gildegoma - Do you know if 1.8.2 will be released soon, with this fix? I've been getting a steady rise of emails and issues filed since people started rebuilding environments on Windows now that Ansible 2 is out :(


@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 Fixing ansible/ansible#12004 should also receive enough attention in my opinion.

@gitebra gitebra pushed a commit to gitebra/vagrant that referenced this issue Jan 26, 2016
Jonas Johansson Merge commit 'b454fdc8d3009d171bb77220c4e0ad9a5cf9ead1'
* commit 'b454fdc8d3009d171bb77220c4e0ad9a5cf9ead1':
  Fix typo
  Use SSL and HTTPS links where appropriate
  Add structured data
  Fix mobile issues
  Tabs to spaces
  Merge docs and www into a single static site
  provisioners/ansible_local: fix #6763
  Backslash-escape `*` character.
  Add note about using `visudo` to edit `sudoers`.
  update CHANGELOG for GH-6793
  fixing incorrect missing ansible error
  add chef installer for suse
  #6794 Add to doc trick how to define locale for SSH session in Vagrant file
@FGtatsuro FGtatsuro added a commit to FGtatsuro/packer-environment-vagrant that referenced this issue Jan 31, 2016
@FGtatsuro FGtatsuro Add a workaround to use Ansible 2.x in Vagrant. 36a42d6
Jeewes commented Feb 3, 2016

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

@marvinpinto marvinpinto added a commit to marvinpinto/ansible-role-authy-ssh that referenced this issue Feb 8, 2016
@marvinpinto marvinpinto Add a basic vagrantfile to enable quick iteration
Note that the `ansible==1.9.4` here is due to work around
mitchellh/vagrant#6793 for now.

That will likely be un-necessary after vagrant 1.8.2 is released.
@geerlingguy geerlingguy referenced this issue in geerlingguy/drupal-vm Feb 9, 2016

Mark current release as not working #423

@FGtatsuro FGtatsuro added a commit to FGtatsuro/packer-environment-vagrant that referenced this issue Feb 14, 2016
@FGtatsuro FGtatsuro 'ansible' provisioner doesn't have the issue mitchellh/vagrant#6793. e98f62d

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
for more information.

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

@MasonM MasonM added a commit to MasonM/hssonline_vagrant that referenced this issue Mar 8, 2016
@MasonM MasonM Add workaround for mitchellh/vagrant#6793 7b5a035
@Radau Radau added a commit to Radau/DigitalOcean-Starbound-Backup-and-Restore that referenced this issue Mar 8, 2016
@Radau Radau Set up Vagrant provisioning with Ansible Galaxy 2.0 Patch from mitche… 6b46eaf
ilyapoz commented Mar 14, 2016

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 which is too old I guess

ilyapoz commented Mar 14, 2016

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

put before ansible provision

dacodekid commented May 11, 2016 edited

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.


@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
  echo '#!/usr/bin/env bash
  /usr/bin/ansible-galaxy "$@"
  exit 0
  ' | sudo tee $GALAXY
  sudo chmod 0755 $GALAXY
likwid commented May 11, 2016

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

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

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

robr3rd commented Jun 6, 2016

@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 commented Feb 8, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment