flozanorht
commented
2 years ago 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
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?