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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 [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/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 [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%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 [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/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 [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/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 [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%2BnsWgwWGXZOw08dkBhU81Lu5d%2B1pM7PDvP5vHc9JkYs3_087Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
