provider/openstack: updating security groups is broken

[Fodoj]

I found two issues:

1. Existing security group despite not being changed at all in template is marked as changed on every terraform apply
2. Because of it, every instance associated with this security group deletes the association and then readds it. I am convinced that is is absolutely not required to re-associate security group after rules have changed. It actually can lead to downtime of the instance because if gap when SG is not yet associated

[jtopjian]

Are you seeing this behavior with the patch from #3801 applied?

If you are, can you provide a sample Terraform configuration? I'm unable to reproduce the problem.

[Fodoj]

Yes, I have this patch in place. I will try to provide an example soon

[Fodoj]

@jtopjian this is enough:

resource "openstack_compute_secgroup_v2" "security_group_1" {
  name = "security_group_1" 
  description = "permissive security group"
  rule {
    from_port = 1
    to_port = 65535
    ip_protocol = "tcp"
    cidr = "0.0.0.0/0"
  }
  rule {
    from_port = 1
    to_port = 65535
    ip_protocol = "udp"
    cidr = "0.0.0.0/0"
  }
  rule {
    from_port = -1
    to_port = -1
    ip_protocol = "icmp"
    cidr = "0.0.0.0/0"
  }
}

If I run it twice then on the second (and all consuequent ones) run I get:

openstack_compute_secgroup_v2.security_group_1: Refreshing state... (ID: q5c89b10-4e5b-4164-94f1-f436cfb4c792)
openstack_compute_secgroup_v2.security_group_1: Modifying...
  rule.0.from_port:   "-1" => "1"
  rule.0.ip_protocol: "icmp" => "tcp"
  rule.0.to_port:     "-1" => "65535"
  rule.1.ip_protocol: "tcp" => "udp"
  rule.2.from_port:   "1" => "-1"
  rule.2.ip_protocol: "udp" => "icmp"
  rule.2.to_port:     "65535" => "-1"
openstack_compute_secgroup_v2.security_group_1: Modifications complete

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

[jtopjian]

Very strange! I was unable to reproduce the problem on any of my production environments. It wasn't until I modified the acceptance test and ran it against a devstack installation running Liberty that I'm able to reproduce it.

I'll look into this -- hopefully I'll figure out a fix very shortly.

[Fodoj]

@jtopjian I've played around with it a bit, trying to implement rules in similar way to aws SG implementation, but it didn't work from first attempt and I don't have time right now, because I am trying to fix other problem (will make a PR soon hopefully). Would be awesome to see this SG group issue fixed.

[jtopjian]

I have a good idea why this is happening, but I'm not sure of a clean fix. Instead of rushing, I'd rather revert the patch that caused this.

If you have a quick second, can you verify if #3824 causes the issue to go away? I'm pretty sure it will, but just want a second confirmation.

[jtopjian]

I'm confident enough that it resolves the problem that I've merged #3824. I'll work on getting both this and #3788 fixed as soon as I can.

[Fodoj]

Does that mean that master branch now doesn't update SGs all the time?

Best regards,
Kirill Shirinkin

On Mon, Nov 9, 2015 at 6:57 PM, Joe Topjian notifications@github.com
wrote:

I'm confident enough that it resolves the problem that I've merged #3824. I'll work on getting both this and #3788 fixed as soon as I can.

Reply to this email directly or view it on GitHub:
#3816 (comment)

[jtopjian]

The revert causes rules to not be computed, meaning the only security group rules that Terraform will know about are the rules that you explicitly set in your configuration. A side effect of this is seen in #3788.

It looks like the ordering issue (what you were seeing) was caused by fixing #3788. switching back and forth between the patch made the configuration you provided either pass or fail.

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