Executing tasks before and after roles now possible - set_up, tear_down

Archives Ansible Project
1

As you may remember, roles are a 1.2 feature that allow for easy modularity and reuse of playbook steps.

I encountered something today where I wanted to do some tasks before a role was invoked and then after a role was invoked.

I came up with this:

https://github.com/ansible/ansible/blob/devel/examples/playbooks/roletest.yml

The whole point of this is to be able to apply a role in a play for rolling updates.

Rolling updates of course worked before, but with the ability of free tasks surrounding the role to only come after the role steps, it wasn’t sufficient to use roles inside the rolling update idiom.

So basically, in set_up, you would have

  • signal outage window for host

  • take host out of load balancer

Then you would apply your roles and any loose tasks

and in tear_down, you would have

  • put host back in load balancer

  • end outage window for host

Naturally this is just a new thing that makes roles easier to use, and you don’t have to use it and it doesn’t affect your existing playbooks if you don’t.

Though I think this kind of being able to split out pre and post steps in a play could be useful for some people.

Let me know if this makes sense or not :slight_smile:

2

To make things simpler, I’m going to rename ‘set_up’ to ‘pre_tasks’ and ‘tear_down’ to ‘post_tasks’.

Teardown to put something back in production feels like a weird word to use.

3

This is all done.

I’ve also upgraded things such that handlers now trigger in between sections (like pre_tasks and tasks, and so on).

This means that restarts triggered by handlers now work logically before you put them back into a rotation, so you do not have to use tests with register + when to see when an item is changed, to restart it early.

There’s an internals trick to how this works if you want to use it yourself for any reason, and really want to run handlers “right now”.

tasks:

  • foo…

  • blarg…

  • meta: flush_handlers

  • baz…

  • glorp…

4

Hi,

Thank you for mentioning this internal trick. It is handy and flexible.

Otherwise a generalized idea for pre_tasks, roles, tasks and post_tasks is to introduce user-definable stages, although to me something like flush_handlers seems like a better solution (you do not have to define them explicitly, specify their order and just put it where you need it).

Greetings,
gw

5

Yeah we are not doing user defined flush-stages. That sounds like it would be approaching fluid dynamics.