-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(secgroups): use standalone secgroup rules instead of in-line rules #109
Conversation
Note: this PR currently sets the ingress and egress prop of both secgroups to an empty array I'll be opening a separate issue to track this props removal bug in pulumi/pulumi.
|
6b1904a
to
9f2b250
Compare
- null out the secgroup ingress & egress to revoke any existing rules - create new standalone secgroup rules
9f2b250
to
a2ca991
Compare
@lukehoban PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This does make me really want some tests to ensure that this update can safely be performed from a stack deployed using previous versions of the library. Do you know exactly what happens during the update? Is there a very brief period of outage where the security groups are removed before they get added? If so, may want to add a note about the upgrade to the CHANGELOG?
@lukehoban agree on the fact that we should enable testing prev versions against the new commits.
I'd imagine that there can be a brief period of unavailability given that the secgroup rules are against the worker instances themselves. That said, this patch update does happen in a matter of seconds (< 10 sec and closer to 5sec) so it isn't a prolonged period. I'll make sure to mention this ^ as a part of the changelog. For the sake of more data on this change:
|
fixes: #106
rel: #69