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 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.