kubeadm upgrade plan: print a component config state table #88124
Conversation
0068d9a to
604f0ee
Compare
|
@rosti can you please show example output? |
| @@ -75,7 +75,7 @@ func getK8sVersionFromUserInput(flags *applyPlanFlags, args []string, versionIsM | |||
| } | |||
|
|
|||
| // enforceRequirements verifies that it's okay to upgrade and then returns the variables needed for the rest of the procedure | |||
| func enforceRequirements(flags *applyPlanFlags, dryRun bool, newK8sVersion string) (clientset.Interface, upgrade.VersionGetter, *kubeadmapi.InitConfiguration, error) { | |||
| func enforceRequirements(plan bool, flags *applyPlanFlags, dryRun bool, newK8sVersion string) (clientset.Interface, upgrade.VersionGetter, *kubeadmapi.InitConfiguration, error) { | |||
|
Sample output: |
604f0ee to
523ad8f
Compare
523ad8f to
bb72eac
Compare
bc82e94 to
9bd4103
Compare
|
/milestone v1.19 |
9bd4103 to
73c6e28
Compare
|
[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 |
|
/retest |
`kubeadm upgrade plan` is using the external (currently `v1alpha1`) types of the kubeadm output API to collect upgrade plans. This is counter intuitive since code structure gets bound to the whatever version the output API is at. In addition to that, the versioned API is used only in the very last stages of a machine readable output (which is currently not implemented). Hence, to increase flexibility and keep up with the standard Kubernetes ecosystem practice, `kubeadm upgrade plan` is migrated to use the internal types of the output API. Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
This change enables kubeadm upgrade plan to print a state table with information regarding known component config API groups. Most importantly this information includes current and preferred version for each group and an indication if a manual user upgrade is required. Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
73c6e28 to
709e3c3
Compare
|
/lgtm |
|
/retest Review the full test history for this PR. Silence the bot with an |
5 similar comments
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
@rosti: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/retest Review the full test history for this PR. Silence the bot with an |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This change enables
kubeadm upgrade planto print a state table with information regarding known component config API groups. Most importantly this information includes current and preferred version for each group and an indication if a manual config upgrade is required.In addition to that, this PR also replaces most of the versioned use of the output API in
kubeadm upgrade planwith the internal types.Which issue(s) this PR fixes:
Refs:
Special notes for your reviewer:
This PR is part of the implementation of the new kubeadm component config management scheme KEP (see link below). It also depends on #91980 . Please, review the last 2 commits only!
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/priority important-longterm
/assign @fabriziopandini @neolit123 @ereslibre
/hold
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: