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/f4e3f6ac-7a08-4bc5-8914-59866a59aaf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
