Major Description of problem:
when we set operator approval plan as manual, after we upgrade cluster from 4.14 to 4.15, the operator fails at operator installing (upgrading) if we want to install new version bundle.
Version-Release number of selected component (if applicable):
4.15.x
How reproducible:
always
Steps to Reproduce:
1.install cluster with 4.14
2.install one operator (like gitops, any operator with rbac is ok) with manual approval. make it not latest version of channel
3. upgrade cluster to 4.15
4, approve insallplan to install new version bundle.
and it fails
--
- lastTransitionTime: "2024-04-01T06:29:44Z"
lastUpdateTime: "2024-04-01T06:29:44Z"
message: 'couldn''t find unpacked step for service-binding-operator.v1.3.3: service-binding-operator.v1.3.3-service-binding-opera-746d6f6d8[rbac.authorization.k8s.io/v1/Role
(redhat-operators/openshift-marketplace)] (Unknown)'
reason: InstallComponentFailed
status: "False"
type: Installed
--
note: it only happen from 4.14 to 4.15.
Actual results:
the operator can not upgraded or installed.
Expected results:
can upgraded or installed.
Additional info:
it is caused by different name rule of role between 4.14 and 4.15.
the role name from installplan (step.Resource.Name) is openshift-gitops-operator.v1.11.2-openshift-gitops-ope-9c5f7454, but the role name from bundle (u.Name) is openshift-gitops-operator-OtgPysvuH5syQKNemSykUqg9Qm4fK5O6HEKP1.
for this upgrade scenario, the step.Resource.Name from installplan is generated in 4.14, and the u.Name is generated per bundle cm in openshift-marketplace in 4.15.
the name rule is changed.and then I checked the code between 4.14 and 4.15. the name generated code is in staging/operator-lifecycle-manager/pkg/controller/registry/resolver/rbac.go and it is different between 4.14 and 4.15.
it is changed by
https://github.com/openshift/operator-framework-olm/commit/e248469f170ddb8ccf03fa714924e75efb9de946#diff-885d1e95e50eb8ece2643ba380c0449ab1adaeba14cf461a0a58b1afcc61f228so, why it failed from 4.14 to 4.15: the name generated rule is different, so it can not find role and failed with unknown.
why it succeed from 4.15 to 4.16: the changed code is on both 4.15 and 4.16, and the name generated rule is same, so it can find role.
