-
Notifications
You must be signed in to change notification settings - Fork 318
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
Restrict subnets only to subnets from regular availability zones in ELB auto-discovery procedure #499
Conversation
@lobziik: This issue is currently awaiting triage. If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the The 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. |
Welcome @lobziik! |
Hi @lobziik. Thanks for your PR. I'm waiting for a kubernetes 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. |
/ok-to-test |
/lgtm Will need an AWS approver to review as well, but the code looks clean and makes sense to me |
e2e is failing, i need some time to reproduce and investigate it. |
Apparently this requires additional iam permissions for describing availability zones. I need to figure out where it does set within this e2es and give an another thought about this api call error handling. Will appreciate some advices here, for now i'm not entirely sure how to proceed. |
Updated PR, added a check for the response type. Insufficient permissions does not threat as an error anymore, warning will be raised instead: https://github.com/kubernetes/cloud-provider-aws/pull/499/files#diff-97a31d0f193ea0b4e2c538595daf93405351054377458053a5010f6fdb97f4dcR3539 for provide backward compatability and do not break existing clusters after ccm upgrade. Added missed permission into documentation also. |
/hold cancel |
/cc @kishorj @JoelSpeed Sry, I misclicked and break review requests. |
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.
Changes look ok, couple of nits about errors but otherwise LGTM, lmk what you think about using the error wrapping, this file already imports the standard library errors package so there's no new dependency on this
/lgtm |
/lgtm |
/pull-kops-e2e-cni-amazonvpc |
pkg/providers/v1/aws.go
Outdated
|
||
azs, err := c.ec2.DescribeAvailabilityZones(azRequest) | ||
if err != nil { | ||
if awsErr, ok := err.(awserr.RequestFailure); ok && awsErr.Code() == "UnauthorizedOperation" { |
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.
Tbh, if we ignore the error we will keep the existing behavior unless the IAM permissions get updated. I favor throwing the error here instead.
We will have to update the IAM permissions. As for EKS, we can start process to update the managed policies. For kops, we can request the permission to be included.
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.
Once the policies get updated, we can backport the changes to older releases as well.
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.
I updated pr, now permissions error will be propagated back.
IAM permissions in kops were extended in kubernetes/kops#14650.
@kishorj can you please take a look? :)
I attempted to update permission list for kops. @olemarkus can you please help with that, when you will have time? :) kubernetes/kops#14650 - think it will be a prerequisite for having |
To workaround the issue with subnets auto-discovery [1] AWS ccm needs to have permission to retrieve information about availability zones (specifically to detect outpost, wavelength, and local zones [2]). [1] kubernetes/cloud-provider-aws#442 [2] kubernetes/cloud-provider-aws#499
To workaround the issue with subnets auto-discovery [1] AWS ccm needs to have permission to retrieve information about availability zones (specifically to detect outpost, wavelength, and local zones [2]). [1] kubernetes/cloud-provider-aws#442 [2] kubernetes/cloud-provider-aws#499
Outpost, wavelength, and local zone don't support NLB or CLB for the moment. This commit adds check for availability zone type and includes only subnets from `availability-zone` typed zones for the auto-discovery.
/retest |
Thanks for the fixups @lobziik /lgtm |
Thanks Need updates to the AmazonEKSClusterPolicy for EKS clusters. Hold merge until we initiate the process to update the managed policy. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: olemarkus 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 feature
What this PR does / why we need it:
Outpost, wavelength, and local zone don't support NLB or CLB at the moment.
This pr adds check for availability zone type and includes only subnets from
availability-zone
typed zones for the auto-discovery.Which issue(s) this PR fixes:
Fixes #442
Special notes for your reviewer:
I'm not sure about PR type, guess that
feature
is the most suitable one.Does this PR introduce a user-facing change?: