Hi Michael,
thanks for you response and for this awesome tool!

We're using it for deployment jobs, as post-build of jenkins jobs, and 
we're trying to do something like this:

-------------- job playbook ---------------
- vars:
   devel:
     host: "host02"
   prod:
     host: "host01"

  hosts: $vars[$prof][host]

  tasks:
  - debug: msg="Hello"
---------------------------------------------------------

ansible playbook is called passing extra var called prof (that is profile) 
and, according with that, we want to use proper host group.

We would like to use a single job playbook for each jenkins job to avoid 
multiple file to maintain.

Thanks for support!

Giorgio


Il giorno mercoledì 4 dicembre 2013 02:26:54 UTC+1, Michael DeHaan ha 
scritto:
>
> 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<javascript:>
> > 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 <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Michael DeHaan <mic...@ansibleworks.com <javascript:>>
> 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-project+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to