Dmitry, this is the solution to the ultimate problem I've been having.
Thanks!!!!
On Wednesday, October 29, 2014 at 1:09:02 AM UTC-7, Sankalp Khare wrote:
>
> I second Giorgio. Dmitry, you're a lifesaver :D
>
> On Friday, 6 December 2013 03:46:13 UTC-6, Giorgio Crivellari wrote:
>>
>>
>> Dmitry you're a f***** genius!!
>>
>> Michael, please add Dimitry example in variables website documentation
>> page... many users will appreciate!
>>
>> Thanks guys!
>> Giorgio
>>
>> Il giorno venerdì 6 dicembre 2013 00:03:59 UTC+1, Dmitry Horbach ha
>> scritto:
>>>
>>> Though I couldn't find anything related within past days - I just found
>>> solution to my problem using following vars :)
>>>
>>> users:
>>> userA: 800
>>> user: userA
>>> user_uid: "{{ users[user] }}"
>>>
>>> data:
>>> type1:
>>> key: value1
>>> type2:
>>> key: value2
>>> type: type1
>>> type_key: "{{ data[type].key }}"
>>>
>>> Thanks
>>>
>>> On Friday, December 6, 2013 12:30:50 AM UTC+3, Michael DeHaan wrote:
>>>>
>>>> I feel like I've answered this a lot in the last 2 days, see the
>>>> archives and we can add an entry in the FAQ.
>>>>
>>>> -- Michael
>>>>
>>>> On Dec 5, 2013, at 4:29 PM, Dmitry Horbach <dim.h...@gmail.com> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> We are also using double evaluation in many places - mostly to not
>>>> repeat definitions of the same variable
>>>>
>>>> *Example 1*
>>>>
>>>> user.yml - user uid values
>>>>
>>>> userA: 800
>>>> userB: 801
>>>>
>>>> main.yml - role variables
>>>>
>>>> user: userA
>>>> user_uid: ${${user}} # will be resolved to 800
>>>>
>>>> *Example 2*
>>>>
>>>> type1_data:
>>>> var1: value1
>>>> var2: value1
>>>> type2_data:
>>>> var1: value2
>>>> var2: value2
>>>>
>>>> type_data: ${${type}_data}
>>>> type_var1: ${type_data.var1}
>>>> type_var2: ${type_data.var2}
>>>>
>>>> By overriding single variable we get different plays (all var blocks
>>>> can be defined in role and block selection can go to single var in
>>>> vars_files)
>>>> This also allows command line override with -e option by passing just
>>>> one key=value.
>>>>
>>>> What will be the appropriate way to use those after old syntax removed?
>>>>
>>>>
>>>> On Wednesday, December 4, 2013 4:26:54 AM UTC+3, Michael DeHaan wrote:
>>>>>
>>>>> Yeah this is a very outdated usage of legacy variables, and a bit of
>>>>> an anti-pattern whenever you want to define a variable by a variable
>>>>> name.
>>>>> (There's a reason even Perl tries to discourage this, and that's Perl).
>>>>>
>>>>> I don't know where you are defining "jobprofile", but can we step back
>>>>> and talk about the use case?
>>>>>
>>>>> Public service announcement, variables look like this:
>>>>>
>>>>> foo: "{{ bar }}"
>>>>>
>>>>> And if you want to get at a variable by name that is scoped to a host,
>>>>> you can do so if you want -- which you won't need often -- like so:
>>>>>
>>>>> {{ hostvars[inventory_hostname][fact_name] }}
>>>>>
>>>>> This doesn't of course apply to the host specifier -- we haven't even
>>>>> got to figure out what host we've talked to yet, hence I'm wanting to
>>>>> understand more.
>>>>>
>>>>> This seems like a case better suited to seperate inventory files, or
>>>>> the case of a dynamic inventory script, the dynamic inventory script
>>>>> responding to an environment variable.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 3, 2013 at 2:17 AM, Giorgio Crivellari <miti...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I used to use "hosts" property, in ansible playbook, dinamically for
>>>>>> example:
>>>>>>
>>>>>>> hosts: ${$jobprofile.hosts}
>>>>>>
>>>>>> where $jobprofile was an external variable that allow me to change
>>>>>> hosts based on profile.
>>>>>>
>>>>>> Since last 1.4 version, my previous playbook doesn't works any more.
>>>>>> Have you some suggestion to do an EVAL into a playbook?
>>>>>>
>>>>>> Thanks
>>>>>> Giorgio
>>>>>>
>>>>>> --
>>>>>> 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 ansible-proje...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael DeHaan <mic...@ansibleworks.com>
>>>>> CTO, AnsibleWorks, Inc.
>>>>> http://www.ansibleworks.com/
>>>>>
>>>>> --
>>>> 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 ansible-proje...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
--
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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/1ea30193-bf57-4fb3-b025-da290cac3afa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
