-
Notifications
You must be signed in to change notification settings - Fork 1.8k
OCPBUGS-49888: Adding update service connection prerequisite to TP st… #90640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@obrown1205: This pull request references Jira Issue OCPBUGS-49888, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
🤖 Wed Mar 26 16:26:19 - Prow CI generated the docs preview: |
@@ -18,6 +18,10 @@ include::snippets/technology-preview.adoc[] | |||
Your cluster does not need to be a Technology Preview-enabled cluster in order for you to use the `oc adm upgrade recommend` command. | |||
==== | |||
|
|||
.Prerequisites | |||
|
|||
* Your cluster is connected to an update service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could go either way on this. On the one hand, I think the OpenShift Update Service (whether it's the Red-Hat-hosted https://api.openshift.com/api/upgrades_info/graph or a customer-run OSUS) is a fantastic value-add, and think we should recommend it more strongly than we currently do. On the other hand, the recommend
subcommand will not crash if there is no connected update service, it will just print a warning. So while it's not wrong that you'll want an Update Service to get much useful out of recommend
, it shouldn't be terrible to skip that warning in the docs and expect customers who have intentionally-disabled or accidentally-broken Update Service access to figure out this relationship when they run the command. And I'd also be really excited if instead of pitching this as a prereq for this one command, we really pushed all customers towards having an Update Service feeding their cluster for all update-related commands, and explained to disconnected/restricted-network folks why we felt it was worth the trouble to run their own OSUS, to try and bring folks on board and emphasize what a value-add it is, instead of just having a low-context requirement they might feel grumbly about.
@obrown1205 it seems the 1st part |
/cc |
886761c
to
ae20cc8
Compare
@obrown1205: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
What do we think about https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/performing-a-cluster-update#update-service-overview_updating-restricted-network-cluster-osus? Do we want to add more to the section? @jiajliu |
The bug's description is a bit misleading. I thought you planned to improve it in this pr, so my original question was to confirm if this pr would include the issue mentioned in the bug. If it's not in the scope now, |
Version(s):
4.17+
Issue:
OCPBUGS-49888
Link to docs preview:
https://90640--ocpdocs-pr.netlify.app/openshift-enterprise/latest/updating/troubleshooting_updates/gathering-data-cluster-update.html
https://90640--ocpdocs-pr.netlify.app/openshift-enterprise/latest/updating/updating_a_cluster/updating-cluster-cli.html
QE review:
Additional information: