Also, I don't believe tags are like sets of tasks that might contain
other sets of tasks. Instead, tags are independent sets without any
intersections. In your example, if the db_server role contained a
tasks/main.yml that looked like this:
- include: db_server.yml
tags=db_server
Then, specifying the tag db_server_role would do nothing. Instead,
you would have to specify the tags db_server_role,db_server. Of course,
you could just specify the tag db_server in the first place. The point
is to be careful about tags defined within a role because they must all
be specified explicitly to run all the role.
* John Jarvis <[email protected]> [2014-04-23 11:16 -0400]:
> Another option is to tag your role from the play like this:
>
>
> site.yml
> ...
> roles:
> - common
> - role: db_server
> tags: db_server_role
> - web_server
> tags: web_server_role
>
> $ ansible-playbook.yml ... site.yml --tags db_server_role
>
> This is useful (in the example above) when you don't want to run the
> tasks in the common role and you have other roles that require common
> vars.
> The only problem with this approach is that I don't believe the tags
> will propagate if you have a role with dependencies or other includes.
>
> -John
>
>
>
>
> On Wed, Apr 23, 2014 at 11:08 AM, Aaron Hunter <[email protected]>
> wrote:
> > Thanks for the reply Michael. I think that would work. However, it's getting
> > complicated since I've implemented your recommendation for handling
> > environments using groups
> > (https://groups.google.com/forum/#!searchin/ansible-project/inventory$20staging/ansible-project/jd3cuR7rqCE/v7jaH-_BAgAJ).
> > I now have a "production" group and a "staging" group. Mixing in roles via
> > includes seems like its overloading the groups concept more than I would
> > like.
> >
> > By the way, this has gotten me thinking about Ansible's conceptual model,
> > that is hierarchy of Ansible's object from the user's perspective. I
> > understand the relationship between host, group, and role objects but when
> > it comes to "site", inventory, and the top of the model it gets a bit murky.
> > Do you have something like as UML class diagram that shows this model? The
> > reason I ask is that I'm thinking a new object such as an "environment" at
> > the top (or perhaps under a "site") might be a simpler way than groups to
> > manage production, staging, etc.
> >
> > Site
> > - 1..n Environment
> > - 1..n Groups
> > - 1..n Hosts
> >
> >
> > --Aaron
> >
> >
> >
> >
> > On Wednesday, April 23, 2014 10:26:55 AM UTC-4, Michael DeHaan wrote:
> >>
> >> It's unlikely we'd want to add more CLI options for this purpose.
> >>
> >> However, there are easy workarounds if you would like this behavior.
> >>
> >> Consider your site.yml (a file that configures all of your infrastructure)
> >> if it were like this:
> >>
> >> - include: webservers.yml
> >> - include: dbservers.yml
> >> - include: other.yml
> >>
> >> If you want to run just servers in the "dbservers" role, instead of
> >> running site.yml, just run "dbservers.yml" instead.
> >>
> >> This trick is using playbooks to include other playbooks (because a
> >> playbook is just, in the end, a list of plays in order).
> >>
> >> --Michael
> >>
> >>
> >> On Wed, Apr 23, 2014 at 10:19 AM, Aaron Hunter <[email protected]>
> >> wrote:
> >>>
> >>> While testing I often want to limit my run to a specific role. I know
> >>> limiting can be done by host and by tag but did you ever consider adding a
> >>> "-r" limit by role option to the ansible-playbook command?
> >>>
> >>> Thanks,
> >>> Aaron
> >>>
> >>> --
> >>> 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 [email protected].
> >>> To post to this group, send email to [email protected].
> >>>
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/ansible-project/0bc34a77-fc27-4791-a65a-b4d2174201d1%40googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > 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 [email protected].
> > To post to this group, send email to [email protected].
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/ansible-project/b877cbe4-f013-4615-b82b-a8ddfdcd0d92%40googlegroups.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CADPH6PLD6%3DM8W6T5Dy34omKEwux4KytwWXZ%3Db%3DAw%2Bzf3kUuT-A%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
Marc Tardif <[email protected]>
Freenode: cr3, Jabber: [email protected]
1024D/72679CAD 09A9 D871 F7C4 A18F AC08 674D 2B73 740C 7267 9CAD
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/20140423172142.GF7254%40jrrr.
For more options, visit https://groups.google.com/d/optout.
