Non-private prompts in Ansible not working

[mpolden]

Using non-private prompts in Ansible provisioning won't work when running provisioning with vagrant provision.

With non-private prompts the input will be echoed, but hangs after hitting enter at the prompt. Private prompts behave correctly.

Non-private prompts behave correctly when running ansible-playbook directly. My guess it has something to do with how Vagrant handles stdin in the Ansible provisioner.

To reproduce:

1. git clone https://github.com/martinp/vagrant-ansible-prompts
2. Run vagrant up
3. When the provisioning prompt appears, enter something at the prompt and hit enter
4. Provisioning won't proceed

Vagrant 1.4.3
Ansible 1.4.4
OS X 10.9.1

[geerlingguy]

Confirmed here, too... I was about to do the exact same thing you did, @martinp, but luckily a quick google search found your repo, then this issue.

[mpolden]

@geerlingguy Which platform are you using? I'm trying to determine if this issue is specific to OS X.

[geerlingguy]

OS X, specifically Mavericks 10.9.1 and 10.9.2 beta.

[joetsoi]

@martinp, we've bumped into this for our packaging for the CKAN project. I'm using a fedora host building onto an ubuntu vm, I'm using the fedora repo's ansible rpm at the moment, I will experiment with other versions when I get some time.

[gildegoma]

See lib/ansible/callbacks.py

Like any other Ansible private prompts (e.g. --ask-pass, --ask-sudo-pass, --ask-vault-pass, --ask-su-pass) private variable prompt relies on getpass.getpass function, which handles well to be piped by Vagrant when executing ansible-playbook from the host.

Other user prompts (e.g. --step) are based on raw_input python built-in function, which does not work with Vagrant integration. After google/stackoverflow quick search (see this example), it seems quite difficult/tricky to solve this problem without any change on Ansible side.

I only verified on OS X, but I suppose it will behave the same on a Linux host.

Except if @mitchellh has an idea about how to easily tweak the childprocess stdin pipe for python's raw_input, I think we have to close this one as wontfix and document this limitation.

Note that in #3396, I also want to evaluate if Vagrant support for all (existing) interactive prompt options (e.g. ansible.ask_sudo_pass) should not be deprecated/removed. Main arguments in favor of this possible change are following:

• Avoid documentation/usage confusions like the one reported here.
• Avoid documentation/usage confusions when introducing guest-based mode (Support Ansible “Local Playbooks” #2103), which cannot support these interactive options.
• All the prompts based on getpass will still be available for "advanced usage" via ansible.raw_arguments.

[geerlingguy]

Not allowing any kind of prompts would really take away from the integration of Vagrant with Ansible; I am currently able to prompt users for a network credential during the build process, so they can do things like grab a particular file from an NFS share, or mount an SMB volume.

It would be awesome if we could get non-private prompts working too, but it sounds like that might be a tall order. Is there something like getpass.getpass Ansible could use that would work with Vagrant and non-private prompts (I'm not a python dev, so I don't know much about what's available)? The Ansible project is pretty open to changes as long as they're well-reasoned and don't break things...

[gildegoma]

@geerlingguy thanks for your feedbacks!

Not allowing any kind of prompts ...

It is not question to prevent prompts, but (for sake of dear simplicity) to maybe not officially support these Ansible features (passing prompt args via ansible.raw_arguments or play's private var_prompt will still work when provisioning from the host). For me, the question is open about which approach is better/simpler for Vagrant ease of use... please comment/vote on #3396.

It would be awesome if we could get non-private prompts working too, [...] The Ansible project is pretty open to changes as long as they're well-reasoned and don't break things...

Of course, it would be an optimal solution for Vagrant integration and I can figure out some other "piped usages" where it could also make sense. Though it is not a priority issue for me, but please let us know if you start the discussion on Ansible mailing list...

[KyleJamesWalker]

Work around for me. I only needed vars_prompt when pushing to remote servers, so it wasn't needed when provisioning locally with ansible and vagrant. And if you define the variable with extra_vars ansible will skip the prompt. It's a little less flexible but good enough for me when working locally.

Vagrantfile

  config.vm.provision :ansible do |ansible|
    ansible.playbook = "deployment/playbook.yml"
    ansible.inventory_path = "deployment/hosts-vagrant"
    ansible.extra_vars = {
      repo_branch: "master"
    }
  end

playbook.yml

  .
  .
  .
  vars_prompt:
    # Warning this will not work with Vagrant (non-private)
    # defined within the Vagrantfile to omit prompt.
    - name: "repo_branch"
      prompt: "Github branch"
      default: "master"
      private: no

[mitchellh]

Closing in favor of guidelines in #3396

[gildegoma]

This is a little note for people hitting an unexpected TypeError: encode() argument 1 must be string, not None when using private vars_prompt with Ansible 1.7.x and the Vagrant provisioner.

This problem

• is not present in previous versions (up to Ansible 1.6.x)
• was introduced by ansible/ansible@346bb61
• will be fixed in next release of Ansible (1.8) ansible/ansible@c8494cd
• can be bypassed by running PYTHONIOENCODING='utf-8' vagrant provision

/cc @maspwr

[btiernay]

Or put the following in your Vagrantfile:

ENV['PYTHONIOENCODING'] = "utf-8"