pkg/cli/admin/update: Add tech-preview 'oc adm upgrade status' - #1554
Conversation
|
/cc |
|
/hold till I am done with https://issues.redhat.com/browse/OTA-1025 |
Avoid confusion like we had with 'oc adm upgrade channel', where folks running older oc (where 'channel' didn't exist) had the command no-op and exit 0. With this change, that sort of thing will give: $ oc adm upgrade does-not-exist error: unknown command "does-not-exist" See 'oc adm upgrade -h' for help and examples
Initial scaffolding, based on the existing code for status rendering
for 'oc adm upgrade', but factored out into a new package to more
easily distinguish between read-only status-rendering and commands
that are intended to change state (like initiating updates). I'm
gating the new subcommand behind an OC_ENABLE_CMD_UPGRADE_STATUS
feature gate to avoid surprising users with a volatile command while
the implementation settles down.
$ ./oc adm upgrade status
error: unknown command "status"
See 'oc adm upgrade -h' for help and examples
$ OC_ENABLE_CMD_UPGRADE_STATUS=true ./oc adm upgrade --help
...
Available Commands:
channel Set or clear the update channel
status Display the status of current cluster version updates.
...
$ OC_ENABLE_CMD_UPGRADE_STATUS=true ./oc adm upgrade status
The cluster version is not updating (Progressing=False).
Reason:
Message: Cluster version is 4.13.10
90a8eab to
701c2ee
Compare
|
@wking: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
|
/hold cancel |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
In case the hidden-ness from 73074c3 (pkg/cli/admin/upgrade/rollback: New rollback command, 2023-12-19, openshift#1642) is not sufficient to scare users away, add a gating environment variable. We also use a gating env. var. for status (701c2ee, pkg/cli/admin/upgrade/status: Add tech-preview 'oc adm upgrade status', 2023-10-03, openshift#1554) and inspect-alerts (229c2a8, pkg/cli/admin/inspectalerts: New tech-preview inspect-alerts subcommand, 2024-01-30, openshift#1674). Also reword the LongDesc to avoid saying "supported" (which readers might misconstrue as "what Red Hat support will do if we open a case"). I'm just trying to talk about "what the cluster-version operator will do if you request a rollback", and hopefully the new wording makes this more clear.
In case the hidden-ness from 73074c3 (pkg/cli/admin/upgrade/rollback: New rollback command, 2023-12-19, openshift#1642) is not sufficient to scare users away, add a gating environment variable. We also use a gating env. var. for status (701c2ee, pkg/cli/admin/upgrade/status: Add tech-preview 'oc adm upgrade status', 2023-10-03, openshift#1554) and inspect-alerts (229c2a8, pkg/cli/admin/inspectalerts: New tech-preview inspect-alerts subcommand, 2024-01-30, openshift#1674). Also reword the LongDesc to avoid saying "supported" (which readers might misconstrue as "what Red Hat support will do if we open a case"). I'm just trying to talk about "what the cluster-version operator will do if you request a rollback", and hopefully the new wording makes this more clear.
Initial scaffolding, based on the existing code for status rendering in
oc adm upgrade. I'm gating the new subcommand behind anOC_ENABLE_CMD_UPGRADE_STATUSfeature gate to avoid surprising users with a volatile command while the implementation settles down.