step through a playbook

I had an idea for a feature when I was debugging an old playbook on a new type of host.

I would love to be able to do per-action confirmation before execution for a playbook.

something like:

ansible-playbook --ask myplaybook.yml

and then have it ask for a 'y/n' before every action it will take. So I can step around a known problem, for example.

Is that completely ridiculous or something folks might find useful? Seems like it would only require a pre-execution callback of some kind - which I'm not sure we have yet - but might be do-able.

-sv

I like having the option, what do others think? (I'm tentatively
thinking this is called --step-through)

This could possibly be implemented by interlacing calls to the pause
module between tasks, not sure if that's the easiest route though.

something like:

ansible-playbook --ask myplaybook.yml

and then have it ask for a 'y/n' before every action it will take.
So I can step around a known problem, for example.

Incredibly useful, for beginners and for debugging. Yes, please!

        -JP

Strongly agree. This would be very useful.
I suggest to call the option --step.

+1

I've implemented this and
here's a Pull request for
it.

https://github.com/ansible/ansible/pull/2354

I implemented it in the simplest way I could think of - as always I'm
willing to be told that this way was not a good idea :slight_smile:

-sv

Very useful, not just for debug, but even for certain sensitive deployments

Michael mentioned something to me today that might be worth trying to
do.

if we number each task in a playbook sequentially (starting from 1).

we could do something like

ansible-playbook --step --start-from 23 someplaybook.yml

which would skip the first 22 actions and start on #23 stepping through
them.

almost like breakpoints :wink:

-sv

if we number each task in a playbook sequentially (starting from 1).

we could do something like

ansible-playbook --step --start-from 23 someplaybook.yml

which would skip the first 22 actions and start on #23 stepping through
them.

almost like breakpoints :wink:

I want that! Thinking that numbering is ok, but how about adding a
label?

        - name: do something
          action: shell echo foo
          label: debug1

I could add a label when I want to start breakpointing:

        ansible-playbook --start-from debug1 someplaybook.yml

Anyhow, breakpoints would really be nice to have!

        -JP

soo name: as a label? tags may also work.

soo name: as a label? tags may also work.

name: contains (can contain) white space. Difficult, no?

        -JP

feels like a label HAS to be unique.

a tag could be a group of things (or more like a tag on a picture, like
in flickr)

labels == unique to the action
tags == groups of actions or of plays, etc

-sv

Would be tempted to call it 'breakpoint' since that its what its being used for.

K

yah - but I can imagine it being used for other things not just
debugging.

<shrug>

@mdehaan - you have a suggestion on if this is all crackrock?

-sv

The number requires a playbook run to know what number to use. This
makes it fine in some cases but harder in others.

I'd say take a name (or even a fnmatch), it's not like you can't quote
it, and start running on the first name that matches.

(BTW, assume it is implied but --start-at-task should not require --step)

Using 'name' avoids adding new syntax and having to explain to users what the difference between a 'name' and a 'label' is. Using 'name' also means '--start-at-task' can be used on an unmodified playbook. Plus I'd generally think task names are likely to be unique across a playbook run (or at least that would be a best practice). Can think of a case where it makes much sense to use the same name twice -- it would make interpreting the output a bit tricky.

K

names are not actually required, are they?

what does ansible stick in there when a name is not specified? Just the
last name?

-sv

names are not required.

Ansible sticks in the task command line, with global variable
substitution, but not inventory variable substitution.

Also, if you are using the short or complex variable forms, it's hard
to guess what that string is, true.

--Michael

So that means if you want to use --start-from you need to give an
action a name?

I wonder how an unnamed action shows up in --step with a complex
variable form.

bet that's a treat to see...

oh well - simple fix for the person who complains - put in a name.

-sv

I'd go for using fnmatch on name (or action if name is absent) if people want to step through (and using breakpoints) they can add something unique to the name if they really want to have a guaranteed single breakpoint.

The clear benefit is that if you want to e.g. debug an NTP related issue, there's a high chance that using 'ntp' in the fnmatch will simply do the right thing out of the box.

In this case I would even go for a case-insensitive match.