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.
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). On Monday, March 14, 2016 at 5:17:04 PM UTC+1, James Cammarata wrote: > > Hi all, we've been working on a solution over the last few weeks to > address the problems introduced by making includes dynamic in 2.0, and > would like some community feedback on my ideas. > > As you're all probably well aware by now, we moved task-level includes to > be completely dynamic in 2.0 to make doing things like loops easier. In > 1.9.x and before, includes functioned like pre-proccessor statements - the > files were parsed, turned into a list of tasks, and inserted into the main > list of tasks at the time the main playbook or role was parsed. > > The downside to this move was to make it quite difficult to handle certain > situations, as we now know nothing about those files (and specifically what > tasks are in those files) until we encounter them in the regular execution > of the playbook. As such, we don' t know what tags are there, and when > notifying handlers the task names aren't known so the notifications fail. > > To address this shortcoming, our idea was simple: allow includes to be > marked as static, and as such they again function as pre-processor > statements. Here is the feature branch where we implement this change: > > https://github.com/ansible/ansible/compare/static_includes > > In a nutshell, there are now two ways to make includes behave as they did > in 1.9.x: > > 1. Use the `static: true` option on the include. > 2. Set options in your ansible.cfg. There is one option each for regular > tasks, and one for handlers, as some may wish to make all handler includes > static without impacting those in regular task sections. > > Example: > > - hosts: all > gather_facts: yes > tasks: > - include: foo.yml > static: yes > > Or, if you're migrating from 1.9.x (or earlier) to 2.0 and want all of > your includes to work as they did before, add the following two options to > your ansible.cfg in the [defaults] section: > > task_includes_static = yes > handler_includes_static = yes > > The caveat to all of this is of course that using loops on a static > include will no longer work. Also, any playbook marked as static using > variables must have those variables available at compile time (no inventory > sources are available at this point). > > We're looking at merging this in for the 2.1 release (targeting an April > release), so any comments/ideas for making it work better are appreciated. > If you've avoided the 2.0 release because of the impact of dynamic > includes, we'd really love to hear how your playbooks work (or don't) when > using this feature branch with dynamic includes disabled completely. > > Thanks! > > James Cammarata > > Ansible Lead/Sr. Principal Software Engineer > Ansible by Red Hat > twitter: @thejimic, github: jimi-c > -- 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/d885d4a4-1803-4986-a3a2-53c92efaa2ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
