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.
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
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 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.
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?
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.
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.
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?
I realized how easy it would be to test the precedence so I did so, and yes, the order you run the group_by is the factor that determines which var wins.
That is way simpler… I’ll try rewriting some stuff that way and see if it feels any less flexible. Thanks again!!
Suppose you defined in inventory a group named “DebianUbuntu” that had child groups “Debian and Ubuntu”. The child group variables would override the parent.
I’m not sure of any fact that is producing a group called “DebianUbuntu” but theoretically if you had, say, another group based on host architecture, variable precedence of two groups at the same depth relative to the root group is undefined.