On Monday, February 4, 2019 at 12:10:51 AM UTC+11, Kai Stian Olstad wrote: > > On 03.02.2019 01:53, Igor Cicimov wrote: > > Kai, why would I use vars when I already have tags on my tasks which > > purpose, and only purpose, is filtering during execution? > > Filtering is done on the command line with --tags not inside a playbook > or task file. >
That's correct ... and have you tried doing so? In the below example: - roles: - role1 - role2 - role3 where all 3 roles have the same tags, lets say "instal" and "configure", how are you going to filter the "install" tag for the role1 only? If you need any other functionality, variables is the way to go. > Yeah like in the example you gave above: --- - include_tasks: install.yml when: test_install | default(true) == true - include_tasks: configure.yml when: test_configure | default(true) == true so you end up with separate file for each tag you have, good luck with that. > > > Also as I said back in 2015 > > https://groups.google.com/d/msg/ansible-project/WimzDEJLHJc/9U10Yjb4CQAJ > > it > > is hard to retrofit variables into hundreds of playbooks you have > > written > > with tags expecting they will serve the purpose they exist for, *which > > is > > filtering*. > > They do, the filtering is done on the command line. > Tags on a role in a playbook is adding the tags to all the task in the > role. > Which is wrong and useless. > So it pretty uniform, tags in in task files and playbooks is adding that > tag to the task. > Filtering is done at run time on the command line. > > > > From where I stand, the "tags" option that we can pass to the role like > > this: > > > > - roles: > > - { name: role1 tags: ["tag1","tag2"] } <== this *IS/SHOULD BE* > > equivalent to a command line > > Why should it, in my opinion this will make it pretty confusing for when > tags add a tag and when it's filtering on tags. > Simple, there should had been *tags*, *skip-tags* and *add-tags*, genius isn't it :-) > > > is pretty much useless since instead filtering the role's tasks based > > on > > that "tags" list it adds those tags to each of them. Really not sure > > how is > > this helping me in any way and what would be the use case or advantage > > I > > get from doing this? I mean if I wanted those tags in a role I would > > have > > included them in its tasks already ... or am I missing something? > > The functionality is that if you want to run a few of the role(s) in a > playbook, add a tag to the role and filter the tag on the command line. > I use this feature a lot, a playbook have have tens of roles and I just > want to run one or two of them, so changing that will destroy my and > everyone else's use of tags. > Why would you include a role in a playbook that you don't need executed I wonder??? > If you download a role from Galaxy you don't want to change the tags in > the role because that makes it very hard to download newer version of > that role. > But you can at least add your own tags on the role so you can filter to > run or not run the role when the playbook is running. > Have never seen any Galaxy role that I can use verbatim without applying any custom changes so this argument can hardly count. > > > So to conclude, when I call a role with *tags* I expect those and only > > those tags to be in effect during role's execution. > > But I don't, and it's not feature I need since I use variables for that. > I do too to include what ever I need to get executed. And then I want to use the tags I've been applying religiously to all tasks I write (as I do with everything I create in AWS) for further filtering. And that is the whole point of the discussion. That option does not exists for playbooks that include roles. > > > Similarly I would > > expect to use *skip-tags* for tags I do not want executed during run > > time. > > Instead of that you are telling me to use vars when I already have tags > > that should serve the purpose. > > The problem here is if you have 20 roles where all roles have uniq tag > and you only want to run one of them, adding 19 skiped tags instead of 1 > include tag is not very practical. > > As said above don't include a role in a playbook if you don't need it. It can also be simply solved via variable as you say right? How about if I have 90 tasks in a role and want to exclude 45? Much more difficult isn't it? > > Not sure why such a resistance towards a feature that is very logical > > to > > have and makes much more sense than what it is atm. > > It might be logical for you but that doesn't mean it is logical for > everyone else. > There is no resistance of new feature, only removing the one that's > there. > Who said anything about removing, see the above comment. It can be improved and turned into what it should had been from the very beginning. In Ansible they have a rule to not break/change feature that people use > unless it's a bug, this one is not a bug as it has function like this > for years and people are using the feature. (Like all rules, there are > exception but I hardly think this is one of them.) > Hahaha you gotta be joking! They have done anything but that! They break backwards compatibility with every single release they do and you say they care about the users? Had I known 5 years ago when I started that Ansible will become what it is today I wouldn't have touched it with a ten foot pole :-D > So changing how tags works on role is probably not going to happen, but > an alternative could be to add new keyword to something like a filter > tag and a add tag. > > You are free to add a proposal at https://github.com/ansible/proposals > and maybe someone have already done that for all i know. > > I would have done that if I thought it would have any effect. -- > Kai Stian Olstad > -- 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/7e987bc9-6965-4218-a61a-e8493ff53714%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
