James do you have an adoption rate of 2.0 compared to older versions? 2.0 is out for just a few months and older versions which use static includes have been out for years now and people are used to them working that way. But more importantly how many of those who switched to 2.0 are really using dynamic includes, so how many playbooks would really get broken? I guess most of the people using 2.0 had more trouble with dynamic includes than fun.
You should also think of the new users, since 2.0 basically broke the include statement and now in 2.1 you want to leave it broken by default. So future users will now always have to write static: yes for every include (except the dynamic ones, which are far less used) if they wanted their plays to behave as they expect them to work. Wouldn't the documentation be much easier for new users if the first time you mention a dynamic include is when you actual need it and not the first time you show them a simple include. So basically this doc page http://docs.ansible.com/ansible/playbooks_roles.html#task-include-files-and-encouraging-reuse, which is one of the first pages new users read, will have to be changed so that it adds static: yes and you would need to explain the concept of a static/dynamic include to a new user, who just learned that there is an include statement. But if you left them to be static by default, then you would need to change basically one part of the documentation and mention it the first time you need a dynamic one which is here http://docs.ansible.com/ansible/playbooks_loops.html#loops-and-includes, which as we all know is far less used than a static one and by the time the user reaches loops, they are already using Ansible. Also what exactly is a dynamic include? I thought it is only used when you use include + with_items and when using when + include on playbook, or there are more situations when an include is useful to be dynamic? I have one more idea/question. Would it be possible for Ansible to know all the situations when it should use a dynamic include, so that it automatically treats it as a dynamic one and threats the rest as static? On Tue, Mar 15, 2016 at 2:57 AM, James Cammarata <[email protected]> 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. > > >> 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/CADKbJJXSpHdg1h%2BJz47XdhjXcPQ4yj-D0EG6BDX6aU06eEX3WA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
