Improve wording in kubeadm upgrade plan #98728
Conversation
Originally raised as an issue with invalid versions to plan, but it has been determined with air gapped environments and development versions it is not possible to fully address that issue. But one thing that was identified was that we can do a better job in how we output the upgrade plan information. Kubeadm outputs the requested version as "Latest stable version", though that may not actually be the case. For this instance, we want to change this to "Target version" to be a little more accurate. Then in the component upgrade table that is emitted, the last column of AVAILABLE isn't quite right either. Also changing this to TARGET to reflect that this is the version we are targetting to upgrade to, regardless of its availability. There could be some improvements in checking available versions, particularly in air gapped environments, to make sure we actually have access to the requested version. But this at least clarifies some of the output a bit. Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
|
Hi @stmcginnis. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
|
thanks for the PR.
the release note seems fine, but please prefix it with as a side note we really give no guarantees when this output changes. /ok-to-test |
|
Thanks @neolit123, release note text updated. Guess I should have thought of that. "as a side note we really give no guarantees when this output changes." Yeah, that makes a lot of sense. Just thought it might be useful to point it out just in case it might help anyone. But I agree, parsing command line output should be avoided in most cases. ;) |
looks like a flake in another package. /retest |
|
Looks like it hit #98697 |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: neolit123, stmcginnis 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 |
|
@stmcginnis hello from 1.21 release notes team!
Can you clarify that this requires users / operators to take action / warrants a sport in "Urgent upgrade notes"? If so, please prepend the release note with Thank you! (CC: @wilsonehusin) |
|
hi @melodychn i'd say "action required" is not needed here. the sentence is for users that are doing this unsupported action. |
|
Exactly as @neolit123 says. No action required. It's really just an informational message in case anyone has been relying on something they shouldn't be. |
|
to upgrade to exact version try with providing version at end
|
Originally raised as an issue with invalid versions to plan, but it has
been determined with air gapped environments and development versions it
is not possible to fully address that issue.
But one thing that was identified was that we can do a better job in how
we output the upgrade plan information. Kubeadm outputs the requested
version as "Latest stable version", though that may not actually be the
case. For this instance, we want to change this to "Target version" to
be a little more accurate.
Then in the component upgrade table that is emitted, the last column of
AVAILABLE isn't quite right either. Also changing this to TARGET to
reflect that this is the version we are targeting to upgrade to,
regardless of its availability.
There could be some improvements in checking available versions,
particularly in air gapped environments, to make sure we actually have
access to the requested version. But this at least clarifies some of the
output a bit.
Fixes kubernetes/kubeadm#2311
/kind bug
/kind cleanup