-
Bug
-
Resolution: Done
-
Normal
-
None
-
1.1.0
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
I create this new bug to track the upgrade issue for bug COO-784 has been closed.
mark.stalpinski.crl.com Is the upgrade linear though (requiring to upgrade to 1.1.0 before going to 1.1.1)? Just curious if we need to apply this workaround, which is a bit problematic for us when we just tried this in our DEV and QA environment:
We just completed the upgrade of COO from version 1.0.0 to 1.1.0 in our DEV and QA environments but ran into a separate issue (one that we cannot replicate anymore as well in our LAB), this is how we ran into this
- We were on COO 1.0.0
- We modified the Sub to apply the resources as noted by https://access.redhat.com/solutions/7113898
- We then attempted the upgrade to 1.1.0 but ran into this error:
ConstraintsNotSatisfiableconstraints not satisfiable: subscription cluster-observability-operator requires @existing/openshift-cluster-observability-operator//cluster-observability-operator.v1.1.0, clusterserviceversion cluster-observability-operator.v1.0.0 exists and is not referenced by a subscription, @existing/openshift-cluster-observability-operator//cluster-observability-operator.v1.1.0 and @existing/openshift-cluster-observability-operator//cluster-observability-operator.v1.0.0 provide ThanosRuler (monitoring.rhobs/v1), subscription cluster-observability-operator exists
InstallComponentFailedcouldn't find unpacked step for cluster-observability-operator.v1.1.0: cluster-observability-operator.v1.1.0-7c99bd9fb8[rbac.authorization.k8s.io/v1/ClusterRole (redhat-operators/openshift-marketplace)] (Unknown)
So the upgrade got stuck and we had to delete the 1.0.0 CSV and uninstall the 1.1.0 Operator and reinstall the 1.1.0 Operator to get it back in order. Any idea why we would run into this?