It's going to be removed in 1.6 but already throws deprecation warnings.

As for YAML, http://docs.ansible.com/YAMLSyntax.html


On Tue, Jan 7, 2014 at 5:36 PM, Kahlil Hodgson <
[email protected]> wrote:

> 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.
>



-- 
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.

Reply via email to