Ok it was someone filing an RFE, not a PR - good catch. yes, code would be welcome.
The "use_tags" thing was what I had proposed in the thread. On Wed, Jul 23, 2014 at 10:07 PM, Greg Swift <[email protected]> wrote: > I did skim through the extensive PR list looking for one, and didn't find > it, but could quite easily have missed it. Is there a good way to search > PRs? There are 59 issues with 'tags role' when searching. I only noticed > one similar, and it is the use_tags one[1]. > > I'll conceed that I did not search the group, i hadn't even actually > joined until i submitted this so thats my bad. I did find this thread on > with_tags [2], but it also seems to have a negative response, and by the > end they took different routes that seem to me to be more convoluted > (having to add when statements and define variables.. basically 'tags > light' imo). > > What would you define as reasonably minimal? > > -greg > > [1] https://github.com/ansible/ansible/issues/8231 > [2] > https://groups.google.com/forum/#!searchin/ansible-project/tags$20role/ansible-project/hSR8CVcxHwE/XO59ewUgWSoJ > > > On Wednesday, July 23, 2014 4:53:31 PM UTC-5, Michael DeHaan wrote: > >> 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/c538b3ce-e043-459c-8039-3d4f36a10d58%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/c538b3ce-e043-459c-8039-3d4f36a10d58%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%2BnsWgxz355Txfx9Eso2c5KcvDvAExpzh0W_7RFkzWg%2BmkjcaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
