No, that kind of hack is about as far from best practices as you can get. As I said in my previous message, the alternative that you were not aware of was using `include_role` with the `always` tag.
On Wednesday, December 8, 2021 at 1:49:58 PM UTC-5 [email protected] wrote: > Thanks. However, I"m not actually using that role. > > My main question is if rendering 'import_role' task files follows best > practices or if there is an alternative to what I'm doing I'm not aware of. > > On Wednesday, December 8, 2021 at 12:06:52 PM UTC-6 flowerysong wrote: > >> Set `tags: always` on your include_role task, so that it always runs. >> >> On Wednesday, December 8, 2021 at 12:31:16 PM UTC-5 [email protected] >> wrote: >> >>> I'd like to start a discussion on the ability to define roles to >>> `import_role` from within host_vars. Instead of *only* defining those roles >>> statically in a playbook. >>> >>> My goal is to be able to give an inventory_host the ability to define >>> any [extra] roles it should import [on top of what is expressed in the >>> playbook]. >>> >>> ``` >>> roles/include-roles/tasks/main.yml >>> --- >>> - name: host_vars defined roles >>> include_role: >>> name: "{{ r }}" >>> loop: "{{ roles }}" >>> loop_control: >>> loop_var: r >>> ``` >>> >>> This is reasonably effective, but I lose the ability to use tags I've >>> set in the roles I include. >>> >> ### Conclusion >>> Overall the rendered task file that imports all the roles does most >>> everything I need, but it feels incorrect. Like I abused the tool into >>> working how I wanted it to work and not how it was intended to be used. Is >>> there some Ansible-ism that I'm not aware of? >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6d079bf0-eee7-465b-a52a-665c534244a8n%40googlegroups.com.
