# Upgraded variables AND conditionals in 1.2 - feedback welcome **URL:** \ **Category:** Ansible Project\ **Created:** [April 5, 2013, 11:14pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639 "2013-04-05T23:14:23Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 5, 2013, 11:14pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/1 "2013-04-05T23:14:23Z")
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](https://github.com/ansible/ansible/blob/devel/examples/playbooks/upgraded_vars.yml) the value given to “when” is any Python statement that returns truthiness. ---
**Author:** ![Chris\_Hoffman](https://avatars.discourse-cdn.com/v4/letter/c/85f322/32.png) [@Chris\_Hoffman](https://forum.ansible.com/u/Chris_Hoffman)\ **Post date:** [April 6, 2013, 3:23am UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/2 "2013-04-06T03:23:03Z")
This is a welcome addition. It has always been a bit awkward to flip between template files and playbooks. ---
**Author:** ![Asad\_Khan](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@Asad\_Khan](https://forum.ansible.com/u/Asad_Khan)\ **Post date:** [April 6, 2013, 1:03pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/3 "2013-04-06T13:03:47Z")
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) 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 ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [April 6, 2013, 1:36pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/4 "2013-04-06T13:36:22Z")
> 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. ---
**Author:** ![Asad\_Khan](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@Asad\_Khan](https://forum.ansible.com/u/Asad_Khan)\ **Post date:** [April 6, 2013, 2:31pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/5 "2013-04-06T14:31:09Z")
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. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 6, 2013, 6:26pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/6 "2013-04-06T18:26:19Z")
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. ---
**Author:** ![Asad\_Khan](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@Asad\_Khan](https://forum.ansible.com/u/Asad_Khan)\ **Post date:** [April 7, 2013, 1:35am UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/7 "2013-04-07T01:35:46Z")
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 ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 7, 2013, 9:17am UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/8 "2013-04-07T09:17:31Z")
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 ---
**Author:** ![Collin\_Allen](https://avatars.discourse-cdn.com/v4/letter/c/7993a0/32.png) [@Collin\_Allen](https://forum.ansible.com/u/Collin_Allen)\ **Post date:** [April 7, 2013, 8:00pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/9 "2013-04-07T20:00:13Z")
Allowing multiple conditions by specifying a list to "when:" like you suggested would be wonderful! ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [April 7, 2013, 11:03pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/10 "2013-04-07T23:03:52Z")
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. ---
**Author:** ![rektide](https://avatars.discourse-cdn.com/v4/letter/r/a88e57/32.png) [@rektide](https://forum.ansible.com/u/rektide)\ **Post date:** [April 10, 2013, 6:51pm UTC](https://forum.ansible.com/t/upgraded-variables-and-conditionals-in-1-2-feedback-welcome/12639/11 "2013-04-10T18:51:52Z")
This sounds super fantastic, and I hope it's indeed true. Here's an example using these stanzas: