Fix GKE default version and tweak node pool upgrade versioning logic #5151
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.
rancher/dashboard#11357
There are two semi-related issues in 11357
Fix for problem 1 was fairly straightforward: instead of using the defaultClusterVersion from the GCP API call we set the cluster version to the latest version shown in the version dropdown. In addition to respecting Rancher-specific versioning limitations this has the added bonus of ensuring that the cluster version is never automatically set to something not shown in the UI.
The fix for problem 1 resulted in a few errors in the node pool component because the cluster version was no longer set before the rest of the page (including np components) rendered. Between that and needing to tweak the node pool version selection logic I ended up rewriting a bunch of observers/computed props around the node pool versioning
Expected node pool version behavior:
Note about node pool versions:
Technically the gcp api provides a list of node versions and a list of control plane versions. In my own testing I did not find an example of a version present in the control plane list and not the node pool list. Nevertheless, the version offered in the node pool upgrade input is from the node pool list: we're using the highest node pool version that is <= the current cluster (control plane) version. It just happens that this is always equal to the control plane version.