-
Notifications
You must be signed in to change notification settings - Fork 579
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: add EKS addon support #2202
✨ feat: add EKS addon support #2202
Conversation
/test ? |
@richardcase: The following commands are available to trigger jobs:
Use
In response to this:
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. |
/test pull-cluster-api-provider-aws-e2e-eks |
Would you want to control addons declaratively in the future? If so, might want to move the commands to underneath alpha if it's not going to be longterm. |
I think we'll want a utility for users to help them see what addons are available (and installed) for the longterm. This would be purely read and any operations have to be via the |
/test pull-cluster-api-provider-aws-e2e-eks |
Need #2216 to let the e2e-image build correctly |
for _, procedure := range procedures { | ||
s.scope.V(2).Info("Executing addon procedure", "name", procedure.Name()) | ||
if err := procedure.Do(ctx); err != nil { | ||
s.scope.Error(err, "failed executing addon procedure", "name", procedure.Name()) |
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.
could the addon status be set to failed in this case?
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've added the status to the state of the addon and this will be set via the state returned by the API. So I don't want to manually set a status.
In the scenario where there are multiple addons and one fails do you think we should carry on with the others or stop processing? At the moment we stop processing but I'm thinking we should continue on after reporting the error.
/test pull-cluster-api-provider-aws-e2e-eks |
2 similar comments
/test pull-cluster-api-provider-aws-e2e-eks |
/test pull-cluster-api-provider-aws-e2e-eks |
/test pull-cluster-api-provider-aws-e2e-eks |
3 similar comments
/test pull-cluster-api-provider-aws-e2e-eks |
/test pull-cluster-api-provider-aws-e2e-eks |
/test pull-cluster-api-provider-aws-e2e-eks |
/test pull-cluster-api-provider-aws-e2e-eks |
1 similar comment
/test pull-cluster-api-provider-aws-e2e-eks |
e2e test are passing. |
This change adds support for installing/managing EKS addons as part of the control plane reconciliation. It includes: * EKS Addon reconciliation * New clusterawsadm commands to list installed/available addons * Additional permissions to the controller policy * Webhook check to make sure we have a supported k8s version * Updated e2e tests * New cluster flavor using the VPC CNI addon
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: randomvariable 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 this PR does / why we need it:
This change adds support for installing/managing EKS addons as part of the control plane reconciliation.
It includes:
Additionally a number of minor bugs have been fixed with the e2e tests/
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #2139