Repository navigation
setup-gcp: let callers choose the cluster's release channel - #1797
Closed
Gari Singh (mastersingh24) wants to merge 1 commit into
Closed
Gari Singh (mastersingh24) wants to merge 1 commit into
Gari Singh (mastersingh24) wants to merge 1 commit into
Conversation
`create cluster` has always let you pin a Kubernetes version with
`--cluster-version`, but never a release channel, so every new cluster
lands on whatever channel GKE defaults to. That is fine until the version
you want is not in that channel: a channel only serves the versions it
carries, and today 1.37 — where the PodCertificate APIs are GA — is in
Rapid alone. `CLUSTER_VERSION=1.37` is simply rejected.
Add `--release-channel` / `RELEASE_CHANNEL` next to the existing version
flag, on both `bootstrap` and `create cluster`.
Two details worth knowing:
- Empty and "none" are deliberately different. An unset ReleaseChannel
in the create request means "GKE decides", which is what every caller
gets today; an explicit UNSPECIFIED unenrolls the cluster from release
channels altogether. Conflating them would change behavior for callers
who pass nothing, so only a caller who says "none" gets UNSPECIFIED.
- "extended" is rejected before the create call. This tool asks for the
beta PodCertificate APIs on every cluster it creates and the extended
channel does not allow beta APIs, so the create can only fail with
"enabling Beta APIs is not supported in the extended release channel".
Better to say that up front than to spend a create on it.
Stable is left alone. It carries no release new enough for Substrate right
now, but that is a Substrate policy question and this is a general-purpose
tool, so it is not enforced here.
Gari Singh (mastersingh24)
added a commit
to mastersingh24/substrate
that referenced
this pull request
Sep 24, 2026
…ization test Moved from the end of cluster_test.go, where agent-substrate#1797 also adds its tests, so the two PRs merge in either order without a conflict.
Bowei Du (bowei)
added
area/dev-infra
kind/feature
Gari Singh (mastersingh24)
added a commit
to mastersingh24/substrate
that referenced
this pull request
Oct 2, 2026
…ization test Moved from the end of cluster_test.go, where agent-substrate#1797 also adds its tests, so the two PRs merge in either order without a conflict.
Gari Singh (mastersingh24)
added a commit
to mastersingh24/substrate-gke
that referenced
this pull request
Oct 18, 2026
setup-gcp could pin a cluster version but not a channel, so new clusters always landed on Regular, and Regular doesn't carry 1.37. This adds --release-channel / RELEASE_CHANNEL to bootstrap and create cluster. Empty leaves the channel unset like before; "none" is an explicit unenroll. "extended" is rejected up front since it won't allow the beta APIs we turn on. Same change as agent-substrate/substrate#1797, now that setup-gcp lives here.
Contributor
Author
|
Closing this since setup-gcp moved to ai-on-gke/substrate-gke (#2304). The same change is in ai-on-gke/substrate-gke#56 there. |
Gari Singh (mastersingh24)
added a commit
to mastersingh24/substrate-gke
that referenced
this pull request
Oct 21, 2026
setup-gcp could pin a cluster version but not a channel, so new clusters always landed on Regular, and Regular doesn't carry 1.37. This adds --release-channel / RELEASE_CHANNEL to bootstrap and create cluster. Empty leaves the channel unset like before; "none" is an explicit unenroll. "extended" is rejected up front since it won't allow the beta APIs we turn on. Same change as agent-substrate/substrate#1797, now that setup-gcp lives here.
Aditya Shantanu (aditya-shantanu)
pushed a commit
to ai-on-gke/substrate-gke
that referenced
this pull request
Oct 21, 2026
* setup-gcp: add --release-channel setup-gcp could pin a cluster version but not a channel, so new clusters always landed on Regular, and Regular doesn't carry 1.37. This adds --release-channel / RELEASE_CHANNEL to bootstrap and create cluster. Empty leaves the channel unset like before; "none" is an explicit unenroll. "extended" is rejected up front since it won't allow the beta APIs we turn on. Same change as agent-substrate/substrate#1797, now that setup-gcp lives here. * Create new clusters at 1.37 on the Rapid channel 1.37 serves the PodCertificate APIs as v1, which Substrate uses from v0.4.0, so a new cluster at 1.37 needs no beta APIs and never needs its node pools replaced. Rapid is the only channel with 1.37 right now. The advanced track gets a release channel field next to the version. We ask GKE (get-server-config) whether the channel offers the version and warn if it doesn't; submitting again goes on, since it only matters if you create a cluster. The check runs under the submit deadline, skips blocked projects, and any edit re-arms it. Extended is refused outright. * Say when the channel lookup times out If get-server-config was the check that ran out the submit deadline, the error was swallowed and the submit went on after 30s with no word. Now it says "timed out" like the other checks, and submitting again goes on. The channel test also drives the project screen directly instead of walking the wizard to it (38s down to 2s), which keeps the ui package under go test's 10 minute default.
2 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1796
create clusterhas always let you pin a Kubernetes version with--cluster-version, but never a release channel, so every new cluster lands on whatever channel GKE defaults to. That is fine until the version you want is not in that channel: a channel only serves the versions it carries, and today 1.37 — where the PodCertificate APIs are GA — is in Rapid alone, soCLUSTER_VERSION=1.37is simply rejected.This adds
--release-channel/RELEASE_CHANNELnext to the existing version flag, on bothbootstrapandcreate cluster.Two details worth a look in review:
noneare deliberately different. An unsetReleaseChannelin the create request means "GKE decides", which is what every caller gets today; an explicitUNSPECIFIEDunenrolls the cluster from release channels altogether. Conflating them would change behavior for callers who pass nothing, so only a caller who saysnonegetsUNSPECIFIED. There is a test pinning both halves of that.extendedis rejected before the create call. setup-gcp asks for the beta PodCertificate APIs on every cluster it creates and the extended channel does not allow beta APIs, so the create can only fail with "enabling Beta APIs is not supported in the extended release channel". Better to say so up front than to spend a create on it.stableis left alone. It carries no release new enough for Substrate right now, but that is a Substrate policy question and this is a general-purpose tool, so it is not enforced here — happy to change that if you would rather it were.go test ./tools/setup-gcp/...)tools/setup-gcp/README.mdflag tables and a note on how channels gate versions;hack/ate-dev-env.sh.example)