--skip-tags equivalent inside playbooks

Archives Ansible Project
21

Probably pretty useless to answer but anyway.

> 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?

You can't without having unique tag.
I understand what you are looking for, I just say that is not possible with Ansible at the moment and if you need that kind of functionality use variables instead.

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.

I don't know why I need good luck with that, been doing it for years and it just work.

> 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.

Strange view on life.

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 :slight_smile:

Yes it is, but I have tried to come up with alternative way to do it in the scope of how Ansible work at the moment.

> 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???

Because I read the Ansible documentation and learned how tags work.
Because of tags I can filter which roles that I need to run-

My playbook contain all configuration for that server/system.
Something like this, but could also have a lot more roles.

roles:
   - role: common
     tags: common
   - role: access
     tags: access
   - role: ntp
     tags: ntp
   - role: common
     tags: common

   - role: nginx
     tags:
       - nginx
       - portal
   - role: vhost
     vhost_engine: nginx
     vhost_name: portal.example.com
     tags:
       - vhost
       - portal
   - role: dns
     dns_name: portal.example.com
     dns_ip: 192.168.0.30
     tags:
       - dns
       - portal

So if the NTP address changes i only need to run the ntp role, so I just add --tags ntp on the command line.
Running the whole playbook takes to long time so it handy to filter with 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.

Have never seen any Galaxy role that I can use verbatim without applying
any custom changes so this argument can hardly count.

All my Galaxy roles are unchanged, the ones I use have all the customization I need in variables.

> 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.

I do understand what you need, I just tried to explain why Ansible developers would be reluctant to change current tags behaviour.
Since this new feature have not been developed they probably doesn't see much demand for it or no one has opened there wallet to get it developed.

> 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.

I need to role, but not on every run if just a small part is changed.

It
can also be simply solved via variable as you say right?

Yes, and I did that before I read about tags and how they worked.

How about if I
have 90 tasks in a role and want to exclude 45? Much more difficult isn't
it?

At the moment I solve that by have roles that just do a very specific so I don't have to just a few tasks in a role.
But in some of them I do i tend to stick them in a file and use include_tasks with a when on 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.

Well why do you say (multiple times) "Which is wrong and useless" about how tags work today.
So no wonder I take that as you would like to replace today functionality.

It't not useless for me and others since we use tags as they are today.

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!

No, hence my parenthesis.

22

Probably pretty useless to answer but anyway.

You are right it was useless.

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?

You can’t without having unique tag.

You will run our of unique names for every single tag in couple of years :slight_smile:

I understand what you are looking for, I just say that is not possible
with Ansible at the moment and if you need that kind of functionality
use variables instead.

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.

I don’t know why I need good luck with that, been doing it for years and
it just work.

So for tasks that have multiple tags you just repeat them in every file? Great!

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.

Strange view on life.

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 :slight_smile:

Yes it is, but I have tried to come up with alternative way to do it in
the scope of how Ansible work at the moment.

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???

Because I read the Ansible documentation and learned how tags work.
Because of tags I can filter which roles that I need to run-

My playbook contain all configuration for that server/system.
Something like this, but could also have a lot more roles.

roles:

  • role: common
    tags: common

  • role: access
    tags: access

  • role: ntp
    tags: ntp

  • role: common
    tags: common

  • role: nginx
    tags:

  • nginx

  • portal

  • role: vhost
    vhost_engine: nginx
    vhost_name: portal.example.com
    tags:

  • vhost

  • portal

  • role: dns
    dns_name: portal.example.com
    dns_ip: 192.168.0.30
    tags:

  • dns

  • portal

So if the NTP address changes i only need to run the ntp role, so I just
add --tags ntp on the command line.
Running the whole playbook takes to long time so it handy to filter with
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.

Have never seen any Galaxy role that I can use verbatim without
applying
any custom changes so this argument can hardly count.

All my Galaxy roles are unchanged, the ones I use have all the
customization I need in variables.

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.

I do understand what you need, I just tried to explain why Ansible
developers would be reluctant to change current tags behaviour.
Since this new feature have not been developed they probably doesn’t see
much demand for it or no one has opened there wallet to get it
developed.

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.

I need to role, but not on every run if just a small part is changed.

It
can also be simply solved via variable as you say right?

Yes, and I did that before I read about tags and how they worked.

As I said before im not contending the documentation I’m very much aware of it. What I’m saying they way it is done is wrong.

How about if I
have 90 tasks in a role and want to exclude 45? Much more difficult
isn’t
it?

At the moment I solve that by have roles that just do a very specific so
I don’t have to just a few tasks in a role.
But in some of them I do i tend to stick them in a file and use
include_tasks with a when on it.

Again not practical, for tasks with multiple tags you need to have the same task in multiple files.

But I will end this pointless discussion here. All I’m saying is conduct the following test with people that have coding mind and no knowledge of Ansible see what happens.

Given the tasks in role1:

  • name: task1
    tags: [“tag1”]

  • name: task2
    tags: [“tag2”]

and the playbook calling the above role:

  • roles:
  • { name: role1 tags: [“tag1”] }

what do you expect to happen?

For me, 6 out of 6 gave the answer I expected. It’s just logic and common sense.

23

For me, 6 out of 6 gave the answer I expected. It’s just logic and common sense.

I recently started using ansible, and I’m trying to adapt the existing playbooks so I can have a ‘config update’ run, and it is exactly how I wanted it to behave.

config-update.yml

24

To achieve what I’m after do I need to refactor all the roles so that they have

To answer my own question, No.

I do need to change the way the roles are called

instead of

  • hosts: tag_compute-node
    roles:

  • {role: ‘compute’, tags: ‘compute’}

  • {role: ‘mount_smb’, tags: ‘mount_smb’}

  • hosts: tag_compute-node
    roles:

  • {role: ‘compute’}

  • {role: ‘mount_smb’}

and then all the tasks in compute need to be tagged install or config depending. Gotcha was also needed to tag items that created checks to tag: always to ensure the variables are already set.

I’d inherited the tagged roles