Hi, Wouldn't be easier to just preproccess those files at beginning of playbook run (so you will evaluate everything to true and load all includes/plays/roles into memory at beginning). So you know what tags/handlers are inside and when that's done you just execute tasks one by one ?
On Tue, Mar 15, 2016 at 7:12 AM, James Cammarata <[email protected]> wrote: > On Tue, Mar 15, 2016 at 1:19 AM, Mark Kusch <[email protected]> wrote: > >> What issues are there with dynamic includes except for included files >> which do not do anything? >> > > Because we do not load the included file until we reach that point in the > execution, we no longer know anything about the tasks contained within that > file. This means that we don't know about tags on those tasks, and > notifying handlers within those files do not work either (which breaks a > common use case for many people). > > >> >> If there was such a huge problem to discuss this, I wouldn't go for a >> change in behaviour of include itself but add a new plugin, e.g. >> static_include, or include_static. >> >> Inline... >> >> # kraM >> >> On 21:57 Mon 14 Mar, James Cammarata wrote: >> > On Mon, Mar 14, 2016 at 8:22 PM, Strahinja Kustudić < >> [email protected]> >> > wrote: >> > >> > > I like the idea, but I don't like the proposal. I would do the same >> thing, >> > > but the other way around. With your proposal it would break backward >> > > compatibility with 1.9 if you don't update all your includes, or >> update >> > > ansible.ini. Also most of the includes are static anyway (since >> dynamic >> > > ones didn't work pre 2.0), so why not make them all static by default. >> > > >> > >> > I went this way to avoid introducing problems with those who have >> already >> > adopted 2.0. We discussed this internally in depth, and flipping the >> > defaults would break everyone who was using 2.0 and upgrading to 2.1. We >> > feel at this point that most people who have not upgraded are avoiding >> > doing so because of backwards incompatibilities with 2.0, so this is >> mainly >> > targeted at giving them an upgrade path. >> >> Upgraded everything to 2.0.0.2, currently upgrading everything to 2.0.1.0 >> (deprecation warnings not visible due to a bug in 2.0.0.2). If we need to >> update everything for 2.1.0, ... Where would that lead to? >> > > >> > >> > > My proposal is to make all includes static by default and introduce a >> new >> > > keyword *dynamic: yes* (or use *static: no* if you like it more) which >> > > you would set on includes where you need them to be dynamic. This >> would >> > > make old 1.9 playbooks backward compatible without any changes >> anywhere, >> > > and if you need a dynamic include in a 2.0 playbook, you will need to >> > > change it in just a few places (since there are far less 2.0 playbooks >> > > anyway and even lower number of dynamic includes). >> > > >> > >> > Again, this is something we discussed internally, the option name is >> > flexible and we can flip it. However for the reasons above we'd default >> it >> > to `dynamic: yes`. >> >> -- > You received this message because you are subscribed to the Google Groups > "Ansible Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Regards. Adam -- 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/CALZpd09ea2UN5%3Dm48Oq7CHS2bYjiwNpk8VS42mJUKZLu7Rbo5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
