Edge case bug in update_security_group

[otm]

This is truly an edge case bug, if it can be called that, in the function update_security_group.

If there are are IpPermissions present in the security group the code will not update the rules if INGRESS_PORTS changes or someone has manually deleted all rules for one value in INGRESS_PORTS.

To reproduce:

1. Set INGRESS_PORTS = [ 80 ]
2. Run the code
3. Set INGRESS_PORTS = [ 80, 443 ]
4. Run the code

Expected behaviour:
IpPermissions has been updated to include port 80 and 443

Actual behaviour:
Only rules for port 80 are present

I recognize that this is an edge case, and that this might not be fixed. In that case this issue will just serve as documentation of this behaviour.

[rarylson]

Currently, there are only two possible values to INGRESS_PORTS: Http or Https, defined via tag Protocol. They are mutually exclusive.

This behavior changed on Dec 9, 2016, when I think the issue was solved.

But, I have some questions...

What would happen if we:

1. Set Protocol to Http
2. Run the code
3. Set Protocol to Https
4. Run the code

Is the code able to handle this? It is, revoking all the HTTP rules and adding new HTTPS ones?

And if we do this:

1. Set Name to cloudfront_g
2. Run the code
3. Set Name to cloudfront_r
4. Run the code

Is the code able to handle this? It is, revoking all the global rules and adding new regional ones?

I didn't test it. Anyway, I thing it's worth to document these questions here.

If the code can't handle this, maybe the proper workaround was just creating a new security group with the correct tags and migrate the applications to use it (if using in a live production environment), or just manually removing all the inbound rules before running the code again.