Bug 2093176
| Summary: | "constraints not satisfiable" error on various operators with no identifiable trend | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Matt Bargenquast <mbargenq> |
| Component: | OLM | Assignee: | Per da Silva <pegoncal> |
| OLM sub component: | OLM | QA Contact: | Jian Zhang <jiazha> |
| Status: | CLOSED DUPLICATE | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | aabhishe, apurty, asheth, cblecker, efried, jkeister, nmalik, travi |
| Version: | 4.10 | Keywords: | ServiceDeliveryBlocker, ServiceDeliveryImpact |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-02-08 21:57:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I have also been able to replicate this on a v4.9 cluster (4.9.35) in addition to 4.10. *** This bug has been marked as a duplicate of bug 1980755 *** |
Description of problem: The OpenShift Dedicated and ROSA OpenShift fleet are observing cases where the Subscription of operators they are deploying are entering a "constraints not satisfiable" state: constraints not satisfiable: subscription rbac-permissions-operator requires at least one of rbac-permissions-operator-registry/openshift-rbac-permissions/production/rbac-permissions-operator.v0.1.202-736d967, rbac-permissions-operator-registry/openshift-rbac-permissions/production/rbac-permissions-operator.v0.1.198-7296439, ........ A CSV will be installed, and the operator will be running, however the subscription will report the above error. It also seems to prevent the operator from updating to any newer CSVs once the subscription enters this state. The operators that this has been observed on are deployed via deploying an OperatorGroup, CatalogSource and Subscription resource onto the cluster, for example: apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: labels: opsrc-datastore: "true" opsrc-provider: redhat name: rbac-permissions-operator-registry namespace: openshift-rbac-permissions spec: displayName: RBAC Permissions Operator icon: base64data: "" mediatype: "" image: quay.io/app-sre/rbac-permissions-operator-registry@sha256:9f41e5f74f930c8598aeaec12b59596d2676d292e750473b5c55c696679c8d28 publisher: Red Hat sourceType: grpc apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: rbac-permissions-operator namespace: openshift-rbac-permissions spec: channel: staging name: rbac-permissions-operator source: rbac-permissions-operator-registry sourceNamespace: openshift-rbac-permissions apiVersion: operators.coreos.com/v1alpha2 kind: OperatorGroup metadata: name: rbac-permissions-operator namespace: openshift-rbac-permissions spec: targetNamespaces: - openshift-rbac-permissions Version-Release number of selected component (if applicable): Observed across numerous 4.10 clusters. There does not appear to be any consistency as to if a cluster will be impacted (some will not be), or which operator is impacted. How reproducible: Unknown