...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]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
