-
Notifications
You must be signed in to change notification settings - Fork 163
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
eks: cluster version update #3123
Conversation
e77691f
to
b4d7c70
Compare
a07c1dc
to
3fc6511
Compare
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.
There is only 1 required change among my comments, the cluster status error message handling, otherwise it looks generally good with a couple of questions/remarks from me to discuss.
internal/cluster/distribution/eks/eksprovider/workflow/update_eks_version_activity.go
Outdated
Show resolved
Hide resolved
internal/cluster/distribution/eks/eksprovider/workflow/wait_update_eks_version_activity.go
Outdated
Show resolved
Hide resolved
internal/cluster/distribution/eks/eksprovider/workflow/save_cluster_version_activity.go
Show resolved
Hide resolved
9ed819e
to
ee4b64b
Compare
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.
My requested changes were implemented.
The topic of the proper separation of the cluster version and node pool upgrade flows are still up for discussion, but even if we decide to change the location of separation/branching we can implement it in another PR if we wish.
(It can still be discussed and implemented here, I'm just not sure this PR is the right way to do it, maybe it calls for a separate discussion or an ADR proposal.)
bbfbfa8
to
e3423eb
Compare
6daa273
to
0f925a7
Compare
0f925a7
to
270b051
Compare
apis/pipeline/pipeline.yaml
Outdated
security: | ||
- bearerAuth: [] | ||
tags: | ||
- cluster-update |
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.
Can it be clusters instead?
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 guess it would collide with the existing cluster update operation, but I don't care about that much. We don't have a BC promise for the generated code.
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.
fixed, thanks.
apis/pipeline/pipeline.yaml
Outdated
@@ -7503,6 +7527,13 @@ components: | |||
type: string | |||
example: 10.20.30.40 | |||
|
|||
ClusterUpdateRequest: |
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.
Can we make it look like the node pool upgrade request?
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.
The nodepool update request looks a bit bad to me, it has cloud or distribution for example. Or do you mean the EKS part?
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 mean this:
UpdateNodePoolRequest:
oneOf:
- $ref: '#/components/schemas/EksUpdateNodePoolRequest'
We should have a similar structure for clusters IMHO.
202: | ||
description: Accepted | ||
default: | ||
$ref: '#/components/responses/Error' |
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.
Note: this is out of scope for this PR, but we should update the the 409 Conflict
error
and message
here, because it refers to the secret by default.
https://github.com/banzaicloud/pipeline/pull/3123/files#diff-2b6bfc5b5d040867ca5e5f7b1df191f1R11868-R11869
Also we should update the 403 Access Denied
message
at the default values, because it seems to be misphrased You are unauthorized to perform this action access resource.
.
https://github.com/banzaicloud/pipeline/pull/3123/files#diff-2b6bfc5b5d040867ca5e5f7b1df191f1R11908-R11909
apis/pipeline/pipeline.yaml
Outdated
security: | ||
- bearerAuth: [] | ||
tags: | ||
- cluster-update |
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 guess it would collide with the existing cluster update operation, but I don't care about that much. We don't have a BC promise for the generated code.
|
||
// EKSAPIFactory provides an interface for instantiating AWS | ||
// EKS API objects. | ||
type EKSAPIFactory interface { |
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.
Is this a cadence library thing? We should keep in mind that we want to generate these, so we should follow the patterns that we set out in the closed repo.
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.
This is just a wrapper to not to rely directly on the AWS lib, for mocking. @pregnor am I right?
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.
That's correct, we use it for test mocking purposes to be able to provide a mocked API in place of an eksiface.EKSAPI
, we did it similarly with the CloudFormation
factories and client/service interfaces.
Context for people out of loop: It helps the Cadence activities to have a constructor argument/field for factories returning client/service interfaces to the corresponding AWS APIs so we don't use eks.New(awsSession)
because it makes test mocking much more difficult as it creates a real API object, this way we can use a EKSFactoryMock{}
object in place of the real factory wrapping the New()
call which allows us to write extensive mock tests as we can control the returned API mock object and thus intercept/mock all API calls.
"github.com/banzaicloud/pipeline/internal/cluster/distribution/eks/eksprovider/workflow" | ||
) | ||
|
||
const UpdateClusterVersionActivityName = "eks-update-version" |
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 guess this is fine for now, but I'd much rather use the proxy pattern we used for other AWS API calls.
88fcd76
to
ec16b63
Compare
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
ec16b63
to
16fc98a
Compare
Signed-off-by: Nandor Kracser <[email protected]>
Co-authored-by: Márk Sági-Kazár <[email protected]>
16fc98a
to
3d1b72b
Compare
What's in this PR?
Basic implementation of EKS cluster version update.
Why?
Additional context
Testable until the CLI implementation becomes available with:
Checklist