playbook pause and tag madness!

225 views
Skip to first unread message

Steve Kieu

unread,
Mar 23, 2015, 8:52:19 PM3/23/15
to ansible...@googlegroups.com
Hi all,

Sorry for the rant but I get through this and think that with that matter ansible is quirky.

1. First roles with tags not work as expected (yes saw some post and people saying you need to agg at the command line

My play book like this

- name: ctn
  hosts: staging-web
  roles:
    - { role: web_base, tags: ['install-php'] }

It executed who whole role no matter the tags is there.

2. Task and Roles unexpected behaviour.

Example I have

- name: DO something
  hosts: myhost
  tasks:
    - pause:
  roles:
    - web_base

If doing like this the tasks and pause is not executed. The role is executed and I did not wait until role finsihed to see if the task is touched at all.

So I have to split them like this, but why do I need to?

- name: do something
  hosts: myhost
  task:
   - pause:

- name: ditto
  hosts: myhost
  roles:
    - myrole

Now it is not enough. The that playbook if I play without the options tags=XXX then it prompts me. But with teh option --tags=XXX then it does not pause me anymore, Why the --tags option affect how the playbook order of execution?

See be low is my playbook and if play without --tag=install-php then it prompts me to warn, But if I specified the tag it skip the prompt (pause) but then play everything rather than only this tags.

It is a mess!

cat update-php.yml
---

# ansible quirks. If you set tasks and then add roles section after that the tasks is not executed, only roles. Thus no pausing happened. To fix need another play and specify the roles. The tags in role does not do anything, still need to put --tags=XX at commandline.

- name: Update PHP to latest version on remi repo. You need to run this play book with option --tags=install-php other than that it will replay the whole playbook
  hosts: staging-web
  tasks:
    - pause: prompt='*** WARNING *** You need to run this play book with option --tags=install-php other than that it will replay the whole playbook. Abort now if you forgot' minutes=10

- name: ctn
  hosts: staging-web
  roles:
    - { role: web_base, tags: ['install-php'] }

# vim:expandtab ts=2 sw=2

Anyone please let me know what I do wrong or thinking wrongly (not the way ansible thinks - Or is it a bug/features??)

Please....

Steve Kieu

unread,
Mar 23, 2015, 8:57:59 PM3/23/15
to ansible...@googlegroups.com

Ironically If I remove the tags: ['install-php'] in the role and then it behaves better that it only play that tags.

Again it still skip the pause for not any reason.

Serge van Ginderachter

unread,
Mar 24, 2015, 3:28:44 AM3/24/15
to ansible...@googlegroups.com
Steve,


1. First roles with tags not work as expected (yes saw some post and people saying you need to agg at the command line

​Well, if you tread those posts, why are you still expecting tags to work in another way than people explained you already?​
 

My play book like this

- name: ctn
  hosts: staging-web
  roles:
    - { role: web_base, tags: ['install-php'] }

It executed who whole role no matter the tags is there.

​tags are applied to the whole role here, they do not select​
 
​parts of the role​

2. Task and Roles unexpected behaviour.

Example I have

- name: DO something
  hosts: myhost
  tasks:
    - pause:
  roles:
    - web_base

If doing like this the tasks and pause is not executed. The role is executed and I did not wait until role finsihed to see if the task is touched at all.

​If you did wait, you would see "tasks" are executed after roles.

See docsite/rst/playbooks_roles.rst for the order of pre_tasks, pst_tasks, roles, tasks, ...
 
So I have to split them like this, but why do I need to?

​No, you don't. You want to use pre_tasks instead of tasks>
 

Now it is not enough. The that playbook if I play without the options tags=XXX then it prompts me. But with teh option --tags=XXX then it does not pause me anymore, Why the --tags option affect how the playbook order of execution?

​It does not affect the order, it affects which tasks get run, being the ones that are tagged. Obviously you have those tags within the role, son only those ar ran.​
 

See be low is my playbook and if play without --tag=install-php then it prompts me to warn, But if I specified the tag it skip the prompt (pause) but then play everything rather than only this tags.

It is a mess!

cat update-php.yml
---

# ansible quirks. If you set tasks and then add roles section after that the tasks is not executed, only roles. Thus no pausing happened. To fix need another play and specify the roles. The tags in role does not do anything, still need to put --tags=XX at commandline.

- name: Update PHP to latest version on remi repo. You need to run this play book with option --tags=install-php other than that it will replay the whole playbook
  hosts: staging-web
  tasks:
    - pause: prompt='*** WARNING *** You need to run this play book with option --tags=install-php other than that it will replay the whole playbook. Abort now if you forgot' minutes=10

- name: ctn
  hosts: staging-web
  roles:
    - { role: web_base, tags: ['install-php'] }

# vim:expandtab ts=2 sw=2

Anyone please let me know what I do wrong or thinking wrongly (not the way ansible thinks - Or is it a bug/features??)

​Feature!

The first play has no tags, the second only a role that gets all tasks tagged with "install-php"​
 

​So only the latter come to run.​




​   Serge​

Martin

unread,
Mar 24, 2015, 4:15:17 AM3/24/15
to ansible...@googlegroups.com

Hi,

(Now this is just a theoretical point. Actually changing that stuff would probably break too much existing stuff)

actually I think there's a point to the pre_task,roles,post_task stuff.

It makes perfect sense once you found that section in the docs, on the other hand one of the big promises of ansible is simplicity and (to me) a big point here is that the following seems reasonable and should just work:

# typing on a cell but you get the idea (hopefully)
name: play
tasks:
  debug:
    msg: this runs first
roles:
  - {role_that_runs_second}
tasks:
  debug:
    msg: this runs last

/Martin


--
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/CAEhzMJD-BfpWztYp9KW1W3oJJ8A%2BHrqbUh3NN5O%3Dpkk0jxw%3DVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Serge van Ginderachter

unread,
Mar 24, 2015, 4:20:17 AM3/24/15
to ansible...@googlegroups.com

On 24 March 2015 at 09:15, Martin <mar...@marcher.name> wrote:
It makes perfect sense once you found that section in the docs, on the other hand one of the big promises of ansible is simplicity and (to me) a big point here is that the following seems reasonable and should just work:


​Well, it's YAML, and YAML translates that to a dictionary, and a dictionary is not ordered...​

There are limits to simplicity.

Martin

unread,
Mar 24, 2015, 6:20:16 AM3/24/15
to ansible...@googlegroups.com

I'm not talking about the underlying technical spec just that I understand the expectations of the OP.

Maybe a solution would be to put this information somewhere in the documentation where it is more visible?


regards,

Martin


--
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-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAEhzMJB_-%3DrqL8vqLrD_Ra%2BD07t75o_WeyNxR4h%2BXSrSgxbwOw%40mail.gmail.com.

Serge van Ginderachter

unread,
Mar 24, 2015, 6:29:42 AM3/24/15
to ansible...@googlegroups.com

On 24 March 2015 at 11:20, Martin <mar...@marcher.name> wrote:
Maybe a solution would be to put this information somewhere in the documentation where it is more visible?


​Agreed, it might help to explain that the order in which you write the different tasks​ blocks, don't affect the execution order. Same for all yaml keys.

    Serge
Reply all
Reply to author
Forward
0 new messages