[enterprise-4.8] Issue in file updating/preparing-eus-eus-upgrade.adoc

[flozanorht]

I asked on openshift-sme: when I perform the intermediate update of my control plane from 4.x (EUS) to the 4.x+1 (non-EUS), will the "oc adm upgrade --to-latest" ignore a "latest" 4.x+1.z release that has no upgrade path to 4.x+2 (next EUS)? Is the eus channel designed to ensure that?

The answer was that no one was sure and I got recommendations to specify a fixed 4.x+1.z (for example 4.9.) that has an update path to the next EUS instead of "latest". So the same recommendation should be in product docs, unless someone answers athoritativelly that the EUS channel will never offer an intermediate control plane non-EUS release that cannot move to the next EUS.

Which section(s) is the issue in?

"EUS-to-EUS update" > "Procedure"

What needs fixing?

Is step 5 "oc adm upgrade --to-latest" guaranteed to leave the control plane in a 4.9.z release with an update path to any 4.10.z? Isn't there any risk of ending up with a control plane that cannot be updated to the next EUS in step 8?

[flozanorht]

Scott Dodson answered in the thread "Minimum update path from 4.6 to 4.10" that it is guaranteed to work if you switch to an eus channel before trying any "oc adm upgrade". If a cluster was in a fast or stable channel, it might be in a release that offers no update path to the next EUS. I think this is important enought to be explicit in the docs. Currently it is implied

Scott also points out that, when performing multiple updates in sequence (as it was my question) it is not guaranteed that the latest release from the next EUS channel provides an update path to the following EUS. Though this is a scenario that brings in other risks and complications, I guess it is important to point out in docs those considerations instead of blindly showing a procedure that updates to latest.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[flozanorht]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[flozanorht]

/lifecycle frozen