Within a role... trying to use a group_by created in the previously run role

[Mark Casey]

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

[Kahlil Hodgson]

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

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

[Mark Casey]

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

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.

[Michael DeHaan]

Roles shouldn't contain knowledge of groups.

The job of a play is to map roles onto groups.

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Mark Casey]

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

[Mark Casey]

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

[Michael DeHaan]

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.

[Mark Casey]

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

[Mark Casey]

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!!

On Wednesday, January 8, 2014 11:06:49 AM UTC-6, Mark Casey wrote:

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.

...

[Michael DeHaan]

First question -- yep!

Second question -- 

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.

I'd go with the first option.