Problems when setting OpenStack security groups for an instance by ID

[dupuy]

My OpenStack Terraform configuration file contains lines like these:

provider "openstack" {
    auth_url = "${var.auth_url}"
    tenant_name = "${var.tenant}"
}

module "dmz" {
    source = "github.com/pitmine/ext-net"

    region = "${var.region}"
    name = "${var.tenant}-dmz"
    subnet = "10.42.0.0/23"
    external_gateway = "${var.external_gateway}"
    tenant_id = "${lookup(var.tenant_ids,var.tenant)}"
}

resource "openstack_compute_secgroup_v2" "https_server" {
    region = "${var.region}"
    name = "https-server"
    description = "Public HTTPS Server on 443/tcp"
    rule {
        from_port = 443
        to_port = 443
        ip_protocol = "tcp"
        cidr = "0.0.0.0/0"
    }
}

resource "openstack_compute_instance_v2" "webserver" {
    region = "${var.region}"
    name = "webserver"
    image_name = "${var.host_image}"
    flavor_name = "m1.small"
    security_groups = [
        # can't use name as any duplicate causes conflictingRequest error
        "${openstack_compute_secgroup_v2.https_server.id}",
        "default"
    ]
    network {
        uuid = "${module.dmz.uuid}"
    }
 }

variable "auth_url" {
    description = "Keystone authentication URL"
}

variable "tenant" {
    description = "OpenStack tenant to be terraformed"
}

variable "tenant_ids" {
    default = {
     example = "a2be8b04bad045df90575b3eb6e530ee"
    }
}

variable "region" {
    description = "Hosting region"
    default     = "RegionOne"
}

variable "host_image" {
    description = "Name of Linux distribution image for normal host instances"
    default     = "cirros"
}

variable "external_gateway" {
    description = "Network UUID for external (public) Internet"
}

As noted in the comment, I use the id attribute of the openstack_compute_secgroup_v2 objects because it is guaranteed to be unique and won't fail to be created because of some left-over secgroup object with the same name.

However, when I run terraform plan a second time, I get the following output:

~ openstack_compute_instance_v2.webserver
    network.0.uuid:    "25655a37-d7a2-44d4-8c8c-e0ccb706a74c" => "2411593d-2a82-4861-8415-8015470b39d0"
    security_groups.0: "default" => "ebb87443-4866-4f4e-b521-a18a1a8c8d86"
    security_groups.1: "https-server" => "default"``

And running `terraform apply a second time will remove the http_server secgroup from the instance (a third apply will bring it back):

$ terraform apply
Modifying...
  network.0.uuid:    "25655a37-d7a2-44d4-8c8c-e0ccb706a74c" => "2411593d-2a82-4861-8415-8015470b39d0"
  security_groups.0: "default" => "ebb87443-4866-4f4e-b521-a18a1a8c8d86"
  security_groups.1: "https-server" => "default"
openstack_compute_instance_v2.webserver: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

$ terraform plan
...
~ openstack_compute_instance_v2.webserver
    network.0.uuid:    "25655a37-d7a2-44d4-8c8c-e0ccb706a74c" => "2411593d-2a82-4861-8415-8015470b39d0"
    security_groups.#: "1" => "2"
    security_groups.0: "default" => "ebb87443-4866-4f4e-b521-a18a1a8c8d86"
    security_groups.1: "" => "default"

$ terraform apply
openstack_compute_instance_v2.webserver: Modifying...
  network.0.uuid:    "25655a37-d7a2-44d4-8c8c-e0ccb706a74c" => "2411593d-2a82-4861-8415-8015470b39d0"
  security_groups.#: "1" => "2"
  security_groups.0: "default" => "ebb87443-4866-4f4e-b521-a18a1a8c8d86"
  security_groups.1: "" => "default"
openstack_compute_instance_v2.webserver: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
...

The problem is that the Terraform OpenStack provider is attempting to match the names to the ids, and doesn't have code to do that. But this would be cosmetic and only a minor annoyance, if it were not for the fact that the provider implements secgroup changes as "add then remove." In this case, the https_server group is added (by id), which is a no-op as it is already present with the specified id. However, the remove step is not a no-op, since it removes the secgroup named "https_server." Repeated application continues to remove and re-add the secgroup.

A better approach would be at a minimum to do "remove before create" since the removal by name would be very quickly undone by the (re-)addition of the secgroup by id.

If the provider could detect that an id matched a name and not mark it as changed, that would be even better, and would remove the several second "gap" when the secgroup is removed but before it is re-added.

I've submitted a PR ( #2008) for the "remove before create" change that works for me.

[jtopjian]

It looks like there are a few issues with the current security group implementation:

1. There may be a bug with the diffs between secgroupsToAdd and secgroupsToRemove. Does provider/openstack: minor fixes to compute and router resources #1848 change this at all?
2. If someone tries to create a security group in Terraform that uses an existing name, maybe Terraform should just use that security group and not make a new one with a duplicate name.
3. Specifying a secgroup ID and canonical name should act on the same security group. Maybe if a secgroup is specified by name, its ID should be looked up and used.

[dupuy]

Thanks for the pointer to #1848 - there are gratuitous changes even when using security group names, and it looks like that PR would fix that problem. I'll merge it into my local copy and see how it works. However, it is just one of the issues, and fairly orthogonal.

As for (re)using an existing security group with the same name, I'm conflicted - the same arguments pro and con would apply to nearly every other OpenStack resource type; I'm dubious that it would make sense to change just security groups.

On the third point, right now if you specify by name, it does what you want unless there are duplicates, in which case you get an error during apply. If the ID were looked up during planning and recorded, we could fail on ambiguity earlier, which is definitely an improvement (it's annoying when a "valid" plan fails during apply).

[jtopjian]

I agree re Point 2. The reason I brought it up is because someone mentioned this ability back when this provider was being developed. I didn't want to introduce personal bias... perhaps this ability is best left aside for now.

Once #1848 and #2008 are merged, I'll look at creating the ability to specify a security group by ID. It should be fairly simple: pull back all security groups, create a map of id => name and look for matching keys.

[mdb]

I'm observing the following behavior -- am I correct in thinking it's relevant to this issue? Apologies if I'm creating noise; just making sure this is accounted for. I'm also hoping my documentation helps others in assessing their own problems.

My issue...

Why are the names & IDs being scrambled when changing a resource?
Why are resources not edited in the .tf file allegedly being changed?

Steps to reproduce:

1. terraform apply yields the following:
   => some_sec_group; id 123
   => some_sec_group_2; id 456
2. edit .tf file:
   add some_sec_group_3 to .tf file
   add some_sec_group_3 to a resource, replacing an existing security group previously associated with the resource
3. terraform plan yields a change to resources un-edited in the .tf file & scrambles SG ids/names
   => some_sec_group; id 456 (scrambled; this was previously some_sec_group_2's id)
   => some_sec_group_2; id 123 (scrambled; this was previously some_sec_group's id)
   => some_sec_group_3; id 789

[jtopjian]

Regarding the ability to specify or refer to a security group by ID, I don't think this is possible. OpenStack Nova will always want the security group name and never the ID. Upon specifying an ID, you get the following error (as of Kilo):

{"badRequest": {"message": "Security group 3697 not found for project 7ab5f9f65b4b417d24d774a23fcdf45b.", "code": 400}}                                                         

I modified the compute resource to make it look up the name of the group when it comes across an string of all digits (assuming it's an ID). Even then, Nova will always report back the name, and Terraform will always want to change it back to the ID.

Given the add/remove order has been taken care of, was there anything else that needed to be noted with this issue? If not, I'll go ahead and close it.

[jtopjian]

I'm going to close this issue, but please re-open or open a new issue if there is still work to be done.

[dannytrigo]

As far as I'm aware - there is still a problem referencing security groups by ID instead of name, and names can conflict (Openstack allows multiple security groups with the same name). So I'm not sure why this issue was closed.

Using IDs, a plan afterwards shows they are being treated as names:

module.consul.openstack_compute_instance_v2.consul: Modifying... (ID: f5f36391-520a-4eb4-8517-acccd20157aa)
  security_groups.3594472879: "" => "e2d7bb7f-d50c-4e36-8fad-8effec52f762"
  security_groups.3820995059: "base-security-group" => ""
  security_groups.639953611:  "" => "d320c817-f834-4f29-887f-f875035568a2"
  security_groups.857928762:  "consul-security-group" => ""

[jtopjian]

@dannytrigo When using the compute API, you must specify the name of the security group, not the ID. When using the Networking API, you must reference the ID. It looks like you are doing the reverse in the above example you gave.

If you are still having problems, I recommend opening a new issue at https://github.com/terraform-providers/terraform-provider-openstack and we can discuss further :)

[dannytrigo]

Ok, thanks for the feedback - so its a peculiarity of the Openstack API :(

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