Well ideological quibbles aside it turns out the method above isn't working
as well as I'd initially though and it seems like there might be some
inconsistent behavior with the yum module. My initial test had only one rpm
defined for a host and that worked, but adding any additional RPMS to the
group var file fails with:
One or more undefined variables: 'dict' object has no attribute 'foo, baz'
Inserting a debug line in place of the yum call shows that it seems to be
looping correctly:
debug: msg="yum name={{ item }}-{{ package_versions[item] }} state=present"
yields:
ok: [host1] => (item=foo) => {"item": "foo", "msg": "yum
name=foo-1.1.19-1 state=present"}
ok: [host1] => (item=baz) => {"item": "baz", "msg": "yum
name=baz-6.11.1-1 state=present"}
I believe the yum module condenses with_items lists to run a single
invocation of yum rather than repeatedly for each item and I wonder if that
is somehow being tripped up by the nested data structure.
Also, if it's relevant this is ansible 1.3.4 (I cannot upgrade immediately
but will be in the very near future)
On Tuesday, January 7, 2014 5:59:16 PM UTC-6, Michael DeHaan wrote:
>
> " Don't get me wrong, the examples are really great but they tend to
> break down as soon as you want to something outside of the norm."
>
> Ansible is a KISS system. I would recommend asking questions like "how
> do I do this" on the mailing list rather than "here's something I did
> complicated, please fix" and you will get more idiomatic answers. What you
> are doing, with having multiple versions of bloop as hashes in a single
> list is *weird*, and you'll get better examples of "how would I model
> something like this", rather than us trying to tweak your example, and
> you'll learn a bit more in the process too.
>
> "My experience so far is that it's been wonderfully easy to find examples
> how to do the normal things but it becomes an exercise in trial and error
> when you can't find a close example to work off of."
>
> We prefer including best practices examples and things that are idiomatic
> of the way Ansible should be used in the field rather than arbitrary
> examples most of the time.
>
> As you have probably found in the docs you should also look at:
>
> http://github.com/ansible/ansible-examples
>
> For some complete things, used end to end.
>
>
>
>
> On Tue, Jan 7, 2014 at 6:11 PM, Richard Schick
> <[email protected]<javascript:>
> > wrote:
>
>> Thanks, that page is a good representation of where examples are used
>> when a less conversational tone would also be helpful. Don't get me wrong,
>> the examples are really great but they tend to break down as soon as you
>> want to something outside of the norm. Using that page as an example it
>> would be helpful to see a straight list of all special characters that the
>> YAML interpreter will key off of and what they mean, two things that jump
>> to mind are comments and single brackets (which were instrumental in my
>> problem). Single brackets aren't listed at all and comments aren't
>> mentioned beyond an appearance in one of the examples (it is admittedly
>> trivial to figure out comments from the example).
>>
>> My experience so far is that it's been wonderfully easy to find examples
>> how to do the normal things but it becomes an exercise in trial and error
>> when you can't find a close example to work off of.
>>
>>
>> On Tuesday, January 7, 2014 4:39:36 PM UTC-6, Michael DeHaan wrote:
>>
>>> 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] <javascript:>.
>>
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Michael DeHaan <[email protected] <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 [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
