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]<javascript:> > > 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]<javascript:>> >> 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] <javascript:>. >> > To post to this group, send email to >> > [email protected]<javascript:> >> . >> > 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] <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.
