# Tags not propagated to dynamically included tasks: Workaround? **URL:** \ **Category:** Ansible Project\ **Created:** [August 24, 2018, 1:47pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415 "2018-08-24T13:47:39Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Frank\_Thommen](https://avatars.discourse-cdn.com/v4/letter/f/7feea3/32.png) [@Frank\_Thommen](https://forum.ansible.com/u/Frank_Thommen)\ **Post date:** [August 24, 2018, 1:47pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/1 "2018-08-24T13:47:39Z")
Dear all, since "recently" (we realized just now), tags applied in role's main.yml task, like: /role/myrole/tasks/main.yml: - name: My Task    include\_tasks: "mytask.{{ansible\_osfamily}}.yml"    tags:      - mytask-only      - always are not propagated to the included task any more. It still works fine for statically included tasks. This seems to be the the now documented way of attribute inheritance since ansible 2.5 and it probably came to us with a recent `yum upgrade` which updated ansible from 2.4 to 2.6 in one big step. However this is a major pain for us: We are extensively using unified, role-spanning[\*] tags on the level of the the main tasks to be able to selectively roll out our configurations. The new behaviour means, that we have to manually add hundreds(!) of "tag" statements to each individual task in all the included taskfiles. Is there a way to achieve the former behaviour (tag inheritance to dynamic includes) other than framing each task.yml with a block, which introduces redundancy and error-proneness? Personally I find this new behaviour suboptimal regarding maintenance, intuitive understanding of playbooks and scalability. All things, that I appreciated with ansible so far. Cheers frank [\*] i.e. we have e.g. the same tag "sysconfig" applied to an included taskfile for the role "common" and for the role "hw-server" and for the role "webserver", allowing us to run the complete system configuration with --tags=sysconfig ---
**Author:** ![Kai\_Stian\_Olstad](https://avatars.discourse-cdn.com/v4/letter/k/e19adc/32.png) [@Kai\_Stian\_Olstad](https://forum.ansible.com/u/Kai_Stian_Olstad)\ **Post date:** [August 24, 2018, 2:31pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/2 "2018-08-24T14:31:29Z")
> since "recently" (we realized just now), tags applied in role's main.yml > task, like: > > /role/myrole/tasks/main.yml: > > - name: My Task >    include\_tasks: "mytask.{{ansible\_osfamily}}.yml" >    tags: >      - mytask-only >      - always > > are not propagated to the included task any more. \ > However this is a major pain for us: We are extensively using unified, > role-spanning[\*] tags on the level of the the main tasks to be able to > selectively roll out our configurations. The new behaviour means, that > we have to manually add hundreds(!) of "tag" statements to each > individual task in all the included taskfiles. You don't need to add it to every task, you can use a block: around them all and set the tag on the block. You can also wrap the include\_tasks in a block, and set the tags on the block.   - block:     - name: My Task       include\_tasks: "mytask.{{ansible\_osfamily}}.yml"     tags:       - mytask-only       - always > Is there a way to achieve the former behaviour (tag inheritance to > dynamic includes) other than framing each task.yml with a block, which > introduces redundancy and error-proneness? Only the workaround mention above, but you can always downgrade. There are some discussion don't remember if it was in an issue or on this list about a option or something like that to tell if it should propagate or not. ---
**Author:** ![Frank\_Thommen](https://avatars.discourse-cdn.com/v4/letter/f/7feea3/32.png) [@Frank\_Thommen](https://forum.ansible.com/u/Frank_Thommen)\ **Post date:** [August 24, 2018, 3:16pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/3 "2018-08-24T15:16:56Z")
Thanks a lot Kai, > > since "recently" (we realized just now), tags applied in role's main.yml > > task, like: > > > > /role/myrole/tasks/main.yml: > > > > - name: My Task > >     include\_tasks: "mytask.{{ansible\_osfamily}}.yml" > >     tags: > >       - mytask-only > >       - always > > > > are not propagated to the included task any more. > > \ > > > However this is a major pain for us: We are extensively using unified, > > role-spanning[\*] tags on the level of the the main tasks to be able to > > selectively roll out our configurations. The new behaviour means, that > > we have to manually add hundreds(!) of "tag" statements to each > > individual task in all the included taskfiles. > > You don't need to add it to every task, you can use a block: around them all and set the tag on the block. > > You can also wrap the include\_tasks in a block, and set the tags on the block. > >    - block: >      - name: My Task >        include\_tasks: "mytask.{{ansible\_osfamily}}.yml" >      tags: >        - mytask-only >        - always Very nice solution. I myself experimendet with a construction like: - name: "My Task"    block:      - import\_tasks: mytask.RedHat.yml        when: distro == "RedHat"      - import\_tasks: mytask.CentOS.yml        when: distro == "CentOS"      - import\_tasks: mytask.Suse.yml        when: distro == "Suse"      - import\_tasks: mytask.Debian.yml        when: distro == "Debian"    tags:      - mytask-only which makes for bad reading and bad maintainability. Your idea with the block is elegant and well maintainable while keeping all the dynamic and flexibility. I realize blocks are more versatile than I thought 😉 f. ---
**Author:** ![stan.varlamov](https://avatars.discourse-cdn.com/v4/letter/s/54ee81/32.png) [@stan.varlamov](https://forum.ansible.com/u/stan.varlamov)\ **Post date:** [August 25, 2018, 6:21am UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/4 "2018-08-25T06:21:27Z")
This is an interesting post that touches upon the topic: [https://medium.com/opsops/ansible-2-5-delegate-to-and-include-role-20cd7e67008e](https://medium.com/opsops/ansible-2-5-delegate-to-and-include-role-20cd7e67008e) The way I look at it, Ansible team has chosen a path of keeping the product competitive vs. maintaining backward compatibility at all costs. The Best Practices recommend avoiding Tags all together, as well as other traditional features that are static in nature and aren’t considered in dynamic Includes. This (supposedly) allows writing better playbooks. Yes, there is a potentially considerable effort re-writing old ones that don’t comply with the new model. On the other hand, with the speed of the industry changes, since the time the old books were written, an average team would probably switch to another tool or technology all together as part of the cycle, so keeping Ansible as a valuable option for future cycles pretty much means that the archaic way the old playbooks were written in has to change. ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [August 27, 2018, 2:59pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/5 "2018-08-27T14:59:03Z")
A few of things: - `include:` still exists, yes we are planning to eventually deprecate as it has mixed static/dynamic behaviour and it is not easy to know which you will get - `include_role`/`include_tasks` were created to represent the ‘dynamic’ parts of the existing `include`, but they have been a work in progress, we do think we have almost finalized them now and hope to mark them as ‘stableinterface’ soon - `import_role`/`import_tasks`/`import_playbook` are the ‘static’ parts, this helps disambiguate the `include:` behaviors and make them explicit. - the distinctions should be easy now import\_X has all keywords set as ‘inheritance’, while include\_X have all keywords apply to it, but not inherited. This still leaves things that make no sense like `delegate_to` or `become` on includes, but we are planning on documenting and warning on those in the future. - `include_role`/`include_tasks` have gotten the `apply` keyword (in 2.7) that allows for inheritance, in older versions you can use a `block` as shown in previous posts. We hope that this rounds out all the functionality needed for these features. We do try to maintain backwards compatibility, but in this case that means `include` as `include_tasks` and `include_roles` were ‘new’ and ‘in progress’ as we figured out how people are using them and how we think it best suits everyone’s needs, so backwards compatibility on those was not as important as getting the feature set ‘right’. User feedback has been crucial for this and part of it was that users were displeased with things changing even if they liked the changes. We are trying to figure out better ways to communicate the state of a feature and adjust expectations as not everything we release is complete, perfect and immutable. Thanks for your feedback and your patience, ---
**Author:** ![Kai\_Stian\_Olstad](https://avatars.discourse-cdn.com/v4/letter/k/e19adc/32.png) [@Kai\_Stian\_Olstad](https://forum.ansible.com/u/Kai_Stian_Olstad)\ **Post date:** [August 27, 2018, 3:54pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/6 "2018-08-27T15:54:26Z")
> - `include:` still exists, yes we are planning to eventually deprecate as > it has mixed static/dynamic behaviour and it is not easy to know which you > will get > > - `include_role`/`include_tasks` were created to represent the 'dynamic' > parts of the existing `include`, but they have been a work in progress, we > do think we have almost finalized them now and hope to mark them as > 'stableinterface' soon I think this might be the source of all frustration, include was marked deprecated before the new feature was stable. The Ansible community is so big that you would have gotten a lot of feedback without marking include deprecated at that point. > We do try to maintain backwards compatibility, but in this case that means > `include` as `include_tasks` and `include_roles` were 'new' and 'in > progress' as we figured out how people are using them and how we think it > best suits everyone's needs, so backwards compatibility on those was not as > important as getting the feature set 'right'. I think your would have gotten this feedback without marking include deprecated. Just mention the new feature in the release notes and say comment accepted would have gone a long way. > User feedback has been crucial for this and part of it was that users were > displeased with things changing even if they liked the changes. We are > trying to figure out better ways to communicate the state of a feature and > adjust expectations as not everything we release is complete, perfect and > immutable. I'm one of does that likes the changes, had no issue with it. I only used when on include, and the change was very welcome. But I understand the painfulness some user have experience. When you see a deprecation warning you naturally want that message to do a way, but non of the new solution could do that out of the box, some tweaking was necessary. ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [August 27, 2018, 4:02pm UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/7 "2018-08-27T16:02:33Z")
We reverted the deprecation on include, the feedback did make it clear we had made a mistake at the time. We have revised our deprecation policy to trail the stable substitute vs always being immediate. ---
**Author:** ![Michael\_Stroder](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@Michael\_Stroder](https://forum.ansible.com/u/Michael_Stroder)\ **Post date:** [September 22, 2018, 9:25am UTC](https://forum.ansible.com/t/tags-not-propagated-to-dynamically-included-tasks-workaround/28415/8 "2018-09-22T09:25:44Z")
Given the volatility of include handling in a pretty short period my question is: Is the solution above guaranteed to work for the next few years? Ciao, Michael.