-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
workaround for terraform bug related to no_floating and extra_groups #10764
workaround for terraform bug related to no_floating and extra_groups #10764
Conversation
Hi @rptaylor. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Thanks @rptaylor |
/assign holmsten |
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.
@rptaylor lgtm, thank you 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, rptaylor The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Using
!
instead of== false
avoids the problem described in the linked issue and is probably better practice for boolean comparison anyway.Which issue(s) this PR fixes:
Fixes #10763
Special notes for your reviewer:
I tested if floating_ip is true, no_floating is removed:
and adding an extra group works:
Also if floating_ip is false, the no_floating group remains as expected, and if an extra group is added it fixes the bug:
So in all cases this has the expected result.
Does this PR introduce a user-facing change?: