That's a REALLY REALLY good proposal, though I'm worried a bit that changing the purposes of the flag might break an existing use case of check mode with tags.
Hindsight is definitely 20/20 though, and "always_run" should have probably had the word "check_mode" in there somewhere to make it clear at least. Something like a "select_tags" or "use_tags" is probably what we'll have to do. On Mon, Jul 28, 2014 at 7:33 PM, Jaime Gago <gagoja...@gmail.com> wrote: > IMHO This is somewhat related to the "always_run" option which at this > point in time is _only_ meant to override the "dry run" mode (--check) and > execute the task no matter what. Unfortunately that doesn't seem to work > with --tags (i.e. a task marked with "always_run" won't be executed if the > playbook is ran with a tag the task doesn't have). Since it seems the > direction is not to extend the "always_run" option to also work with tags > but instead modify core Ansible to be able to use a conventional "always > run" tag then I'd vote for the "always_run" option to be renamed. > > Personally I would have preferred to keep it as an option to a task > instead of a dedicated tag, first we already have an "always_run" option > and its name says it all in terms of what one would expect it to do to a > task. > Second with a conventional tag we will for the first time (unless I missed > something) have to be _careful_ with how we pick our tags and that seems > like a slippery slope. Imagine the newbie that didn't read the specific 2 > lines that says "if you use tag <foo> then that task will always be run no > matter what", nothing will let him know when he picks that tag that it's > doing something internally (i.e. always running the tasks), granted we > could had something to the output e.g. "This task tagged to always run", > still though it leaves room for human error. > My point being with an "always_run" *option* I have to explicitly call it > as part of my playbook logic, tags as far I was concerned were always > metadata to be leveraged during a playbook run; adding a "special" tag > feature, however simple, breaks that rule and IMHO moves tags in the wrong > direction. > > My $.02 meh. > > J. > > > > On Tuesday, May 13, 2014 1:50:54 PM UTC-7, Michael DeHaan wrote: > >> Good deal. >> >> This is marked a "P3" ticket, so it's in queue once we get the P2's >> smited down properly.... not too far away, hopefully! >> >> >> >> >> On Tue, May 13, 2014 at 4:35 PM, Peter Gehres <peter....@appdynamics.com> >> wrote: >> >>> I believe there is a pull request for an "all" tag at >>> https://github.com/ansible/ansible/pull/7039 >>> >>> >>> On Tue, May 13, 2014 at 12:53 PM, Michael DeHaan <mic...@ansible.com> >>> wrote: >>> >>>> You should be tagging such tasks with something like 'core' like you >>>> say above, for now. >>>> >>>> We would entertain an 'all' tag if well implemented, which I believe >>>> we've also said before. >>>> >>>> "So what should I be doing here?" >>>> >>>> Submitting a pull request? :) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, May 13, 2014 at 3:49 PM, Snyder, Chris <chris_...@sra.com> >>>> wrote: >>>> >>>>> How do you always have a set of tasks run regardless of the tag >>>>> being passed in on the command line? >>>>> >>>>> >>>>> >>>>> I’m getting to the point where I have a ‘core’ playbook that must be >>>>> run before any other playbook I have. This does specific things such as >>>>> set specific facts based upon my local environments or OS distro that are >>>>> to be used by all my later roles. However, when I use ‘—tags do_this’ or >>>>> ‘—tags do_that’ tasks/roles executed in my core playbook are ignored >>>>> because they aren’t tagged with ‘do_this’ or ‘do_that.’ >>>>> >>>>> >>>>> >>>>> It doesn’t seem reasonable (or scalable) to me to modify my core >>>>> playbook and add every possible tag I can ever use, nor does it seem >>>>> reasonable to force my fellow admins to always run Ansible with ‘—tags >>>>> core,do_this’ or ‘—tags core, do_that’ when they only want a particular >>>>> tag >>>>> to be executed. >>>>> >>>>> >>>>> >>>>> It really feels to me that Ansible is missing some way to say ‘this >>>>> task/role/whatever REQUIRES this other code to be run as well’. >>>>> >>>>> >>>>> >>>>> It seems I’m not alone in this – there’s some calls for similar >>>>> functionality here: >>>>> >>>>> * https://github.com/ansible/ansible/issues/3157 >>>>> >>>>> * https://github.com/ansible/ansible/pull/7039 >>>>> >>>>> >>>>> >>>>> So what should I be doing here? >>>>> >>>>> >>>>> >>>>> Thx >>>>> >>>>> Chris. >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 ansible-proje...@googlegroups.com. >>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>> >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/ansible-project/BFD6B7398AEB474A9A28B39B9B5D00 >>>>> CB588B283D%40SRAexMBX05.sra.com >>>>> <https://groups.google.com/d/msgid/ansible-project/BFD6B7398AEB474A9A28B39B9B5D00CB588B283D%40SRAexMBX05.sra.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 ansible-proje...@googlegroups.com. >>>> To post to this group, send email to ansible...@googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/ansible-project/CA%2BnsWgxPzOSt%2B5k40dZ%3Dhp% >>>> 3DrmQf1338m8TaBj-y1VubQubw6zA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxPzOSt%2B5k40dZ%3Dhp%3DrmQf1338m8TaBj-y1VubQubw6zA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Peter Gehres >>> Site Reliability Engineer | AppDynamics, Inc. >>> www.appdynamics.com | AS62897 >>> >>> -- >>> 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 ansible-proje...@googlegroups.com. >>> To post to this group, send email to ansible...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/ansible-project/CABpn%2BqSHT7VJN-9ex61DngHWFnKEW2bjjzQGdu_t1Yc% >>> 3DmWQmQw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/ansible-project/CABpn%2BqSHT7VJN-9ex61DngHWFnKEW2bjjzQGdu_t1Yc%3DmWQmQw%40mail.gmail.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 ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/b8db389a-55bf-4675-b0b3-7e01102eefd6%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/b8db389a-55bf-4675-b0b3-7e01102eefd6%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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwWGXZOw08dkBhU81Lu5d%2B1pM7PDvP5vHc9JkYs3_087Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
