-
Bug
-
Resolution: Done
-
Normal
-
None
-
4.13, 4.12
-
Moderate
-
No
-
CFE Sprint 240, CFE Sprint 241
-
2
-
False
-
Description of problem:
In OCP 4.13, in cert-manager stable-v1 channel, there are three versions: v1.10.2, v1.11.1, v1.11.4. If a user has a cluster which used stable-v1 to install v1.10.2 and had upgraded to v1.11.1 when v1.11.1 was GA, now he/she will upgrade to v1.11.4.
A question comes: if the user has some cluster which installed v1.10.2 with Manual mode and (due to any reason [1]) has to follow again above path (which was valid) to upgrade to v1.11.1 first instead of v1.11.4, then seems no way.
[1] Possible reason may be similar to what OCPBUGS-6066 mentioned:
"customers who are using staging environments to test operator-based products before promoting a new version to production"
"sometimes the latest release is buggy or there are other reasons why a customer wants to install the older version" like v1.11.1.
Version-Release number of selected component (if applicable):
cert-manager v1.11.4
How reproducible:
Always
Steps to Reproduce:
1. Launch a 4.13 cluster. 2. Install cert-manager v1.10.2 using channel stable-v1: $ oc create ns cert-manager-operator $ oc create -f my-operatorgroup.yaml operatorgroup.operators.coreos.com/cert-manager-operator-og created $ oc create -f - << EOF apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-cert-manager-operator namespace: cert-manager-operator spec: channel: stable-v1 installPlanApproval: Manual name: openshift-cert-manager-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: cert-manager-operator.v1.10.2 EOF $ oc get ip -n cert-manager-operator NAME CSV APPROVAL APPROVED install-mcggp cert-manager-operator.v1.10.2 Manual false $ oc patch --type=merge ip install-mcggp -n cert-manager-operator -p " spec: approved: true" 3. Checking the result, v1.10.2 is installed, but v1.11.4 is resolved as next install plan, users seem to have no way to choose v1.11.1 to be next install plan: $ oc get ip -n cert-manager-operator NAME CSV APPROVAL APPROVED install-g9vs8 cert-manager-operator.v1.11.4 Manual false install-mcggp cert-manager-operator.v1.10.2 Manual true $ oc get csv -n cert-manager-operator NAME DISPLAY VERSION REPLACES PHASE cert-manager-operator.v1.10.2 cert-manager Operator for Red Hat OpenShift 1.10.2 Succeeded
Actual results:
Seems no way if users intentionally want to upgrade the v1.10.2 cert-manager version to v1.11.1 first (which was a valid upgrade path when v1.11.1 was GA at which time users may apply that upgrade path) instead of directly to v1.11.4.
Expected results:
If this is not a product bug, or if OCPBUGS-16784's upcoming solution happens to BTW fix this Jira's bug, then this Jira can be converted to a Documentation bug. It is worthy to has an upgrade section to clarify cert-manager upgrade policy or rationale for users, like: whether a user can choose an old version as target upgrade version, what upgrade paths are expected to happen, et al.
If this is a product bug and if OCPBUGS-16784's upcoming solution does not cover this Jira bug's fix, then fix it so that users could choose v1.11.1 as target upgrade version. A separate document bug can be created to clarify ** cert-manager upgrade for users.
Additional info:
- is documented by
-
-
- Closed
-
