ROX-18976: fix language around secured cluster and central version matching #63530
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@kcarmichael08: This pull request references ROX-18976 which is a valid jira issue. 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 kubernetes/test-infra repository. |
openshift-ci
bot
added
the
size/S
|
🤖 Updated build preview is available at: Build log: https://circleci.com/gh/ocpdocs-previewbot/openshift-docs/26134 |
kcarmichael08
changed the title
kcarmichael08
force-pushed
the
ROX-18976-cloud-service-versions
branch
from
0a4d118 to
a7aa5f4
Compare
openshift-ci
bot
added
size/M
kcarmichael08
force-pushed
the
ROX-18976-cloud-service-versions
branch
from
a7aa5f4 to
0888dc1
Compare
gaurav-nelson
added
RHACS
msugakov
left a comment
msugakov
left a comment
There was a problem hiding this comment.
Thanks, this definitely makes an improvement
| [IMPORTANT] | ||
| ==== | ||
| If you choose manual updates, you must update the {product-title-short} Operator in all secured clusters when you update the {product-title-short} Operator in the cluster where Central is installed. The secured clusters and the cluster where Central is installed must have the same version to ensure optimal functionality. | ||
| If you choose manual updates, you must update the {product-title-short} Operator in all secured clusters when you update the {product-title-short} Operator in the cluster where Central is installed. The secured clusters and the cluster where Central is installed must have the same version to ensure optimal functionality. For {product-title-managed-short}, use the latest version of the software that is available. (The software version for Central is automatically updated.) | ||
| ==== |
There was a problem hiding this comment.
This gets rendered on the page dedicated to the installation for self-managed. https://63530--docspreview.netlify.app/openshift-acs/latest/installing/installing_ocp/install-central-ocp#install-acs-operator_install-central-ocp
There's a page about Operator installation for Secured Cluster connected to ACS CS mentioning manual operator updates. https://63530--docspreview.netlify.app/openshift-acs/latest/cloud_service/installing_cloud_ocp/cloud-install-operator#install-acs-operator-cloud_cloud-install-operator
I think, we should add a note there saying that Red Hat recommends enabling automatic upgrades.
I suggest removing the new sentence from this page but adding one as [IMPORTANT] note to the CS page.
There was a problem hiding this comment.
This gets rendered on the page dedicated to the installation for self-managed. 63530--docspreview.netlify.app/openshift-acs/latest/installing/installing_ocp/install-central-ocp#install-acs-operator_install-central-ocp
(disregard previous message - have moved this note to the cloud services operator install module)
|
|
||
| The version of {product-title-managed-short} used on Secured Clusters must match the version of the Central instance of {product-title-managed-short} to ensure compatibility. | ||
| Customers are responsible for Secured Cluster services upgrades required to maintain this version compatibility. | ||
| To ensure optimal functionality and compatibility between Central and secured clusters, upgrade your secured clusters to the latest software version available. (The software version for Central is automatically updated.) |
There was a problem hiding this comment.
Optional suggestion:
| To ensure optimal functionality and compatibility between Central and secured clusters, upgrade your secured clusters to the latest software version available. (The software version for Central is automatically updated.) | |
| To ensure optimal functionality and compatibility between Central service and Secured Clusters, upgrade your secured clusters to the latest software version available. (The software version for Central is automatically updated.) |
There was a problem hiding this comment.
secured clusters are not capitalized in the docs.
|
|
||
| [role="_abstract"] | ||
| Upgrades through the {rh-rhacs-first} Operator are performed automatically or manually, depending on the *Update approval* option you chose at installation. | ||
| Upgrades through the {rh-rhacs-first} Operator are performed automatically or manually, depending on the *Update approval* option you chose at installation. Upgrading from version 3.74 to 4.x requires some additional steps that are described on this page. Upgrading within 4.y versions requires no additional steps. |
There was a problem hiding this comment.
I suggest stick to 4.x for consistency unless you meant to highlight the difference between 4.x and 4.y in this sentence.
| Upgrades through the {rh-rhacs-first} Operator are performed automatically or manually, depending on the *Update approval* option you chose at installation. Upgrading from version 3.74 to 4.x requires some additional steps that are described on this page. Upgrading within 4.y versions requires no additional steps. | |
| Upgrades through the {rh-rhacs-first} Operator are performed automatically or manually, depending on the *Update approval* option you chose at installation. Upgrading from version 3.74 to 4.x requires some additional steps that are described on this page. Upgrading within 4.x versions requires no additional steps. |
upgrading/upgrade-operator.adoc
Outdated
| include::modules/operator-upgrade-change-subscription-channel.adoc[leveloffset=+3] | ||
|
|
||
| include::modules/remove-central-attached-pv-overview.adoc[leveloffset=+1] | ||
| include::modules/remove-central-attached-pv-overview.adoc[leveloffset=+3] | ||
|
|
||
| include::modules/remove-central-attached-pv-operator.adoc[leveloffset=+2] | ||
| include::modules/remove-central-attached-pv-operator.adoc[leveloffset=+4] |
There was a problem hiding this comment.
Changing subscription channel is the upgrade itself, therefore it should go one level up to show up in ToC.
Removing central-attached PV is post-upgrade step and should also go one level up.
include::modules/operator-upgrade-change-subscription-channel.adoc[leveloffset=+2]
include::modules/remove-central-attached-pv-overview.adoc[leveloffset=+2]
include::modules/remove-central-attached-pv-operator.adoc[leveloffset=+3]
| include::modules/remove-central-attached-pv-overview.adoc[leveloffset=+3] | ||
|
|
||
| include::modules/remove-central-attached-pv-operator.adoc[leveloffset=+2] | ||
| include::modules/remove-central-attached-pv-operator.adoc[leveloffset=+4] |
There was a problem hiding this comment.
I noticed the PR description says
- cherry pick to
rhacs-docs-4.0
This will be wrong w.r.t. Remove Central-attached PV section because it only applies to 4.1+ releases.
Continuing our earlier conversation #63482 (comment) (and the one in JIRA), I suggest to structure this page in a following manner:
# Upgrading from 4.0
## Remove Central-attached PV
# Upgrading from 3.x
(notes about upgrading 3.x to 3.74, then from 3.74 to 4.0, then from 4.0 further)
## (upgrade steps)
### Preparing to upgrade
### Changing subscription channel
## Rolling back an Operator upgrade
## Troubleshooting Operator upgrade issuesI.e. group steps corresponding to the release from which the user will upgrade.
Also, optionally, make newer "from" releases go before older ones so that users who upgrade often don't need to scroll the page to check if there are any instructions that apply to their case.
I don't know if we can avoid maintaining separate versions of this page per releases. Cherry-picking shouldn't be used, but at least the new content will be additive.
There was a problem hiding this comment.
OK, based on this and looking into it more, I am going to need to make separate PRs for the branches. I'll be closing this one and opening new ones.
|
Replaced by #635388 |
5 participants
Version(s):
rhacs-docsrhacs-docs-4.2rhacs-docs-4.1rhacs-docs-4.0Issue
Link to docs preview:
QE review:
Additional information: