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 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/CAMFyvFi8%2BEEeZ35h50XgUfMPX4PDmCDvo%2BXeDhaDhwbrAXVDtg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
