On Tue, Mar 15, 2016 at 8:10 AM, Udondan <[email protected]> wrote:
> I also agree it would have made more sense if the dynamic include was > optional and the default behavior was the version 1 way. But I also see how > this is hard to justify now that Ansible 2 works as it does, it's hard to > go back. If Ansible follows semver that would actually mean we have Ansible > 3 knocking on our door if the behavior is switched back. > > Ideally, in my opinion, the new functionality would have been added with a > different name, for example "import" instead of "include". This would have > allowed a clean way to migrate without breaking things. It also makes it > possible to distinguish between two complete different features by name. > Agreed, hind sight is 20/20. That is also something we considered, however again at this point it would break playbooks as written for 2.0. > We have adopted Ansible 2 but I would not mind if the behavior changed > back to the old static include. In any case, I will adjust our roles. Most > of the includes do not need to be dynamic and I would set them to static > just to get rid of the hundreds blue include statements during playtime. > > Now, I'm wondering what happens if a static include includes a file which > has a dynamic include. :) > Thanks for this, this is something I need to test with my feature branch. I don't think I recursively parse tasks brought in from static includes... -- 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/CAMFyvFi-%2B1B9wNpazV%3DnoY%3DhY_%2Bpsdyh98c8XZ53zpRcd4KmBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
