> 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 <keif.gw...@3drepo.org> 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 <ig...@encompasscorporation.com>
> 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 ansible-project+unsubscr...@googlegroups.com.
>> To post to this group, send email to ansible-project@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
>> <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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
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.
