-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat(cluster.tf): add support to set initial release channel version #1625
Conversation
…release channel This change adds support for specifying an initial version to use when a release channel is being used. The new logic sets the `min_master_version` variable to the value of the locally defined `master_version` when `release_channel` is `null` or `"UNSPECIFIED"`. When a release channel is specified, `min_master_version` is set to the value of `initial_version` if it is defined, and falls back to the value of `master_version` otherwise.
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
/gcbrun |
/gcbrun |
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.
Thanks for the contribution @slimatic!
If we don't have one already, please include one of the test fixtures setting kubernetes_version = "latest"
so this new functionally is covered by the Integration tests.
/gcbrun |
…ory and remove cluster_name_suffix variable
/gcbrun |
@apeabody fixed the tests and addressed the lint failures. |
/gcbrun |
…move kubernetes version from title
@apeabody applied |
/gcbrun |
/gcbrun |
/gcbrun |
@apeabody I noticed the cicd build is failing. Is my attention required on the failure? Please advise. |
/gcbrun |
@apeabody apologies, I accidentally closed the PR when I was commenting. |
/gcbrun |
@apeabody just triggered a new merge of the master branch. |
Thanks @slimatic, I'll re-run the CI. Per merge timeline, what are the potential impacts to existing clusters? Just need to determine if this is OK for immediate minor release now, or if it will need to be a major release with migration documentation. |
/gcbrun |
@apeabody Thanks for providing some insight on the merge timelines. |
@apeabody were the following questions were directed to me?
|
Hi @slimatic - Thanks, yes, do you have any insight on the potential impacts to existing clusters? |
/gcbrun |
Yes, based on my tests, making this change will have minimal impact on existing clusters. If the Kubernetes version is modified and applied to an existing cluster, Terraform will upgrade the cluster only if the specified version is greater than the current version. If the version is smaller than the existing version, the terraform apply command will complete successfully without upgrading the cluster 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.
Thanks @bharathkkb - That was above and beyond! |
/gcbrun |
Will merge once the CI is all green. |
…erraform-google-modules#1625) Co-authored-by: Andrew Peabody <[email protected]>
This change adds support for specifying an initial version to use when a release channel is being used. The new logic sets the
min_master_version
variable to the value of the locally definedmaster_version
whenrelease_channel
isnull
or"UNSPECIFIED"
. When a release channel is specified,min_master_version
is set to the value ofkubernetes_version
if it is defined, and falls back to the value ofmaster_version
otherwise.Fixes #1460