How do you set up a confirmation prompt before running a playbook?

[maticm1]

How do you set up a confirmation prompt before running a playbook?

I'd like to have to enter "YES" before the playbook makes any changes to hosts. Right now I have the following code in site.yml, but it's not working.

  vars_prompt:
  - name: "confirmation"
    prompt: "Are you sure you want to run this playbook? Answer with 'YES'"
    default: "NO"
    private: no
    failed_when: "confirmation != YES"

[Amr Ali]

First of all failed_when doesn't work for vars_prompt only for tasks..

here is what you could do :

- hosts: all

  any_errors_fatal: yes

  vars_prompt:

    name: "confirmation"
    prompt: "Are you sure you want to run this playbook? Answer with 'YES'"
    default: "NO"
    private: no

  tasks:

    - name: Check Confirmation

      fail: msg="Playbook run confirmation failed"

      when: confirmation != "YES"

note the use of any_errors_fatal, this is important because otherwise the check task will only fail for the current host only, this makes the whole playbook fails on any errors.

problem with this is that it's not foolproof for instance if you did confirm the run and any of your tasks failed, it'd fail the whole playbook as opposed to the default behavior of taking out the just the host that failed.

the only way to counter this is to use  when: confirmation == "YES" in all your tasks, instead of using a primary "Fail Task", a bit ugly but a safer route depending on your use case.

also if you go  the "Fail Task" route keep in mind that this won't work if your playbook uses roles, in this case use a pre_tasks instead of a normal tasks.

[Michael DeHaan]

Another nice shortcut that is a bit of syntactic sugar for "fail + when" is the assert module.   It's a little weird because it has the "that" in there but we needed a key name for the argument.

- assert: 

    that:

      - "confirmation == 'YES'"

OR:

- assert: { that: "confirmation == 'YES' }

etc

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/600eb96a-95cd-46c1-ad9e-8293b97457b6%40googlegroups.com.

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

[Outsider]

This got me thinking that we kinda need an action to mimic any_errors_fatal in a task, would be very helpful in cases like this.. where you need to trigger a whole playbook failure conditionlly without affecting the default failure behavior.. anything like that in the works? 

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/gDzrZVQ3AMw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxQ3d-%2BouBr2YezD-no0N%2BiJsegq_m5stKycU6QOvaJ_A%40mail.gmail.com.

[Outsider]

Maybe a fail_all module or a modification of the current fail module to add an all argument?

[Michael DeHaan]

I'd be open to a param on the fail module for that.

Not entirely sure what the plumbing throughout the stack might be to get it done.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEgsm8P3hdxe5TXkfzdsu27GD2AUHq5VxbN1LAf%2B0icVk_kSUQ%40mail.gmail.com.

[Amr Ali]

Yeah me neither, will have a look tonight, we can't just throw/raise an ansible error right?

[Michael DeHaan]

I think a AnsibleError on one host won't be enough.

It may be required to add some flag to a ReturnData and then when that is processed back in playbook code land, that might need to throw the error there.

Should be easy to experiment though.

On Sat, Aug 2, 2014 at 2:22 AM, Amr Ali <amre...@gmail.com> wrote:

Yeah me neither,  will have a look tonight,  we can't just throw/raise an ansible error right?

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/17a50efc-12a6-42d2-baf6-7139a634d54c%40googlegroups.com.

[Amr Ali]

Yes throwing an error in the module didn't work, i have actually dropped the whole idea about raising an error, since it halted the playbook midway without showing the aggregated stats at the end.

here is the pull request : #8410