For example if I have a playbook like this:
`
// site.yml
–skip-tags always, but if you have any tasks tagged ‘always’ that overlap with the ‘postgres’ tag, they won’t run either.
Which means there is no nice workaround to this problem. Do you think it would make sense to introduce a new special tag for this situation, or do you have a better suggestion?
No workaround, but not sure that this merits a new directive as separating the plays can easily get around this limitation (and then including them in general playbook to use the other way).
Splitting the whole site into smaller playbooks doesn’t help in this case, since I want to run a role on a whole site. I don’t want to think on which host/group the role is applied, I just want to apply it on all hosts which have it.
Also I don’t see making playbooks just based on roles, it’s possible to do it like that, but if you have a lot of hosts, it’s highly unlikely. One of the reasons you have roles is to easily use them in different plays.
Would it be possible to add something similar to roles, e.g. a special
tag always_role or always_with_role, or whatever sounds better, so
that a task with that tag is run if any of the tasks in a role are
executed?
It seems like you could work around this by adding a tag like that
yourself, and including that tag when you run Ansible. Change 'always' in
your role to 'common_vars' or whatever, and then run
ansible-playbook site.yml -t postgres,common_vars
if you want the vars from the common role, and just drop the 'common_vars'
tag if you don't.
You have to remember to include the common_vars tag every time you run
with any other tag; if you want to include it most of the time, maybe
create a shell function like
ansible-playbook () { /usr/bin/ansible-playbook $* -t common_vars ; }
and run /usr/bin/ansible-playbook when you don't want '-t common_vars'
automatically tacked on. (Or call the shell function something else, but
if you don't want to have to remember to type something new, or whatever.)
-Josh (jbs@care.com)
(apologies for the automatic corporate disclaimer that follows)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.
Hi Josh,
Thanks for the suggestion, but you missed the point which is probably because I didn’t explain it correctly. I don’t want to execute tasks from a ‘common’ role when I’m executing the ‘postgres’ role, I only want to execute the ‘postgres’ role.
My problem is that I would like to somehow tag some tasks in a role so that they are executed if any of the tasks in that role are also executed because of some tag in that role. E.g. I have a include_vars task in a role and I have tasks in that role which are tagged with ‘postgres_config’, I would like that the include_vars task is run with that ‘postgres_config’ tag and every possible tag in the postgres role, but I don’t want to update tags of that that include_vars task every time I add a new tag in a role.
if you don’t want tasks to run always … don’t use the always tag …
I’ll do that anyway, just asking how to make a task run always if any task in a role is executing, but now that I think about it, we don’t have that many tags in roles anyway, so I’ll just list them all.
Thanks for the suggestion, but you missed the point which is probably
because I didn't explain it correctly. I don't want to execute tasks
from a 'common' role when I'm executing the 'postgres' role, I only
want to execute the 'postgres' role.
Right, I imagined you having two high-level use cases:
(1) You want to run just the 'postgres' role, and none of the tasks in the
'common' role.
(2) You want to run things that include some of the tasks in the 'common'
role -- and when you do, you want to run the include_vars task as well.
So my suggestion was that if you tag the include_vars task with a tag like
'common_vars', you can then get that task when you want it, and not when
you don't -- you just have to add that tag when you do want it, as opposed
to getting it always except when you don't want it. So e.g. if you wanted
to run tasks in the 'common' role with some other tag, like 'common_foo',
that's when you'd do
ansible-playbook site.yml -t common_foo,common_vars
This is slightly more annoying than having the include_vars task have an
'always' tag, because if you forget, and leave off the 'common_vars' tag,
then it won't get run; that's the problem that the shell function idea was
meant to work around.
Anyway, it sounds your other workaround should work as long as you don't
mind having to put all of the other tags from all of the other tasks in
the common role (all the common_foo stuff) on the include_vars task. But I
think my suggestion would work if there were too many tags for that to be
maintainable, so I figured I'd mention it (among other things, in case
someone else comes across this thread in the future).
-Josh (jbs@care.com)
This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.