No, we can't do this because of variables and the possibility that they
will do loops (which may also be based on a variable).
Take for exampe:
- include: "{{ansible_distribution|lower}}.yml"
^ This is completely valid in 2.0, and a much nicer alternative to the
include/when syntax you used to have to do. However, we don't know which
files will be brought in until that's actually run, so we can't pre-process
anything (unless we also read in and parse every yaml file in the
playbook/roles path, which presents other problems).
James Cammarata
Ansible Lead/Sr. Principal Software Engineer
Ansible by Red Hat
twitter: @thejimic, github: jimi-c
On Tue, Mar 15, 2016 at 7:33 AM, haad <[email protected]> wrote:
> 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/CAMFyvFijLOjQhT8mWnbx21cFULXxfjApwCpQmVw7WEqroNg%2BkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
