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]> 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]. > 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.
