You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should also be testing commits against the following use-cases:
replace-secgroup:
Stand up a cluster with an external nodeSecurityGroup secgroup to a new NodeGroup, on an update remove the external secgroup to fall back on the cluster's default nodeSecurityGroup, and verify if the patch works as expected with the cluster remaining in a running state.
Stand up a cluster, and then swap out its config (e.g. go from using 2 subnets -> 3 subnets), and issue another update to see if the patch works as expected with the cluster remaining in a running state.
Stand up a cluster using the latest, known release available. Then apply and test the patch on another update to the existing cluster to see if the patch works as expected with the cluster remaining in a running state.
Currently we have the following nodejs examples/tests:
We should also be testing commits against the following use-cases:
nodeSecurityGroup
secgroup to a newNodeGroup
, on an update remove the external secgroup to fall back on the cluster's defaultnodeSecurityGroup
, and verify if the patch works as expected with the cluster remaining in a running state.Note: To verify the k8s cluster "remains in a running state," a small scoped smoke-test testing the following would suffice:
aws-auth
k8s ConfigMap can be retrieved, is correct, and can be correctly used by Nodes to join the cluster with no interruptions.The text was updated successfully, but these errors were encountered: