[ansible-devel] When statements with Jinja2 templating delimiters
Hi All,
Am new to this group and Google Groups in general so please go easy.
I have a few questions about the recent change in Ansible 2.3.0.0 that new
prints a warning when jinja2 templating is included in a when, changed_when
and failed_when statement. Please see this closed GitHub issue for more
details on exactly what warning I mean:
https://github.com/ansible/ansible/issues/22397
We have some very complex plays that depend on multiple roles. The roles
are kept very generic by design so they can be used by multiple calling
roles. Example: we may have plays for three or four completely different
Java web apps that all depend on a common Tomcat role, passing in
overriding variables for customisation.
This now causes any when statement that uses one of these overridden
variables to throw a warning. Please find a very simplistic example below:
*Parent Role - defaults*
bootstrap_ping : true
*Parent Role - meta*
dependencies:
- { role: apollo/platform/ping, ping: '{{ bootstrap_ping }}' }
*Child Role - tasks*
- name: execute
when: ping
win_ping:
This throws the warning.
I have looked at a few GitHub threads and a few Stack Overflow questions
and have yet to see a valid workaround for this situation.
I also do not understand why Ansible processes Jinja2 under when statements
if the stance is you are not supposed to do it. I raised a PR (here:
https://github.com/ansible/ansible/pull/24974) which was swiftly closed
(fair enough, I have never contributed to this project before and I did not
follow procedure).
I was hoping someone could please help with the below questions to educate
myself and improve our Ansible playbooks further:
1. Will this remain forevermore just a warning or will it become a hard,
breaking error in a future release?
2. What is the 'proper' way to write the above example whilst keeping
things modular?
3. If this will remain just as a warning what about the possibility of
implementing an ansible.cfg flag to turn it off?
Really appreciate any help,
Thanks!
Rich
--
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 ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-devel] Re: When statements with Jinja2 templating delimiters
Hi Micheal,
Thanks for the reply. I have also seen pretty much that any other example
of this warning being triggered is both valid and workaround-able.
I am beginning to think our way of using Ansible (passing through variables
into sub-roles) might be different to other peoples...
Which brings me back to my original questions. Will this always be a
warning or will it become a "hard" error? At this point I understand that
the change won't be reverted and why I just would like to know how big the
impact of this will be in the future.
On Thursday, 25 May 2017 13:39:23 UTC+1, Brian Coca wrote:
>
> @Micheal, in your case having the extra moustaches ({{ }}) would cause
> unwanted double interpolation, @Rich is actually using that on
> purpose. So the warning was valid in your case, but not his.
>
> For templating there are mainly 2 rules (though 2nd is actually
> consequence of the first):
>
> - moustaches don't stack: {{ {{ }} }} <= you should not use tempating
> inside templating, normally you want contactenation or hostvars[]
> - Always use moustaches except when `when:` <= conditionals are
> 'expressions' so they already have an implied template which then hits
> rule #1
>
>
>
> --
> Brian Coca
>
--
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 ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-devel] Re: When statements with Jinja2 templating delimiters
I mean Hi Brain! ooops...
I have no idea how to edit posts either!
On Tuesday, 30 May 2017 11:39:33 UTC+1, Rich Lees wrote:
>
> Hi Micheal,
>
> Thanks for the reply. I have also seen pretty much that any other example
> of this warning being triggered is both valid and workaround-able.
>
> I am beginning to think our way of using Ansible (passing through
> variables into sub-roles) might be different to other peoples...
>
> Which brings me back to my original questions. Will this always be a
> warning or will it become a "hard" error? At this point I understand that
> the change won't be reverted and why I just would like to know how big the
> impact of this will be in the future.
>
> On Thursday, 25 May 2017 13:39:23 UTC+1, Brian Coca wrote:
>>
>> @Micheal, in your case having the extra moustaches ({{ }}) would cause
>> unwanted double interpolation, @Rich is actually using that on
>> purpose. So the warning was valid in your case, but not his.
>>
>> For templating there are mainly 2 rules (though 2nd is actually
>> consequence of the first):
>>
>> - moustaches don't stack: {{ {{ }} }} <= you should not use tempating
>> inside templating, normally you want contactenation or hostvars[]
>> - Always use moustaches except when `when:` <= conditionals are
>> 'expressions' so they already have an implied template which then hits
>> rule #1
>>
>>
>>
>> --
>> Brian Coca
>>
>
--
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 ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ansible-devel] Re: When statements with Jinja2 templating delimiters
Latest devel seems to work great for me now. Thanks to the developers for
fixing it for this specific use-case.
Our codebases no longer generate any warnings except one or two that are
both valid and very easy to fix
Thanks!
On Tuesday, 30 May 2017 14:45:16 UTC+1, Ed wrote:
>
> [ Bringing a question over here that was unanswered in ansible-project...
> ] I've got cases where I want to run the same complex task multiple times,
> with minor variances. I've been implementing that with a loop where each
> item has a property for its when statement, and the task uses templating to
> resolve the property. With 2.3, I now receive warnings about the jinja
> expression. I can't use "when: item.condition", since that handles
> item.condition as a string (instead of evaluating the content of
> item.condition). What's the best way to accomplish this, warning-free, in
> 2.3? Is there a filter I can use to do evaluation? For maintenance
> reasons, I'd like to avoid building a distinct task for each case.
>
> Simple example below.
>
> Thanks,
> Ed
>
>
> $ cat inventory
> one ansible_connection=local
> $ cat play.yml
> ---
> - hosts: all
> tasks:
> - debug:
> msg: "{{ item.message }}"
> when: "{{ item.condition }}"
> with_items:
> - { message: "hello", condition: "7 < 4" }
> - { message: "goodbye", condition: "7 > 4" }
> $ ansible-playbook -i inventory play.yml
>
> PLAY [all]
> ***
>
> TASK [Gathering Facts]
> ***
> ok: [one]
>
> TASK [debug]
> *
> [WARNING]: when statements should not include jinja2 templating
> delimiters such as {{ }}
> or {% %}. Found: {{ item.condition }}
>
> ok: [one] => (item={u'message': u'goodbye', u'condition': u'7 > 4'}) => {
> "item": {
> "condition": "7 > 4",
> "message": "goodbye"
> },
> "msg": "goodbye"
> }
> skipping: [one] => (item={u'message': u'hello', u'condition': u'7 < 4'})
>
> PLAY RECAP
> ***
> one: ok=2changed=0unreachable=0failed=0
>
> $
>
>
> On Thursday, May 25, 2017 at 2:31:30 PM UTC-4, Brian Coca wrote:
>>
>> There are just 2 contexts, normal (you require them) and conditionals
>> (anything with when:) which don't. It is consistent, juts not uniform.
>>
>> --
>> Brian Coca
>>
>
--
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 ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
