k5_server_group - multiple same-name groups created

[andyeff]

What looks like a quirk with K5 Openstack means that multiple server groups can be created with the same name.

My example uses four servers, two in AZ1 and two in AZ2. I group these in the inventory and have the following in a group_var:

---
server_group:
   name: "NPR-SMG-Affinity-Group-{{ az_suffix }}"
   policy: "anti-affinity"

The az_suffix is picked out of pre-defined "uk-1a" and "uk-1b" variables.

This is in turn used by a task in a build-server role to do the following:

- name: Create servergroups if required
  k5_server_group:
    state: present
    k5_auth: "{{ k5_auth_reg.k5_auth_facts }}"
    name: "{{ server_group.name }}"
    availability_zone: "{{ az }}"
    policies: "{{ server_group.policy }}"
  register: af_group
  when:  server_group is defined
  delegate_to: localhost

I would therefore expect when running a playbook that utilises this to create one server group per AZ, however when running a playbook the following is observed:

Output from Ansible Tower:

TASK [k5_buildvm : Create servergroups if required] ****************************
changed: [kpppsmg001 -> localhost]
changed: [kpppsmg003 -> localhost]
changed: [kpppsmg002 -> localhost]
changed: [kpppsmg004 -> localhost]

Output from Openstack 'server group list'

+--------------------------------------+--------------------------------+---------------+
| ID                                   | Name                           | Policies      |
+--------------------------------------+--------------------------------+---------------+
| d0ef9abf-efaa-4af1-b700-5b9f1bb56fd5 | NPR-SMG-Affinity-Group-az1     | anti-affinity |
| 5c98d9af-eecf-4c3e-9449-dd27c0d3a8c3 | NPR-SMG-Affinity-Group-az1     | anti-affinity |
| c6e582c9-b233-41b0-bff6-0645bec04cb4 | NPR-SMG-Affinity-Group-az2     | anti-affinity |
| 2dcf9347-200a-40bc-a91c-fa2c16add80b | NPR-SMG-Affinity-Group-az2     | anti-affinity |
+--------------------------------------+--------------------------------+---------------+

Each server is placed inside its own unique server group, instead of the desired outcome of two servers in their own matching AZ group.

I suppose this might be an unsolvable problem due to Openstack not treating the server group names as unique and allowing multiple ID's to share the same name, but I felt like raising it as an issue to see if there's anything that can be done around this.

[andyeff]

Extra observation: If the playbook is run again, no new server groups are created - the module / openstack recognise that groups already exist and no more are created.

I imagine the original problem is therefore because the task is being run once per machine simultaneously. Perhaps using a serial:1 on the task that creates server_group might work so it only processes one at a time. I shall test this now.

EDIT - ok scratch that idea, I thought serial was supported per task but it is not. I'd have to have a separate play / role that ran with serial: 1 , and that has some time/scaling issues anyway if a large number of servers are being processed.

[andyeff]

A hack-y way of doing it might be to have two tasks, that have run_once specified, and are targeted per-AZ somehow, based off which AZ vm's are going to be in (so it only runs one task if only az1 machines are being built, but three times if you're build in three zones for example) EDIT - I suspect this would fail as subsequent VM's would not have the registered fact available to them and therefore would fail during os_server when af_group.server_group.id is attempted to be parsed. (or, potentially worse, build the server anyway but not place it in a group because a default(omit) is used)

[mohclips]

ah yes, GUID is king here. To get around this maybe the best idea is to create the server group outside of creating the servers. a new layer in your stack between network creation and server creation?

of course you would need to get the server group facts before you build the server and as there is not module for this (k5_server_group_facts) then a 'uri' module call would be needed to get that json.

[andyeff]

Cheers Nick,

I tried not to spend too much time on this but ended up thinking more about it some more ..

Assuming the server group creation can be done elsewhere in the same playbook, using k5_server_group with state: list will return the groups which can then be processed for later.

So, if we were creating a group per host the os_server param would be:

scheduler_hints:  "{% if server_group is defined %}group={{ af_group.server_group.id }}{% else %}{{ server_group | default(omit) }}{% endif %}"

However if we instead pre-create the groups and use k5_server_groups to get a list back, we can change this to something along the lines of

scheduler_hints:  "{% if server_group is defined %}group={{ af_group | json_query(\"af_group.server_groups[?name=='\" + server_group.name + \"'].id\") }}{% else %}{{ server_group | default(omit) }}{% endif %}"

Where server_group.name is something in a group_var for a group of servers, for example.

This way we still have the ease of use of being able to use names and not have to rely on a fixed GUID being present.

(The escaping of that json_query filter to support server_group.name being a variable seems messy, but I wasn't able to get it to work otherwise)

[mohclips]

glad you got it sorted, can we close this now?

[andyeff]

Yeah sure - it's a limitation of K5 that needs working around, not something the module can fix :)