Add vars_prompt: to pause module

[Javier Candeira]

I was about to open an issue that the prompt to vars_prompt did not
interpolate my variables. Then, after doing a couple more tests, I
realised it is because vars_prompt runs very early, before even setup
does.

There is a need for a vars_prompt that runs later in a play, with access
to play-generated variables? This is my scenario:

1. Play runs, and through its run it creates a var with the name of a
database it's going to delete.
2. User gets prompted something like vars_prompt: db2: "I'm about to
delete {{db1}}. Enter the db's full name to confirm"
3. The play only deletes the database when: db1 == db2.

In -project, James Cammarata said:

> Regarding [1 and 2], it would seem that running the data gathered during the vars_prompt through the template engine might be the best/easiest solution, though we can continue to discuss it on -devel.

The problem is that not what to do with the data gathered at
vars_prompt. In cases such as the above scenario, the user can only
learn what to type after the play has generated other variables. So
the vars_prompt has to run after other plays, not before as it does
currently.

In IRC discussion with drybjed and bbhoss, this is a possible solution:

Add the vars_prompt: type of lookup to the pause module, so pause has
both prompt: for yes/no, and vars_prompt: for strings input at the
keyboard.

Sounds good?

J

[Michael DeHaan]

It seems that to get it to prompt where you want, you'd really need a "vars_prompt" kind of task.

In this case, while pause does this, I like playbooks to be explicit.

How about making an action plugin called "prompt" ?

Then it would be easy to do this, and while prompt would also pause, it might be more explicit as you could insert this where you needed to go.

I accepted the patch to save the input to the pause module because it's a one-liner, but I don't think we need to make it standard.

I think the "prompt" module would be a combination of ideas from both "pause" and "set_fact", something of a hybrid.

This way you would also not need to use register with it.

Maybe like

prompt:  variable=foo prompt="enter the self destruct code for {{x}}" ?

I think for most people vars_prompt is sufficient, but I like the idea that it would be a regular action.  OTOH, there's a lot of stuff about secrets and password re-entry in vars prompt that probably aren't going to be duplicated here -- and maybe should be.  Moving them into common functions might be advisable.

--Michael

J

--
You received this message because you are subscribed to the Google Groups "Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-deve...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Javier Candeira]

Hi, Michael. Makes lots of sense. Will try to provide a pull request.

J

[Kesten Broughton]

Did this ever make it in?

I would find a task-level vars_prompt very handy.

kesten

[Mridusmita Talukdar]

Hi,

Is there an update on this? When can we expect this feature to be released?

We need something similar to this.

Thanks,

Mridu

[Michael DeHaan]

Nope,

There's been a decided emphasis in automation in Ansible and asking questions at task level is not something we really want to do.

However, you can still ask vars_prompt questions at play level and use those variables throughout tasks.   You just can't ask questions in roles.

And really, that's what I would like to enforce -- if a lot of Galaxy roles start asking questions, I can see that being annoying :)

For more options, visit https://groups.google.com/d/optout.