e2e test should take GKE node version as an input #603
Conversation
k8s-ci-robot
added
release-note
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: saikat-royc 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 |
k8s-ci-robot
added
approved
saikat-royc
force-pushed
the
node-version-skew
branch
from
8f21166 to
1ccf3cd
Compare
k8s-ci-robot
added
size/S
|
/retest |
| @@ -167,6 +167,10 @@ func clusterUpGKE(gceZone, gceRegion string, numNodes int, imageType string, use | |||
| cmdParams = append(cmdParams, "--enable-autorepair") | |||
| } | |||
|
|
|||
| if isVariableSet(gkeNodeVersion) { | |||
There was a problem hiding this comment.
nit: should there be validation against specifying both release channel and node version?
There was a problem hiding this comment.
I don't think that's an error. I just ran
gcloud beta container clusters create --release-channel rapid --node-version 1.16.8-gke.15 skewed
and it succeeded. It might be useful to test such skewed deployments (although it looks like one might need to be careful about auto-upgrade---maybe that should be automatically disabled whenever both release channel and node version are specified? Or maybe we should just disable auto-upgrade all the time anyway as we probably never want that to happen during a test?)
There was a problem hiding this comment.
It works if we specify release channel and node version. Master version picks the release version, while nodes pickup the node version.
There was a problem hiding this comment.
ah ok thanks for checking. Yeah in hindsight if this were not the case, the skew tests we have planned with node version = master version - 2 would be tough.
Disabling auto-upgrade all the time makes sense to me. Removes the possible confusion during the rare occasion when a short-lived test cluster is running while an auto-upgrade is being pushed out.
There was a problem hiding this comment.
I see error when using release channels, and --no-enable-autoupgrade option.
e.g.
gcloud beta container clusters create gcp-pd-csi-driver-test-cluster --zone us-central1-c --num-nodes 3 --quiet --machine-type n1-standard-2 --release-channel rapid --enable-autorepair --no-enable-autoupgrade --node-version 1.16 --addons GcePersistentDiskCsiDriver
...
Auto_upgrade cannot be false when release_channel RAPID is set
however --no-enable-autoupgrade works with cluster-version and node-version option
gcloud beta container clusters create gcp-pd-csi-driver-test-cluster --zone us-central1-c --num-nodes 3 --quiet --machine-type n1-standard-2 --image-type cos --cluster-version latest --no-enable-autoupgrade --node-version 1.16 --addons GcePersistentDiskCsiDriver
There was a problem hiding this comment.
Ok, let's defer the autoupgrade fiddling until we understand the use cases a bit better. It may be that it's not a problem for tests, we'd have to dig into the details more.
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/hold Saikat do you think we should always disable auto upgrade? If so does it make sense to add it in this PR? |
k8s-ci-robot
added
the
do-not-merge/hold
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/retest |
For GKE clusters, node-version flag can be provided during cluster creation to specify worker node k8s version. This change is needed to test node and master version skew combinations.
saikat-royc
force-pushed
the
node-version-skew
branch
from
1ccf3cd to
b45161e
Compare
k8s-ci-robot
removed
the
lgtm
|
/lgtm |
k8s-ci-robot
added
the
lgtm
For GKE clusters, node-version flag can be provided during cluster
creation to specify worker node k8s version. This change is needed
to test node and master version skew combinations.
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: