-
Notifications
You must be signed in to change notification settings - Fork 23.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or {% %}. #22397
Comments
This is expected. The warning was recently added to the 2.3 release purposefully. As the warning states, you should not use jinja2 delimiters in a when statement. Instead it should read:
If you have further questions please feel free to use the mailing list. |
How to workaround this warning if the when expression is stored in a variable (for whatever reason, e.g. due to it being used mutlitple times in different plays). e.g.: What works is to declare |
This works for me
with
|
That works for me too. But now move the condition to a variable and try to use the variable instead. |
ansible_PSVersionTable is a variable from a custom fact I have installed on all Window computers. |
Try the following and I assume it won't work (given that the condition is
|
In that case you would need the "{{ ... }}" - its only the 'when' conditional where the "{{ .... }}" is implied, I think. |
also might want to make use of | bool filter to ensure var is stored as a boolean. |
That's what I'm saying... you will either need the "{{ ... }}" within the variable declaration or the when condition as it won't work (correctly) otherwise. And then you will get the mentioned WARNING. |
You can use something like:
|
possibly a dup of #23578 |
I'm also a bit confused by this. I understand we can now do
^ This will NOT return the current date (YYYY-MM-DD). In this instance I have no way to use anything else but the jinja2 delimiters with something like:
Another use case is, e.g.
I have no way to simply do
So my question is: how can I both account for those 2 use cases if jinja2 delimiters are deprecated starting with Ansible 2.3? Is |
Adding another use case: consider the following variable:
then the following tasks generate the warning. Not sure how to avoid it as item.name is the result of iteration on the list
|
@PhilEv , you can do something like this to avoid that problem (note you dont need the true check):
|
We're seeing these warnings as well, and removing the jinja delimiters from
Any suggestions for an alternative way of writing this? |
|
@sivel Awesome, thank you. What is the tilde doing specifically in this case? I can't find the docs on it and would love to read up. |
@jsuter http://jinja.pocoo.org/docs/dev/templates/#other-operators
|
Thanks @streetster as posted in ansible group (thanks @sivel and Josh)
|
I honestly don't see how you can write a meaningful playbook without triggering this new warning message. The whole point of Ansible is that things can be modularised into roles. If you want to stop this warning from being triggered you have no chance unless you are writing flat playbooks with ugly when expressions. Examples that are seemingly not able to be worked around: defaults
meta
throws warnings.... And finally (this is really difficult to work around!) Parent Role - defaults
Parent Role - meta
Child Role - tasks
I seriously hope I am being stupid and am missing something simple either that or this change gets reverted in the next release. |
Color me confused as well. Everything else in Ansible, as far as I can see, uses Jinja delimeters. What's the difference between "changed_when" and the rest? Speaking as someone who is learning Ansible, it makes things harder to understand. |
Please see above PR. I will probably get fish slapped pretty hard but if it is affecting enough people please show your support and maybe the warnings will get removed (either by this way or another). |
…ating delimiters such as {{ }} or {% %}. ansible/ansible#22397
Instead of saying what not to do it should say WHAT TO DO! We are not magicians. Thanks. |
Ansible 2.3.0 does not like delimiters in when statement. Related link: ansible/ansible#22397 Closes-Bug: #1714349 Change-Id: I973cc6537c4c1374546b5cddb4ce713a553b92f4
I get this warning all over the place now. I have a generic role that is 'extended' in specialized roles by specifying some variables when defining this generic as a dependency like this in the
The Then, in the generic role I have steps like this:
I now however, in every single step in the
This is due to the implicit 'when' clause that's added to every step in that included file, but I'm not sure how to solve this-one. The
This however doesn't work, since when I debug print that _configuration_needed variable, I see this "custom_configuration_needed" as (a non-empty) string, which always evaluates to "True". This is certainly not expected or wanted behavior and I have no idea how to remove these warnings. If there is a working solution for preventing these warnings in this case, which also have the expected behavior, please share - bur right now, I can't find any way to do this. Also, for ansible 3, please consider making jinja templating consistent across the board. Everywhere or nowhere |
I can't eveluate a dynamic variable without the {{}}, I can't get this working witout the curly brackets:
Without the brackets it's just a string which will be evaluated as TRUE. It's really dissapointing to see that you want to remove the only way to evaluate variable within the |
@bartmeuris in your example, that warning will no longer show up in ansible v2.4 which is soon to be released @MichalTaratuta you should be using the following instead:
The fact that your example worked before was unintentional, and is not best practice for building a variable name to check. |
What about when testing for the presence of a string, part of which contains a variable?
It's very possible I'm just missing a better or more appropriate way to write that but so far the only method that works seems to be using the brackets within the quoted string. EDIT
|
I see that the warning is useful, but can e.g. longer expressions like the following one can be written without any templating delimiters:
|
… var (#1911) * Change deprecated vagrant ansible flag 'sudo' to 'become' * Emphasize, that the name of the pip_pyton_modules is only considered in coreos * Remove useless unused variable * Fix warning when jinja2 template-delimiters used in when statement There is no need for jinja2 template-delimiters like {{ }} or {% %} any more. They can just be omitted as described in ansible/ansible#22397 * Fix broken link in getting-started guide
… var (kubernetes-sigs#1911) * Change deprecated vagrant ansible flag 'sudo' to 'become' * Emphasize, that the name of the pip_pyton_modules is only considered in coreos * Remove useless unused variable * Fix warning when jinja2 template-delimiters used in when statement There is no need for jinja2 template-delimiters like {{ }} or {% %} any more. They can just be omitted as described in ansible/ansible#22397 * Fix broken link in getting-started guide
This may help new people, so to avoid such things while checking the condition by passing variable, first we need to register that particular variable and then use that.Below is the small example VERSION is already defined or passed explicitely while running a play book
|
Hello, What about the case when I am passing a inventory group name based on the predefined variable?
|
|
ISSUE TYPE
COMPONENT NAME
ANSIBLE VERSION
CONFIGURATION
Stock ansible.cfg
OS / ENVIRONMENT
Management host macOS 10.12.3
SUMMARY
Task I've been using for over 7 months started throwing a warning.
STEPS TO REPRODUCE
EXPECTED RESULTS
Task would run without a warning
ACTUAL RESULTS
The text was updated successfully, but these errors were encountered: