@jimi-c: Is it possible to evaluate static includes after the setup module
runs to gathering facts? The most common use pattern I see in users plays
and roles are dynamic includes that define the filename based on a fact
like ansible_os_family. Collecting the fact before evaluating includes
would make things even more seamless for users.

Timothy Appnel
Principal Architect
Ansible by Red Hat

+1 718.404.6429 | <+1+718.404.6429> ansible.com <https://www.ansible.com/>

GitHub: tima <https://www.github.com/tima>

Twitter: @appnelgroup <https://www.twitter.com/@appnelgroup>

On Tue, Mar 15, 2016 at 11:32 AM, James Cammarata <[email protected]>
wrote:

> On Tue, Mar 15, 2016 at 11:03 AM, Strahinja Kustudić <
> [email protected]> wrote:
>
>> So basically now simple includes without any loops or variables in file
>> name will be static by default? That is great news, since most of the
>> includes are like that and it makes them at least backward compatible with
>> 1.x.
>>
>> Could anyone tell me what exactly is the difference between:
>>
>> - include: "{{ some_var }}.yml"
>>   static: yes
>>
>>
> In this case, the include would be processed at playbook parsing time,
> meaning there is no inventory. As such, `some_var` would have to be
> available in playbook vars (vars/vars_files/role vars and defaults), or
> extra vars. Tasks and all related info would be available to things like
> --star-at-task, --list-tags, and --list-tasks.
>
>
>
>>
>> and
>>
>> - include: "{{ some_var }}.yml"
>>   static: no
>>
>> Does it mean for static: yes that some_var would need to be defined
>> statically as a var, and for static: no some_var could be defined during
>> play execution, e.g. set_fact: some_var=something.
>>
>>
> In this case, the include would not be processed until that task was hit
> at execution time, meaning `some_var` could come from any and all available
> variable sources in ansible. Nothing about the tasks in this file would be
> known at compile time, and as such that information would not be available
> for the CLI switches mentioned above.
>
> --
> 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.
>

-- 
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/CAOMCme6HnpS8PtQVwi%2BP1wgc3J%3D7ow4Om1UJpDhDrUNZZOJ1VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to