Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-private prompts in Ansible not working #2924

Closed
mpolden opened this issue Feb 1, 2014 · 11 comments
Closed

Non-private prompts in Ansible not working #2924

mpolden opened this issue Feb 1, 2014 · 11 comments

Comments

@mpolden
Copy link

mpolden commented Feb 1, 2014

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
Copy link
Contributor

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
Copy link
Author

mpolden commented Feb 24, 2014

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

@geerlingguy
Copy link
Contributor

OS X, specifically Mavericks 10.9.1 and 10.9.2 beta.

@joetsoi
Copy link

joetsoi commented Feb 28, 2014

@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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Collaborator

@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
Copy link

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
Copy link
Contributor

Closing in favor of guidelines in #3396

@gildegoma
Copy link
Collaborator

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

btiernay commented Nov 2, 2014

Or put the following in your Vagrantfile:

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants