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 <[email protected]<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 <[email protected]> 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 <
>>>>> [email protected]> 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 <[email protected]>
>>>>>> 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 [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 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
>>>>>> [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.
