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 <[email protected]> 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 <[email protected]>
>>>>> 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 [email protected].
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael DeHaan <[email protected]>
>>>>> 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 [email protected].
>>>> 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 [email protected].
To post to this group, send email to [email protected].
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.
