# pre\_tasks and tags...

**URL:** <https://forum.ansible.com/t/pre-tasks-and-tags/13100>\
**Category:** Ansible Project\
**Created:** [July 11, 2013, 1:21pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100 "2013-07-11T13:21:54Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![seanosh](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@seanosh](https://forum.ansible.com/u/seanosh)\
**Post date:** [July 11, 2013, 1:21pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/1 "2013-07-11T13:21:54Z")

</div>

Hey all,

Assuming the following example playbook:

- name: run common tasks against all hosts…  
hosts: all

pre\_tasks:

- name: hello world!  
shell: echo ‘hello world’ \> /tmp/hello

roles:

- { role: ‘common’, tags: [‘common’] }

When I execute the playbook without specifying any tags, the “hello world” task is executed. When I specify tags (to say, limit to a subset of specific tasks I’d like to run), the pre\_tasks get skipped. Is this by design/intentional? Could just be me assuming functionality here, but I look at the logic and think any tasks in ‘pre\_tasks’ would be executed regardless of whether or not any tags were specified…

Thanks!

---

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [July 11, 2013, 3:49pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/2 "2013-07-11T15:49:27Z")

</div>

Excerpts from seanosh's message of 2013-07-11 09:21:54 -0400:

> Could just be me assuming functionality here, but I look at the logic  
> and think any tasks in 'pre\_tasks' would be executed regardless of  
> whether or not any tags were specified...

When you specify tags, ansible will run \*only\* the tasks with the  
specified tags. In other words, tags can be used only to \_limit\_ the  
set of tasks run. Untagged tasks are run unconditionally.

If you think about it makes sense: in your given example, if no tags are  
specified, both your pre\_tasks and role tasks are run; when you specify  
the tag 'common', only the role tasks get run. If it worked the way you  
are expecting, then in your example, whether you specified the tag  
'common' or not, the same result would occur. Which seems weird to me  
at least. On the other hand, given how it does work, there's no  
super-clean way to mark tasks as needing to be run unconditionally,  
except by making sure \*every\* task is tagged, one way or another (e.g.,  
with a throw-away tag that you always specify whenever you specify any  
tags.

If you find yourself in that situation, I'd recommend rethinking your  
mental model: the whole point of playbooks is to map hosts to tasks, so  
if you're trying to make one playbook map a single set of hosts to more  
than one set of tasks, it may mean you actually want two or more  
separate playbooks...

---

<div class="post-metadata">

**Author:** ![seanosh](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@seanosh](https://forum.ansible.com/u/seanosh)\
**Post date:** [July 11, 2013, 4:54pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/3 "2013-07-11T16:54:17Z")

</div>

Hey Morgan,

Thank you for your response. Inline:

> Excerpts from seanosh’s message of 2013-07-11 09:21:54 -0400:
> 
> > Could just be me assuming functionality here, but I look at the logic  
> > and think any tasks in ‘pre\_tasks’ would be executed regardless of  
> > whether or not any tags were specified…
> 
> When you specify tags, ansible will run _only_ the tasks with the  
> specified tags. In other words, tags can be used only to _limit_ the  
> set of tasks run. Untagged tasks are run unconditionally.

Right, totally get that.

> If you think about it makes sense: in your given example, if no tags are  
> specified, both your pre\_tasks and role tasks are run; when you specify  
> the tag ‘common’, only the role tasks get run. If it worked the way you  
> are expecting, then in your example, whether you specified the tag  
> ‘common’ or not, the same result would occur. Which seems weird to me  
> at least. On the other hand, given how it does work, there’s no  
> super-clean way to mark tasks as needing to be run unconditionally,  
> except by making sure _every_ task is tagged, one way or another (e.g.,  
> with a throw-away tag that you always specify whenever you specify any  
> tags.

To me, “pre\_” specifies a “before” state for actions nested under it. If I wanted/needed a way to run a task early and have it only run under certain tags, I would’ve gone with “tasks” and then tagged them accordingly. So then, for me, it begs the question - what would “pre\_tasks” do differently than if I had just put “tasks” in that same spot?

I guess what I’m expecting is that pre\_ and post\_tasks behave in a “setup” and “teardown” type way… they’re always executed as part of the playbook (maybe a setup command to run a custom module that does some fact gathering, maybe a teardown command that uses the “campfire” module to notify a room that tasks have completed successfuly).

Using [https://github.com/ansible/ansible-examples/blob/master/lamp\_haproxy/rolling\_update.yml](https://github.com/ansible/ansible-examples/blob/master/lamp_haproxy/rolling_update.yml) as an example, let’s say I only wanted to update an Apache config. I don’t need the whole playbook re-executed top to bottom when I know what I’m after, so I’ll use tags to limit that (unless this is an incorrect mental approach to take to such things). In that example, none of the the pre\_ or post\_ tasks would fire since I narrowed the scope with the tag.

Ultimately if I have to tag the pre\_ tasks with all the other tags to ensure their execution, then I guess that’s what it needs to be - just pointing out it’s not immediately clear that it’s needed for pre\_ and post\_ tasks. If there’s an agreement there I’ll happily contribute by updating the documentation and creating a PR to prevent any future confusion.

> If you find yourself in that situation, I’d recommend rethinking your  
> mental model: the whole point of playbooks is to map hosts to tasks, so  
> if you’re trying to make one playbook map a single set of hosts to more  
> than one set of tasks, it may mean you actually want two or more  
> separate playbooks…

Right, totally get that as well, but that’s not what I’m doing. I have hosts that should have “common” tasks executed against them and for other hosts, say “webservers” - those grab their own “roles” as well - which from what I understand is how it’s recommended to be done based on the examples repo and the “Best Practices” README.

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [July 11, 2013, 5:11pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/4 "2013-07-11T17:11:17Z")

</div>

If I wanted/needed a way to run a task early and have it only run under

> certain tags, I would've gone with "tasks" and then tagged them  
> accordingly. So then, for me, it begs the question - what would "pre\_tasks"  
> do differently than if I had just put "tasks" in that same spot?

"tasks" run after roles, "pre\_tasks" run ​​before roles. you have to keep  
in mind that roles are basically nothing more than some automation around  
tasks, in a more portable way.

The order in in which tasks are executed are:

&nbsp;&nbsp;pre\_tasks:  
&nbsp;&nbsp;roles:  
&nbsp;&nbsp;tasks:  
&nbsp;&nbsp;post\_tasks:

> I guess what I'm expecting is that pre\_ and post\_tasks behave in a "setup"  
> and "teardown" type way... they're always executed as part of the playbook

That's just not how it works.  
​​

> Using  
> [https://github.com/ansible/ansible-examples/blob/master/lamp\_haproxy/rolling\_update.ymlas](https://github.com/ansible/ansible-examples/blob/master/lamp_haproxy/rolling_update.ymlas) an example, let's say I only wanted to update an Apache config. I don't  
> need the whole playbook re-executed top to bottom when I know what I'm  
> after, so I'll use tags to limit that (unless this is an incorrect mental  
> approach to take to such things). In that example, none of the the pre\_ or  
> post\_ tasks would fire since I narrowed the scope with the tag.

That's because in this example, none of the pre\_ and post\_tasks are  
tagged.​​ Also, I'm not sure which tags you would use here, as the  
apache\_common and web roles do not have any tags in their tasks. (  
lamp\_haproxy\<[https://github.com/ansible/ansible-examples/tree/master/lamp\_haproxy&gt](https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy&gt);  
/ roles\<[https://github.com/ansible/ansible-examples/tree/master/lamp\_haproxy/roles&gt](https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy/roles&gt);  
/ base-apache\<[https://github.com/ansible/ansible-examples/tree/master/lamp\_haproxy/roles/base-apache&gt](https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy/roles/base-apache&gt);  
/ tasks\<[https://github.com/ansible/ansible-examples/tree/master/lamp\_haproxy/roles/base-apache/tasks&gt](https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy/roles/base-apache/tasks&gt);  
/ \*main.yml\* etc...)

> Ultimately if I have to tag the pre\_ tasks with all the other tags to  
> ensure their execution, then I guess that's what it needs to be - just  
> pointing out it's not immediately clear that it's needed for pre\_ and post\_  
> tasks.

AFAIK, it's nowhere mentioned that \*tasks and roles behave differently as  
far as tags are concerned​.

> If there's an agreement there I'll happily contribute by updating the  
> documentation and creating a PR to prevent any future confusion.

Better documentation is always good :)​​

&nbsp;&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [July 11, 2013, 8:48pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/5 "2013-07-11T20:48:30Z")

</div>

“When you specify tags, ansible will run _only_ the tasks with the  
specified tags. In other words, tags can be used only to _limit_ the  
set of tasks run. Untagged tasks are run unconditionally.”

This statement is not quite correct. If you have 3 out of 57 steps tagged “go” and run --tags go, it will run 3 steps.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [July 11, 2013, 8:50pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/6 "2013-07-11T20:50:25Z")

</div>

If I may summarize, it sounds like you are using pre and post tasks for load balancing, specified some tags, and the pre and post tasks were not tagged with anything, so they didn’t run, and this was not intuitive.

I generally don’t think pre tasks _should_ be exempt from tag filtering (as that would be confusing too) but we should probably make a note of this in the documentation, so that if people are running rolling updates they can be aware to specify a tag for those tags and also include them.

---

<div class="post-metadata">

**Author:** ![seanosh](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@seanosh](https://forum.ansible.com/u/seanosh)\
**Post date:** [July 11, 2013, 9:29pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/7 "2013-07-11T21:29:25Z")

</div>

Thank you Michael and Serge for the replies… Inline:

> If I may summarize, it sounds like you are using pre and post tasks for load balancing, specified some tags, and the pre and post tasks were not tagged with anything, so they didn’t run, and this was not intuitive.

Yup, that’s it - just not for load balancing. I have a custom module that grabs facts I want available to any play (regardless of tag) via an external API. Since I assumed that pre\_tasks behaved like a ‘setup’ task, I figured that’d be the best place for it. I’ll just go a different route. Thanks for your responses!

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [July 11, 2013, 9:30pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/8 "2013-07-11T21:30:54Z")

</div>

I’d tag your pre and post tags with something like “lb” for now and remember to include them when you specify tags, maybe?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [July 11, 2013, 9:32pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/9 "2013-07-11T21:32:34Z")

</div>

Ticket opened to upgrade docs: [https://github.com/ansible/ansible/issues/3505](https://github.com/ansible/ansible/issues/3505)

---

<div class="post-metadata">

**Author:** ![seanosh](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@seanosh](https://forum.ansible.com/u/seanosh)\
**Post date:** [July 11, 2013, 9:39pm UTC](https://forum.ansible.com/t/pre-tasks-and-tags/13100/10 "2013-07-11T21:39:11Z")

</div>

Right, that works. This ends up prompting me to do some tag cleanup (a good thing!) to keep tags manageable so that they can be attached to pre\_tasks and also only consider loading these facts when I need them (vs. having them for any playbook execution). Thanks for your suggestion!
