provider/openstack openstack_compute_instance_v2 security_groups does not properly handle UUIDs

[jhoblitt]

The openstack_compute_instance_v2 resource accepts secgroups by both name and id. However, when using an id, the behavior is non-idempotent. The first apply succeeds but any successive plan/apply compares the current state of the resource by name with the declared id. Apply will fail attempting to "change" the security groups. These goofy semantics are likely the fault of the openstack API -- perhaps some heuristic matching could be apply to detect uuids?

resource "openstack_compute_instance_v2" "ctrl" {
  ...
  security_groups = [
      "${openstack_compute_secgroup_v2.bastion.id}",
      "${openstack_compute_secgroup_v2.internal.id}"
  ]
  ...
}

Output from initial apply

openstack_compute_instance_v2.ctrl: Creating...
  ...
  security_groups.#:                    "" => "2"
  security_groups.1187708532:           "" => "af7cba8d-5c35-4866-bb87-8fb6dd3247b7"
  security_groups.3338006936:           "" => "e4a24898-4f7f-42a1-bd6e-6f0e8650de8d"
  ...

Output from plan after an apply:

~ openstack_compute_instance_v2.ctrl
    security_groups.1187708532: "" => "af7cba8d-5c35-4866-bb87-8fb6dd3247b7"
    security_groups.3338006936: "" => "e4a24898-4f7f-42a1-bd6e-6f0e8650de8d"
    security_groups.4080450739: "slurm_bastion" => ""
    security_groups.779637287:  "slurm_internal" => ""

[jtopjian]

@jhoblitt Yup, this is a painful inconsistency with the OpenStack API. There are some details about it in #4319 and here.

I'm going to leave this open to revisit and see if there's a way to get this working.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.