Glad that helped :-)

Just to note, the {{ variable }} syntax is preferred over the old
${variable} syntax, and I believe there are plans to remove the old
syntax in version 1.5.

K

Kahlil (Kal) Hodgson                       GPG: C9A02289
Head of Technology                         (m) +61 (0) 4 2573 0382
DealMax Pty Ltd                            (w) +61 (0) 3 9008 5281

Suite 1415
401 Docklands Drive
Docklands VIC 3008 Australia

"All parts should go together without forcing.  You must remember that
the parts you are reassembling were disassembled by you.  Therefore,
if you can't get them together again, there must be a reason.  By all
means, do not use a hammer."  -- IBM maintenance manual, 1925



On Wed, Jan 8, 2014 at 9:21 AM, Richard Schick <[email protected]> wrote:
> Thanks so much Kal, that did the trick. I suspected something like that was
> possible but I couldn't find a good example.
>
> Being new to ansible the syntax has been a bit frustrating to muddle through
> which is part of what had me stumped here.  The many real world examples in
> the documentation are very helpful but it's difficult to find a straight
> description of how things work.  I suspect it's because there is assumption
> that YAML is described elsewhere but it would be helpful if there was a
> formatting/syntax guide was direct explanations instead of relying on
> examples. For example, in this case ${variable} is behaving differently than
> {{variable}} and my initial searching isn't revealing exactly what the
> differences are without having to infer it from a collection of examples.
>
>
> On Tuesday, January 7, 2014 2:32:48 PM UTC-6, Kahlil Hodgson wrote:
>>
>> Looks like you want to look up a package version by package name:
>>
>> ## Vars file
>> version_for_package:
>>   foo: 1.1.19-1
>>   bar: 3.11.0-6
>>   baz: 6.11.1-1
>>   ...
>>
>> ## Task
>> - name: update packages
>>     action: yum name={{ item }}-{{ version_for_package[item] }}
>> state=present
>>     with_items: packages
>>
>> Kahlil (Kal) Hodgson                       GPG: C9A02289
>> Head of Technology                         (m) +61 (0) 4 2573 0382
>> DealMax Pty Ltd                            (w) +61 (0) 3 9008 5281
>>
>> Suite 1415
>> 401 Docklands Drive
>> Docklands VIC 3008 Australia
>>
>> "All parts should go together without forcing.  You must remember that
>> the parts you are reassembling were disassembled by you.  Therefore,
>> if you can't get them together again, there must be a reason.  By all
>> means, do not use a hammer."  -- IBM maintenance manual, 1925
>>
>>
>>
>> On Wed, Jan 8, 2014 at 7:20 AM, Michael DeHaan <[email protected]>
>> wrote:
>> > Not sure why you are keeping the list of multiple versions in there, but
>> > sounds like you should define a nested datastructure or an array or
>> > something.
>> >
>> >
>> >
>> > On Tue, Jan 7, 2014 at 2:17 PM, Richard Schick <[email protected]>
>> > wrote:
>> >>
>> >> Greetings,
>> >> We have long list of packages with versions that change frequently,
>> >> those
>> >> packages need to be installed on quite a lot of servers but each server
>> >> needs a different combination of those packages. Defining a role or set
>> >> of
>> >> group vars that lists each package and it's version works fine except
>> >> that
>> >> managing the versions is very unwieldy because the versions change
>> >> daily and
>> >> we need to maintain parallel stacks of servers that have different
>> >> package
>> >> versions.
>> >>
>> >> The way I have it working is with a central list of all packages in a
>> >> var
>> >> file with their versions, then group var files that list the packages
>> >> that
>> >> need to be installed.  The play iterates over the central package list
>> >> for
>> >> each item in the group vars file to find a name match and grab the
>> >> version.
>> >> This is working great except for one highly annoying issue, when the
>> >> playbooks run it outputs 'skipping' for each package from the central
>> >> file
>> >> that isn't matched to the current item in the group var list.  With
>> >> many
>> >> dozen packages and many dozen hosts this results in an overwhelming
>> >> stream
>> >> of 'skipping' messages, it also seems like it's fairly inefficient and
>> >> could
>> >> eventually run into scale issues.
>> >>
>> >> Here is roughly how it's setup:
>> >> =============================
>> >> The central file with versions
>> >> =============================
>> >> packages.yml:
>> >> package_versions:
>> >>  - { name: "foo", version: "1.1.19-1" }
>> >>  - { name: "bar", version: "3.11.0-6" }
>> >>  - { name: "baz", version: "6.11.1-1" }
>> >>  - { name: "blah", version: "3.8.0-1" }
>> >>  - { name: "bleep", version: "3.10.0-1" }
>> >>  - { name: "bloop", version: "0.11.1-1" }
>> >>
>> >> =============================
>> >> Group vars
>> >> =============================
>> >> group_vars/host1:
>> >> ---
>> >> packages:
>> >>  - foo
>> >>  - baz
>> >>  - bleep
>> >>
>> >> group_vars/host2:
>> >> ---
>> >> packages:
>> >>  - bar
>> >>  - blah
>> >>  - bleep
>> >>
>> >> group_vars/host3:
>> >> ---
>> >> packages:
>> >>  - bar
>> >>  - foo
>> >>  - bleep
>> >>
>> >> =============================
>> >> The task
>> >> =============================
>> >>  - name: update packages
>> >>     action: yum name=${item.name}-${item.version} state=present
>> >>     with_items: package_versions
>> >>     when: item.name in ${ packages }
>> >>
>> >>
>> >> So that works but I would be a lot happier if it didn't iterate over
>> >> the
>> >> full central list of packages for each item and instead used the
>> >> package
>> >> name from the group vars as a key to grab the version from that central
>> >> list.  I haven't been able to find a way to grab a key value pair out
>> >> of a
>> >> list by directly referencing the key and hopefully I'm just missing
>> >> something simple.
>> >>
>> >> Any help would be greatly appreciated, I'm drowning in 'skipping'
>> >> messages.
>> >>
>> >> --
>> >> 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].
>> >> 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].
>> > To post to this group, send 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].
> 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].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to