I think I'd be open to it, depending on patch complexity.
On Fri, Jul 11, 2014 at 3:30 PM, Dmitry Makovey <droopy4...@gmail.com>
wrote:
> On Wednesday, July 9, 2014 4:50:55 PM UTC-6, Michael DeHaan wrote:
>>
>> "Now the other question: would it be reasonable to ask for such feature
>> then? "
>>
>> It would not :)
>>
>> I think it makes much more sense to explicitly tag things.
>>
>> For instance, think of flickr.com and I tag all pictures in an album
>> "vacation", I don't have the ability to take another album and tag pictures
>> "not vacation" in such a way that the vacation tag doesn't pick them up.
>>
>> Being able to say "don't run these tags" if of course what --skip-tags
>> does, and we can do that.
>>
>
> It appears I should've been clearer with my question: "would it be
> reasonable to include feature that allows selective use of role's tasks?"
>
> So right now we can do { role: roleA, tags: tagX } which, if I understood
> things correctly applies tagX to all tasks under roleA. What I'm asking is
> something more like:
> { role: roleA, use-tags: tagY } which would be similar to the CLI "--tags"
> except localized down to a roleA only and exectuting *only* tasks tagged
> tagY from roleA.
>
> My usecase: I've got playbook that does both install and setup. However
> install should really be ran once and setup, well, as many times as I
> please :) for each role in my playbook I'd like to use common vars and some
> of the files, like templates and scripts. So, I would like to be able to
> write 2 playbooks: 1st_run.yml that uses "normal" role notation and invokes
> all the tasks under that role, and then "setup.yml" which would use above
> mentioned syntax for role: { role: roleA, use-tags: setup }. Passing
> --tags with CLI is a bit too blunt for the cases where I want all tags to
> run for roleB, for example. use of "when" and conditional vars for the
> same purpose becomes cumbersome as now I have to handle mutiple "when"
> statements for some tasks etc. Tags IMO present a way more elegant solution.
>
> With above explanation, I'd like to restate my question: would it be
> reasonable to expect such feature in Ansible?
>
> --
> 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/f235c0cf-9103-41e5-a4b2-612223cd1560%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/f235c0cf-9103-41e5-a4b2-612223cd1560%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%2BnsWgzWunwWhYw8HfoKzxRab6fhCFg1uxq%3DADA-RE9FuQaMRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
