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<javascript:>
> > 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<javascript:>
>> > 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<javascript:>> 
>>> 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 <javascript:>.
>>> > To post to this group, send email to 
>>> > ansible...@googlegroups.com<javascript:>
>>> .
>>> > 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 <javascript:>.
>>>
>>> To post to this group, send email to 
>>> ansible...@googlegroups.com<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 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.

Reply via email to