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

Ansible 2.0 prompts for vars_prompt when --extra-vars is used #13770

Closed
chlunde opened this issue Jan 8, 2016 · 5 comments · Fixed by #13772
Closed

Ansible 2.0 prompts for vars_prompt when --extra-vars is used #13770

chlunde opened this issue Jan 8, 2016 · 5 comments · Fixed by #13772
Labels
bug This issue/PR relates to a bug.
Milestone

Comments

@chlunde
Copy link

chlunde commented Jan 8, 2016

Issue Type

Bug Report

Ansible Version

2.0 from the "stable-2.0" branch, commit 91c7691

$ ansible --version
ansible 2.0.0
  config file =
  configured module search path = Default w/o overrides
Ansible Configuration

No changes

Environment

RHEL 7

Summary

Ansible 2.0 stops execution and requests the user to enter variables specified with vars_prompt even if the same variable has been specified on the comand line.

Ansible 1.9.4 does not prompt for vars_prompt if --extra-vars specifies the same variable.

Steps To Reproduce:
playbook.yml
---
- hosts: all
  gather_facts: False
  vars_prompt:
    - name: x
      prompt: 'Enter value for x'
  tasks:
    - local_action: debug var=x
$ cat inventory
localhost

$ ansible-playbook -i inventory playbook.yml -e x=1
Expected Results:

Non-interactive run, as on 1.9.4:

$ ansible-playbook --version
ansible-playbook 1.9.4
  configured module search path = None

$ ansible-playbook -i inventory playbook.yml -e x=foo

PLAY [all] ********************************************************************

TASK: [debug var=x] ***********************************************************
ok: [localhost -> 127.0.0.1] => {
    "var": {
        "x": "foo"
    }
}

PLAY RECAP ********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0
Actual Results:

The user is prompted:

$ ansible-playbook -i inventory playbook.yml -e x=foo
Enter value for x:
@bcoca
Copy link
Member

bcoca commented Jan 8, 2016

so there is code that checks for this (and it used to work) https://github.com/ansible/ansible/blob/devel/lib/ansible/executor/playbook_executor.py#L114

But for some reason play.vars is now always empty.

@bcoca bcoca added this to the v2 milestone Jan 8, 2016
bcoca added a commit to bcoca/ansible that referenced this issue Jan 8, 2016
pushed it to use the existing propmpt from display and moved the vars prompt code there also for uniformity
changed vars_prompt to check extra vars vs the empty play.vars to restore 1.9 behaviour
sipmlified the code as it didn't need to check for syntax again (tqm is made none prior based on that)
fixes ansible#13770
@bcoca
Copy link
Member

bcoca commented Jan 8, 2016

@chlunde can you test the PR above and confirm the fix?

@chlunde
Copy link
Author

chlunde commented Jan 8, 2016

Thanks! It works as expected on my playbook now.

bcoca added a commit that referenced this issue Jan 8, 2016
pushed it to use the existing propmpt from display and moved the vars prompt code there also for uniformity
changed vars_prompt to check extra vars vs the empty play.vars to restore 1.9 behaviour
sipmlified the code as it didn't need to check for syntax again (tqm is made none prior based on that)
fixes #13770
@ThomasSteinbach
Copy link
Contributor

Where is this behavior documented? I can't find anything in the official docs.

@bcoca
Copy link
Member

bcoca commented Apr 27, 2016

Since extra vars have higher priority than play vars, it makes sense that there is no need to prompt for a value you have already overridden. Still, we should make note in vars_prompts docs about this.

@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug This issue/PR relates to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants