I didn't realize if you had a *../group_vars/Debian* file and ran the task
*group_by:
key={{ansible_os_family}}* on a Debian family host that in the next play
those vars will be available. I just tried it though, and it works. Is that
what you mean?
If so...one final question (hopefully). If I had *../group_vars/Debian* and
*../group_vars/DebianUbuntu* but both files defined the same variable,
would the precedence be defined by which *group_by* I run first?
Thank you,
Mark
On Tuesday, January 7, 2014 4:38:35 PM UTC-6, Michael DeHaan wrote:
>
> That strikes me as making things a bit too complicated, I'd probably just
> look into putting your hosts into a group and assigning the variables to a
> group via group_vars and keeping it simple.
>
> But that's me.
>
>
>
>
> On Tue, Jan 7, 2014 at 5:17 PM, Mark Casey <mark....@gmail.com<javascript:>
> > wrote:
>
>> ...two things.
>>
>> The ../vars/main.yml file shown in the gist (the second file option to
>> each with_first_found) only defines one dummy variable. It does not hold
>> defaults; it only exists for when you don't need to set anything at a
>> particular level and so have no main.yml file in the first-given, specific
>> path.
>>
>> Also, I guess it would be easier to drop the host init part of my
>> goal/question here and just say I want a portable role that groups hosts
>> and imports variables for them. That is, as you said, more what is breaking
>> the rules.
>>
>>
>> On Tuesday, January 7, 2014 11:35:50 AM UTC-6, Mark Casey wrote:
>>>
>>> Hi Michael,
>>>
>>> Thanks for your response. I think what I'm wanting to do sort of falls
>>> through the cracks with regards to best practices...at least the way I'm
>>> attempting it.
>>>
>>> I'm trying to do something like what this excerpt from the Ansible EC2
>>> page describes (http://docs.ansible.com/guide_aws.html#example-2):
>>>
>>>> *Example 2: I’m using AutoScaling to dynamically scale up and scale
>>>> down the number of instances. This means the number of hosts is constantly
>>>> fluctuating but I’m letting EC2 automatically handle the provisioning of
>>>> these instances. I don’t want to fully bake a machine image, I’d like to
>>>> use Ansible to configure the hosts.*
>>>
>>>
>>> So I'm not actually using AutoScaling, but generally speaking I do want
>>> to use Ansible to initialize new hosts with a one-time prep procedure (that
>>> happens before applying more traditional roles) as opposed to baking in
>>> changes to VM templates (templates of any type, not just AMIs). *TLDR:
>>> To that end, I'm trying to write a portable role that does a more
>>> comprehensive job of setting variables (like the apache service name, or a
>>> list of system accounts like 'games' to remove from new hosts, or a
>>> per-distro list of files to remove setuid from) to different values for
>>> different hosts based on things like OS family or distro version.*
>>>
>>> Here is what I've got at the moment, which I've been tinkering at very
>>> intermittently over the last few months... it is the main.yml for a
>>> var-setter role: https://gist.github.com/mark-casey/8302657
>>>
>>> IMvHO the real problem is that new host initialization (which I'd define
>>> as doing a bunch of one-time tasks on several classes of dissimilar hosts)
>>> is sort of the antithesis of the way Ansible is supposed to be used.
>>>
>>> Would you happen to have any thoughts or advice on this?
>>>
>>> Thank you,
>>> Mark
>>>
>>>
>>> On Monday, January 6, 2014 7:04:07 PM UTC-6, Michael DeHaan wrote:
>>>>
>>>> Roles shouldn't contain knowledge of groups.
>>>>
>>>> The job of a play is to map roles onto groups.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jan 6, 2014 at 6:49 PM, Mark Casey <mark....@gmail.com> wrote:
>>>>
>>>>> Thank you for the suggestions! Unless I'm misunderstanding though, it
>>>>> seems that requiring calls to multiple roles from within the parent would
>>>>> really cut down on the portability of the role. I'm hoping to be able to
>>>>> simply call the role without parameters and have it work, and call any
>>>>> role
>>>>> dependencies (once I set them up) as needed.
>>>>>
>>>>> Though not quite ideal, I think I just found a way just a moment ago
>>>>> to do this and also merge the two roles I had into just one. Since I only
>>>>> have a few tasks left in the role after the group_by, I'm simply using
>>>>> "when: group1 in group_names", then for another task "when: group2 in
>>>>> group_names". So it isn't real pretty because you get skipped tasks in
>>>>> the
>>>>> output, but as far as I can tell the group_by groups are added to
>>>>> group_names immediately and it is working well so far.
>>>>>
>>>>> Thanks for your time,
>>>>> Mark
>>>>>
>>>>>
>>>>> On Mon, Jan 6, 2014 at 4:55 PM, Kahlil Hodgson <
>>>>> kahlil....@dealmax.com.au> wrote:
>>>>>
>>>>>> I've never tried this but I would think you could just use the hosts
>>>>>> option in the the parent playbook?
>>>>>>
>>>>>> Something like:
>>>>>>
>>>>>> - hosts: all
>>>>>> roles:
>>>>>> - generate_groups # generates group1, group2, etc
>>>>>>
>>>>>> - hosts: group1
>>>>>> roles:
>>>>>> - do_something_with_a_group
>>>>>>
>>>>>> Otherwise you might try:
>>>>>>
>>>>>> - hosts: all
>>>>>> roles:
>>>>>> - { role:do_something_with_a_group, when: inventory_host in
>>>>>> groups["group1"] }
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 Tue, Jan 7, 2014 at 7:30 AM, Mark Casey <mark....@gmail.com>
>>>>>> wrote:
>>>>>> > Hello everyone,
>>>>>> >
>>>>>> > My situation is that my playbook calls a role to split my hosts up
>>>>>> using
>>>>>> > group_by. I then immediately call another role in which I want to
>>>>>> use the
>>>>>> > newly created groups.
>>>>>> >
>>>>>> > The problem is that in the second role I cannot (to my knowledge)
>>>>>> start new
>>>>>> > plays within ../role/task/main.yml to use the hosts: option to
>>>>>> limit by
>>>>>> > these new groups. Can I use when to limit which tasks run in the
>>>>>> second role
>>>>>> > instead (I realize this might cause a lot of skipped tasks)?
>>>>>> >
>>>>>> > Please let me know if my description is too brief/confusing, I
>>>>>> didn't want
>>>>>> > to make anyone read a novel.
>>>>>> >
>>>>>> > Thank you,
>>>>>> > Mark
>>>>>> >
>>>>>> > --
>>>>>> > 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.
>>>>>> > To post to this group, send email to ansible...@googlegroups.com.
>>>>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "Ansible Project" group.
>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>>> topic/ansible-project/oc8IjKx3uuw/unsubscribe.
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> ansible-proje...@googlegroups.com.
>>>>>>
>>>>>> To post to this group, send email to ansible...@googlegroups.com.
>>>>>> 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 ansible-proje...@googlegroups.com.
>>>>> To post to this group, send email to ansible...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael DeHaan <mic...@ansibleworks.com>
>>>> 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-proje...@googlegroups.com <javascript:>.
>> To post to this group, send email to ansible...@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.
To post to this group, send email to ansible-project@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
