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.
If you need any other functionality, variables is the way to go.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
--
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/03568fab278c35d38ae15a8c2821b71c%40olstad.com.
For more options, visit https://groups.google.com/d/optout.
