Check this out.
For those looking for better variable access AND easier conditionals, I think this is good stuff. You should like this.
Old ways still work for the forseeable future (we might decide to deprecate them in a year), but I think this is much much better:
https://github.com/ansible/ansible/blob/devel/examples/playbooks/upgraded_vars.yml
the value given to “when” is any Python statement that returns truthiness.
This is a welcome addition. It has always been a bit awkward to flip between template files and playbooks.
First, superb evolution. This will really improve our playbooks and simplify further work, I will start experimenting with it.
Second:
First, superb evolution. This will really improve our playbooks and
simplify further work, I will start experimenting with it.Second:
1) Will this come with support for multi-conditionals per action?
(Multiple when statements on a single action, interpreted as an overall AND)
Yeah, we can do this. It's not something that it does now, but I think if
when: specified a list, that is what it should do.
2) Will there be an equivalent for (or something similar to) Jinja2's set?
i.e. be able to assign a value to an intermediate variable
This is a bit unrelated to the above, but I don't think you need it.
For instance, assume an example where you register the result of some
command and (super imaginary use case), need the return code multiplied by
10 for another command:
- shell: foo --param1=2
register: foo_result
- shell: bar --param2={{ foo_result.rc * 10 }}
So suppose you didn't want to repeat {{ foo_result.rc * 10 }}, you can just
do:
vars:
rc10: {{ foo_result.rc * 10 }}
And later:
- shell: bar --params2={{ rc10 }}
- shell: bar --again --params2={{ rc10 }}
Or even using it in a template:
{{ rc10 }}
A 'set' keyword isn't an immediate priority, but it would be doable.
I agree it reduces the need in several cases.
But there are a number of use-cases where the same (complex) expression is used over and over again, and even permeates through included tasks. As playbooks evolve, it’s cumbersome and error-prone to correct/modify said expression (and variants) all over the place.
(Someone tries to enhance one part of the play, and forgets about another place e.g. in an embedded task.)
For now, I use jinja2/localfacts to wrap up such expressions and avoid the hassles.
You can save the expression in a variable and it should just work.
Although ultimately nearly all uses of repeated expressions are better handled by “group_by” and a play targetting a dynamic group of generated hosts.
Save it in a var/vars_file var? Sorry, this just isn’t possible in our situation.
The expressions we have involve variables whose value is determined at run-time, due to one reason or another e.g.
They are derived via templates because we have certain data that needs to be “joined” (usually to model server interdependencies that influence server configuration, and are flexible)
They are the result of command/shell executions (these will always exist in real systems, no matter how many modules get written)
There is no mechanism in Ansible that I’m aware of (short of templates/local_facts) that encompasses the above. Ergo expressions.
Note: We deal with proprietary applications. I solved the simple cases of apache/drupal/php/rsyslog/backup/tomcat/openldap/mysql/etc. deployments in the first few weeks using Ansible - that’s not where our modeling complexity lies; it’s the top tier of the value chain which has proprietary (and flexible) topologies, and complex application interdependencies. We will use one unified tool to construct our entire data-center from lab to Production, and Ansible is it for now.
As to your last point, all I can say is, we need to make significant use of templates, local_facts and register variables, and without them we would not be able to model our system. If our use-case is in the minority, so be it, I understand the priority call
Asad,
I have to balance the needs of everyone on the list with what I work on.
You are welcome to send in a patch.
–Michael
Allowing multiple conditions by specifying a list to "when:" like you suggested would be wonderful!
Perhaps you too would like to submit a patch 
If not, I’ll take a look eventually. Though commander and other things are more of a priority at the moment.
This sounds super fantastic, and I hope it's indeed true. Here's an example
using these stanzas: