> 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
On Tue, 12 Feb 2019 at 16:52, Keif Gwinn <[email protected]> wrote:
> > 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 ?
>
> On Tue, 5 Feb 2019 at 22:51, Igor Cicimov <[email protected]>
> wrote:
>
>>
>>
>> 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!
>>
>>
>>> >> > 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.
>>>
>>>
>> 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.
>>
>>
>>> >> > 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
>>>
>> --
>> 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/36b5a50a-7aff-4659-9ab9-c881baa74ee1%40googlegroups.com
>> <https://groups.google.com/d/msgid/ansible-project/36b5a50a-7aff-4659-9ab9-c881baa74ee1%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Keif Gwinn
>
--
Keif Gwinn
--
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/CAMTXzjVPkec%3DnWCby4pxVeErNuThvHvOAMyt2FYnaoMOBEbdNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
