provider/openstack: Ignore order of security_groups in instance

[Sheile]

Problems

When execute terraform plan after terraform apply with same template by provider/openstack, sometimes output some changes of securitygroups.
This problem is occurred when created securitygroups have mismatched between order of ID and order of security_groups attribute in template like below.

resource "openstack_compute_instance_v2" "server" {
  name = "terraform-server"
  security_groups = ["${openstack_compute_secgroup_v2.sg1.name}", "${openstack_compute_secgroup_v2.sg2.name}"]
}

# nova secgroup-list
+--------------------------------------+---------+---------------------------+
| Id                                   | Name    | Description               |
+--------------------------------------+---------+---------------------------+
| 483d055e-54f3-43f5-b24f-2e33610c4ad6 | default | default                   |
| ab3ac38f-c185-4232-a4bd-cac3b1455aa2 | sg1     | terraform_security_group1 |
| 71834dc8-e73e-41f5-a191-66f8007b92ae | sg2     | terraform_security_group2 |
+--------------------------------------+---------+---------------------------+

If assigned ID of sg1 larger than ID of sg2, terraform plan will output following changes.

$ terraform plan

~ openstack_compute_instance_v2.ap_server
    security_groups.0: "sg2" => "sg1"
    security_groups.1: "sg1" => "sg2"


Plan: 0 to add, 1 to change, 0 to destroy.

I think this problem is relevant to openstack API response to get server information.
Following request return security_groups that is sorted by ascending order on ID. In addition, these response hasn't ID attribute.

curl -H "X-Auth-Token: *****************" http://localhost:8774/v2/*************/servers/***************** | jq .server.security_groups
[
  {
    "name": "sg2"
  },
  {
    "name": "sg1"
  }
]

Fix

Order of SecurityGroups can be ignored. I changed security group from TypeList to TypeSet.

[jtopjian]

@phinze This is the same solution that was suggested in #2284. Unfortunately it was rolled back due to concerns about schema migrations. I left a question in #2284 about whether a schema migration is really needed as I was unable to break anything by launching resources, switching to the patched version, then resuming work. Thoughts?

[phinze]

@jtopjian Ah yes, the reason nothing broke is because - as the state representation is currently implemented - a TypeSet can be successfully parsed out of the state for an attribute that was stored in the TypeList format. It's a bit of a cheat semantically speaking, but I think we should be able to use it successfully.

[phinze]

To be clear: after the first run with the newer version of Terraform - the state version will be stored in the standard TypeSet format. You saw this in your testing as well as the monotonically increasing integers switched to hashcodes.

[jtopjian]

@phinze So this should be OK to merge without a schema migration? With the understanding that this was, more or less, a lucky break?

[phinze]

Yep - sounds about right. Merge away! ( See #3696 (comment) for my merge+changelog crash course. 👌 )

[jtopjian]

okie dokie. acceptance tests pass.

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