Closed NikitaCloudRuntime closed 13 hours ago
@NikitaCloudRuntime can you add the following patch as well for NodeGroup ? so you will have EKS Version in Cluster and NodeGroup the same ? does this work for you ?
- fromFieldPath: spec.parameters.version
toFieldPath: spec.forProvider.version
yep, it works but shouldn't it be the default behaviour?
@haarchri it worked but now we face another issue - when we try to delete the EKS cluster we get the following error
Conditions:
Last Transition Time: 2023-10-10T05:40:27Z
Reason: ReconcileSuccess
Status: True
Type: Synced
Last Transition Time: 2023-10-17T06:25:26Z
Reason: Deleting
Status: False
Type: Ready
Last Transition Time: 2023-10-17T06:26:58Z
Message: destroy failed: deleting EKS Cluster (eks-test-hng4n): ResourceInUseException: Cluster has nodegroups attached
{
RespMetadata: {
StatusCode: 409,
RequestID: "7d30250f-2076-44cb-a486-dafc6deb17c5"
},
ClusterName: "eks-test-hng4n",
Message_: "Cluster has nodegroups attached",
NodegroupName: "eks-test-frpf2"
}:
Reason: DestroyFailure
Status: False
Type: LastAsyncOperation
Last Transition Time: 2023-10-10T05:48:58Z
Reason: Finished
Status: True
Type: AsyncOperation
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal DeletedExternalResource 19s (x4 over 112s) managed/eks.aws.upbound.io/v1beta1, kind=cluster Successfully requested deletion of external resource
I think this dependency must be somehow handled by the controller
when your nodegroup deletion is successfully done - the provider will start the removal process of cluster resource
This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale
. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh
will mark this issue as not stale.
This provider repo does not have enough maintainers to address every issue. Since there has been no activity in the last 90 days it is now marked as stale
. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh
will mark this issue as not stale.
This issue is being closed since there has been no activity for 14 days since marking it as stale
. If you still need help, feel free to comment or reopen the issue!
What happened?
NodeGroup AMI doesn't follow version of the EKS cluster
How can we reproduce it?
As part of our investigation of possibility to switch to Crossplane for infrastructure provisioning we detected that after update of the k8s version of EKS provisioned by Crossplane, AMI version of the particular NodeGroup doesn't not update
We have a long XRD so I'll put only relevant resources Cluster
NodeGroup
Initial version of the cluster was 1.25, but later we updated it to the next major release which was 1.26. We can see that the EKS cluster version has been updated, but the nodeGroup AMI is still on 1.25
According to the documentation, the version – Kubernetes version. Defaults to EKS Cluster Kubernetes version.
What environment did it happen in?