--skip-tags equivalent inside playbooks

[Dmitry Makovey]

Hi everybody,

http://docs.ansible.com/playbooks_tags.html mentions several ways to use tags, one of which is:

- { role: A, tags: [t1, t2] }

however cli interface allows for inversion via --skip-tags (which is great BTW) and there's no mention of it's equivalent in playbooks.

so in short:

"--tags" == "tags:"

"--skip-tags" == ???

[C. Morgan Hamill]

Excerpts from Dmitry Makovey's message of 2014-07-08 18:49:22 -0400:

> Hi everybody,
>
> http://docs.ansible.com/playbooks_tags.html mentions several ways to use
> tags, one of which is:
>
> - { role: A, tags: [t1, t2] }

This doesn't do what you think it does. It applies tags 't1' and 't2'
to all the tasks in role 'A'. It doesn't filter that tasks within the
role.

As such, this is not applicable:

> however cli interface allows for inversion via --skip-tags (which is great
> BTW) and there's no mention of it's equivalent in playbooks.

--
Morgan Hamill

[Michael DeHaan]

Correct.

Tags in playbooks apply tags to tasks.

--tags means "run the things that are so tagged"

--skip-tags means the opposite

--
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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1404913541-sup-3375%40al.wesleyan.edu.

For more options, visit https://groups.google.com/d/optout.

[Dmitry Makovey]

On Wednesday, July 9, 2014 1:49:16 PM UTC-6, Michael DeHaan wrote:

Correct.

Tags in playbooks apply tags to tasks.

--tags means "run the things that are so tagged"

--skip-tags means the opposite

darn.  May I suggest some clarification for the documentation then? The way it is written currently allows for "free interpretation" which obviously mislead me.

Now the other question: would it be reasonable to ask for such feature then? I can see a lots of uses for it (both for using only tagX from roleA and skipping all tagY from roleB scenarios) also I can see how I can unify all tasks in fewer files and not have to resort to tricks like:

roles/

 httpd/

  install/

   tasks/

  setup/

   tasks/

with subsequent:

roles:

- role: httpd/install

- role: httpd/setup

that I've done on advise from this list to separate my install from my setup yet I'd like to share a thing or two between those... having it done via tags would seem more natural to me.

[Michael DeHaan]

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

--

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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b2d74d00-f73f-42c9-be26-72ecd8a7c2ed%40googlegroups.com.

[Dmitry Makovey]

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? 

[Michael DeHaan]

I think I'd be open to it, depending on patch complexity.

--

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-proje...@googlegroups.com.
To post to this group, send email to ansible...@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.

[Igor Cicimov]

This sounds like very reasonable request, option like:

- { role: A, skip-tags: [t1, t2] }

whould be very useful in case of playbook with many roles having same tags thus --skip-tags is not an option in case one wants to skip tags in couple of roles only.

Any plans to support this?

[Marc Patermann]

Hi,

Am 11.07.2014 um 21:30 Uhr schrieb Dmitry Makovey:
> On Wednesday, July 9, 2014 4:50:55 PM UTC-6, Michael DeHaan wrote:

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

I'd like that too!

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

I would like to have the equivalent to
# ansible-playbook -i Testing/ ldap.yml --tags=ldap_schema mailserver
in a Playbook.
There is no way to do this at the moment, am I right?

I could put it in a shell script, but this does not feel right …


Marc

[Mike Biancaniello]

I agree that I'd like to be able to have roll contain a number of tasks and then have then selective run. A use-tags or play-tags option would be nice to use in that case. While you can certainly implement that with vars (see #2 below), it seems that a tags solution would be more elegant.

There are also times when you want to insert debug tasks but don't want them to play by default and don't want to have to remember to always send --skip-tags='debug' every time you run a playbook.

However, for now, I work around this in two ways:

1. I write a python script that calls the playbook and it sets the tags for me.

e.g.

./run_playbook.py site.yml

would essentially run:

ansible-playbook -i hosts site.yml --skip-tags='debug'

or something to that effect.

2. I require an extra-var to not skip.

e.g.

  tasks:
    - name: Show vars
      debug: msg={{item.ansible_facts}}
      with_items: some_loaded_vars.results
      tags: debug
      when: debug|default(false)

then:

ansible-playbook site.yml -e '{"debug":true}'

would execute that task.

[Igor Cicimov]

Yeah, for sure there can be some workarounds but very tedious ones. Your example can work but needs to be thought of at the very beginning of organizing your repository and I can't see anyone that clever foreseeing that far in the future about issue like this. Ones you have repository of 30 roles and more than hundred of playbooks retrofitting this into every playbook for every task and who knows how many different variables (you obviously need separate variable per tag type) is really impossible.

[Krisztián Tóth]

Is this feature implemented yet? Does somebody know anything about it?

[Igor Cicimov]

Anyone knows if this is possible in any ansible release?

[Brian Coca]

No, it is not possible

----------
Brian Coca

[Igor Cicimov]

Brian, I find the current usage of "tags" when calling a role via "roles:" or "include_role/import_role" is counter intuitive. The reason we tag tasks in our playbooks is for the purpose of filtering which we would expect to be the case in the above mentioned scenarios as well. But it is not, and that is major draw back in making reusable (DRY) code.

I constantly find my self in need to execute just a part of some role tasks, lets say the ones tagged with "install" but skip the ones tagged with "configure" lets say. This is exactly what we get by passing "--tags" or "--skip-tags" on the command line so why not make this consistent everywhere?

[Kai Stian Olstad]

On 02.02.2019 05:39, Igor Cicimov wrote:
> Brian, I find the current usage of "tags" when calling a role via
> "roles:"
> or "include_role/import_role" is counter intuitive. The reason we tag
> tasks
> in our playbooks is for the purpose of filtering which we would expect
> to
> be the case in the above mentioned scenarios as well. But it is not,
> and
> that is major draw back in making reusable (DRY) code.
>
> I constantly find my self in need to execute just a part of some role
> tasks, lets say the ones tagged with "install" but skip the ones tagged
> with "configure" lets say. This is exactly what we get by passing
> "--tags"
> or "--skip-tags" on the command line so why not make this consistent
> everywhere?

I would argue that it's very consistent at the moment.
All tags in a yaml file sets/add that tag(s), and which tags you want to
run is specified on the command line.

Use variables if you want to run part of your code.
An example:

roles/test/install.yml
roles/test/configure.yml


roles/test/main.yml
---
- include_tasks: install.yml
when: test_install | default(true) == true

- include_tasks: configure.yml
when: test_configure | default(true) == true

Then to only run install just do this
playbook.yml
- hosts: localhost
roles:
- role: test
test_configure: false


You can also overwrite the variables on the command line too if needed.

--
Kai Stian Olstad

[Igor Cicimov]

Kai, why would I use vars when I already have tags on my tasks which purpose, and only purpose, is filtering during execution?

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.

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

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?

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

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.

[Kai Stian Olstad]

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

[Igor Cicimov]

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

[Adrian Sebastian Dutu]

You have the tag "never" which will make that role/task not execute by default when running the play, unless explicitly called with --tags. Check special tags in the docs: https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html

[Kai Stian Olstad]

On 04.02.2019 04:10, Igor Cicimov wrote:
> On Monday, February 4, 2019 at 12:10:51 AM UTC+11, Kai Stian Olstad
> wrote:

Probably pretty useless to answer but anyway.

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

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

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.

--
Kai Stian Olstad

[Igor Cicimov]

On Wednesday, February 6, 2019 at 2:14:57 AM UTC+11, Kai Stian Olstad wrote:

On 04.02.2019 04:10, Igor Cicimov wrote:
> On Monday, February 4, 2019 at 12:10:51 AM UTC+11, Kai Stian Olstad
> wrote:

Probably pretty useless to answer but anyway.

You are right it was useless.

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

You can't without having unique tag.

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

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!

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.

[Keif Gwinn]

> 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

---

- hosts: tag_compute-node

roles:

- {role: 'compute', tags: ['config','restart']}

tags:

- compute

- hosts: tag_www-node

roles:

- {role: 'webserver', tags: ['config','restart']}

tags:

- webserver

ansible-playbook config-update.html --tags webserver should call the webserver role and apply all tasks that have the config or restart tags. Without any --tags set it should call all the roles with the config and restart tasks.

Is how I'd interpreted it from the docs. I'm however getting all tasks run on everything.

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

- hosts: tag_compute-node

roles:

- {role: 'compute-install', tags: ['compute-install']}

- {role: 'compute-configure', tags: ['compute-configure']}

- {role: 'compute-start', tags: ['compute-start']}

tags:

- compute

and then I could call it with ansible-playbook config-update.html --tags compute-configure ?

--

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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/36b5a50a-7aff-4659-9ab9-c881baa74ee1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Keif Gwinn

[Keif Gwinn]

> 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

--

Keif Gwinn