This is about the ninth time this has been asked in the last few weeks :) ... I am guessing nobody reads the other posts :)
There's been a bit of a proposal for a new keyword "use_tags", which I'm not against, if reasonably minimal. Might be a PR already. On Tue, Jul 22, 2014 at 6:13 PM, Greg Swift <[email protected]> wrote: > So I apparently was going the wrong route with my thoughts on how tags in > roles and playbooks interacted. I was thinking that when you referenced > the tags when bringing in the role you were limiting the role, not tagging > it inside the playbook. > > In my head what this enabled was the ability to have a very config > management oriented role that could cover all facets of whatever the role > was related to, preferably laid out in such a way that the end state of > running an non-limited manner ended with everything installed, configured, > and running. > > Then with the same role you would then be able to modularly utilize > specifically related tasks in the role based on tags, which benefits > related orchestration playbooks. This specifically appeals to me for the > purpose of having ready to run playbooks to hand off to our dev and ops > teams. > > Its now obvious to me that I was thinking about this wrong[1] and the > second I actually tried to use it this way it all fell apart. I have two > roles[2][3] that are setup with tags to support this methodology, and > isolating them in a playbook and using the tag restrictions of the cli, > this works. > > I've got an example of what I was originally doing wrong, and what I'm > proposing as a thought of role/tag behavior inside playbooks in a gist[4]. > > In the playbook there is some functionality thats not in upstream yet, but > there is an associated PR[5] for it. > > I feel this is a reasonable use case, but is there a better way for me to > accomplish the same thing? Would there be interest in supporting this > feature? (I'm open to working on it if I can find the time. > > > thanks > > greg > > [1] re-reading the related documentation was a slap in the face, because > the associated text is rather obvious about the behavior. > [2] https://github.com/gregswift/ansible-plight > [3] https://github.com/kost/ansible-galaxy.ubuntu.puppet > [4] https://gist.github.com/gregswift/a1c72dfd70f6736b6748 > [5] https://github.com/ansible/ansible/pull/7260 > > -- > 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/5526a993-39ac-43bc-b0c0-46b6e8cc460a%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/5526a993-39ac-43bc-b0c0-46b6e8cc460a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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/CA%2BnsWgyEeCMF_7Ec-dxj4eg0L_s-h8C4SE0NEy9gBQng1ZALbw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
