-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
feat: Create SG rule for each new cluster_endpoint_private_access_cidr block #1549
feat: Create SG rule for each new cluster_endpoint_private_access_cidr block #1549
Conversation
…cess_cidr block In order to fix A duplicate Security Group rule error
I have tested this PR for described scenarios (before change and then repeated on new code) and everything works as described. Migration to new module version after those changes also happening without issue and without impacting current EKS workload. Good work @lisfo4ka 👍 @antonbabenko it can be merged |
If this would be a small module with a couple of users I would merge this right away and explain how to run I propose that we group this one together with other breaking changes and bump a new major release with the described upgrade path. Here is one of the latest examples of a good upgrade doc created by @bryantbiggs in another module - https://github.com/terraform-aws-modules/terraform-aws-ec2-instance/blob/master/UPGRADE-3.0.md @lisfo4ka Could you please make a draft for the upgrade guide and link it to this one? @daroga0002 Are there any other PRs with the breaking changes? |
this is not a breaking change, this migration doesnt require any Technically it is:
Security group is exactly same, Kubernetes cluster is not impacted as nodes are communicating thru this security group rule. Main purpose of |
adding plan and execution:
|
I see! You are right, this is not as bad as renaming the whole security group. We don't need to make an upgrade path for this then. I will merge it now. |
@daroga0002 @antonbabenko thanks a lot for your active involvement) |
@lisfo4ka Not sure why but I think this is causing complete outage in my test clusters. I will come back with further information. I upgraded from v17.1.0 to v17.18.0 and terraform showed me a SG duplicate error (I don't have it right now, but will try to replicate it soon) and now I can't connect to the cluster (both kubectl and terraform timeout, meaning that this change made locked me out of the cluster with security groups) |
hmm, this change is just touching a security group rules, doesnt change anything with security groups. I tested this earlier and this was quite transparent move from v17.1 to this version. When you will get chance please post a error and plan from your execution maybe we will be able to help you. |
I fixed it with a targeted apply:
But, the thing is, that it failed on the first run, effectively leaving me with no security group at all.
I'll replicate it from zero whenever I can. Just wanted to put it here meanwhile. |
I can not replicate the issue right now... ! When I do a full upgrade from scratch I'll let you know if I see the issue again. Else, in case it happens randomly, the above targeted apply solution might help someone in the future. |
I tried a fresh upgrade again:
Result
And again, I could fix it with a targeted apply
|
I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Create separate sg rule for each new
cluster_endpoint_private_access_cidr
block in order to fix A duplicate Security Group rule error mentioned in #984PR o'clock
Description
At the moment, it isn't possible to update the
cluster_endpoint_private_access_cidrs
variable since terraform apply fails with the error described in the #984Initial settings:
Updated settings:
terraform plan:
terraform apply:
After proposed fix applied the separate SG rules will be created for each CIDR block in a list resolving the described issue:
Checklist