kubeadm: Fix upgrade plan for air-gapped setups
#94421
Conversation
A bug was discovered in the `enforceRequirements` func for `upgrade plan`. If a command line argument that specifies the target Kubernetes version is supplied, the returned `ClusterConfiguration` by `enforceRequirements` will have its `KubernetesVersion` field set to the new version. If no version was specified, the returned `KubernetesVersion` points to the currently installed one. This remained undetected for a couple of reasons - It's only `upgrade plan` that allows for the version command line argument to be optional (in `upgrade plan` it's mandatory) - Prior to 1.19, the implementation of `upgrade plan` did not make use of the `KubernetesVersion` returned by `enforceRequirements`. `upgrade plan` supports this optional command line argument to enable air-gapped setups (as not specifying a version on the command line will end up looking for the latest version over the Interned). Hence, the only option is to make `enforceRequirements` consistent in the `upgrade plan` case and always return the currently installed version in the `KubernetesVersion` field. Signed-off-by: Rostislav M. Georgiev <[email protected]>
k8s-ci-robot
added
the
release-note
k8s-ci-robot
added
kind/bug
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rosti 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
the
approved
| // This also makes the KubernetesVersion value returned for `upgrade plan` consistent as that command | ||
| // allows to not specify a target version in which case KubernetesVersion will always hold the currently | ||
| // installed one. | ||
| cfg.KubernetesVersion = newK8sVersion |
There was a problem hiding this comment.
Just to double check. After this change, if the user passes to plan 1.19.2, while the cluster version is at 1.19.1, would the table for control plane component upgrade still print .2 as the planned upgrade target in a case where the latest stable is not 1.19.2 (eg newer than that)?
There was a problem hiding this comment.
Yes. The tables are generated using the version getter (initialized at the return of this func with the value of newK8sVersion).
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/milestone v1.20 |
…upstream-release-1.19 Automated cherry pick of #94421: kubeadm: Fix `upgrade plan` for air-gapped setups
What type of PR is this?
/kind bug
/kind regression
What this PR does / why we need it:
A bug was discovered in the
enforceRequirementsfunc forupgrade plan.If a command line argument that specifies the target Kubernetes version is
supplied, the returned
ClusterConfigurationbyenforceRequirementswillhave its
KubernetesVersionfield set to the new version.If no version was specified, the returned
KubernetesVersionpoints to thecurrently installed one.
This remained undetected for a couple of reasons
upgrade planthat allows for the version command line argument tobe optional (in
upgrade planit's mandatory)upgrade plandid not make use of theKubernetesVersionreturned byenforceRequirements.upgrade plansupports this optional command line argument to enableair-gapped setups (as not specifying a version on the command line will end up
looking for the latest version over the Interned).
Hence, the only option is to make
enforceRequirementsconsistent in theupgrade plancase and always return the currently installed version in theKubernetesVersionfield.Which issue(s) this PR fixes:
Fixes kubernetes/kubeadm#2274
Special notes for your reviewer:
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/priority important-soon
/assign @fabriziopandini @neolit123
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: