Description of problem (please be detailed as possible and provide log snippets): OLM will create a channel for operators to communicate complex conditions by introducing the Condition CustomResourceDefinition. When an operator is installed, OLM will create a Condition CustomResource (CR) for the operator. The operator's RBAC will be configured such that it is only able to get the Condition resource it owns and update the resource's status subresource. When the Condition CR is created, OLM will update the deployments defined in the CSV with an addition environment variable: OperatorConditionName: The name of the operator's Condition CR With the aid of a library provided by the operator-sdk, operators may set conditions on the operator's respective Condition CR to communicate complex states to OLM For more details, see https://github.com/operator-framework/enhancements/blob/master/enhancements/operator-conditions.md Version of all relevant components (if applicable): Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Is there any workaround available to the best of your knowledge? Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? Can this issue reproducible? Can this issue reproduce from the UI? If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We intend to target this only for OCS 4.8
Nithya, is this already fixed in 4.8?
(In reply to Mudit Agarwal from comment #3) > Nithya, is this already fixed in 4.8? I don't think so.
I don't think this is currently a *strict* requirement of the OLM. We should be able to continue to operate as normal without using an OperatorConditions CR. Indeed, the linked enhancement states: "Operators may not opt-in to this feature, so existing behavior must be preserved in this case." As such, given that work has not started on this and no one is officially assigned, moving this to ODF 4.9.
This feature is already there in 4.9, moving it to MODIFIED Can be moved to ON_QA once we have the acks.
The OperatorConditions changes for OCS went in as part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1968606. However, the verification for that BZ is unlikely covered all the scenarios for the feature. Please use this BZ to do the required upgrade tests. More information is available at https://olm.operatorframework.io/docs/concepts/crds/operatorcondition/
QE team will validate via regression testing (standard upgrade testing), and on top of that, QE will check whether the new CR OperatorStatus resource is present in openshift-storage namespace.
Please test with any of the latest 4.9 build
I see that we have those CRs in 4.9: $ oc get OperatorCondition -n openshift-storage NAME AGE noobaa-operator.v4.9.0-164.ci 43h ocs-operator.v4.9.0-164.ci 43h odf-operator.v4.9.0-164.ci 43h Output of oc describe on one of the ODF operator condition: Name: odf-operator.v4.9.0-164.ci Namespace: openshift-storage Labels: operators.coreos.com/odf-operator.openshift-storage= Annotations: <none> API Version: operators.coreos.com/v2 Kind: OperatorCondition Metadata: Creation Timestamp: 2021-10-11T19:12:40Z Generation: 1 Managed Fields: API Version: operators.coreos.com/v2 Fields Type: FieldsV1 fieldsV1: f:metadata: f:labels: .: f:operators.coreos.com/odf-operator.openshift-storage: f:ownerReferences: .: k:{"uid":"7fe639cb-01c9-42e1-ba21-a10c700c5bfa"}: f:spec: .: f:deployments: f:serviceAccounts: Manager: olm Operation: Update Time: 2021-10-11T19:12:46Z Owner References: API Version: operators.coreos.com/v1alpha1 Block Owner Deletion: false Controller: true Kind: ClusterServiceVersion Name: odf-operator.v4.9.0-164.ci UID: 7fe639cb-01c9-42e1-ba21-a10c700c5bfa Resource Version: 29484 UID: 98a0ec31-a7b1-47a7-9bce-864799f36c34 Spec: Deployments: odf-operator-controller-manager odf-console Service Accounts: odf-operator-controller-manager odf-operator-controller-manager Events: <none> N. Balachandran what conditions can lead that the operator Condition will not be upgradeable? Or what other scenarios should we test?
(In reply to Petr Balogh from comment #14) > > N. Balachandran what conditions can lead that the operator Condition will > not be upgradeable? Or what other scenarios should we test? StorageCluster creation and expansion should trigger a pause in upgrades until the pods the are up again
Ok, I have verified this with add capacity to cluster: pbalogh@pbalogh-mac pbalogh-stat $ oc get storagecluster -n openshift-storage NAME AGE PHASE EXTERNAL CREATED AT VERSION ocs-storagecluster 115m Progressing 2021-10-15T13:23:34Z 4.9.0 pbalogh@pbalogh-mac pbalogh-stat $ oc describe OperatorCondition -n openshift-storage |grep -B 6 Upgradeable Spec: Conditions: Last Transition Time: 2021-10-15T15:19:17Z Message: StorageCluster is not ready. Reason: NotReady Status: False Type: Upgradeable -- Conditions: Last Transition Time: 2021-10-15T15:19:17Z Message: StorageCluster is not ready. Observed Generation: 12 Reason: NotReady Status: False Type: Upgradeable pbalogh@pbalogh-mac pbalogh-stat $ oc get storagecluster -n openshift-storage NAME AGE PHASE EXTERNAL CREATED AT VERSION ocs-storagecluster 115m Progressing 2021-10-15T13:23:34Z 4.9.0 pbalogh@pbalogh-mac pbalogh-stat $ oc describe OperatorCondition -n openshift-storage |grep -B 6 Upgradeable Spec: Conditions: Last Transition Time: 2021-10-15T15:19:42Z Message: Reconcile completed successfully Reason: ReconcileCompleted Status: True Type: Upgradeable -- Conditions: Last Transition Time: 2021-10-15T15:19:42Z Message: Reconcile completed successfully Observed Generation: 15 Reason: ReconcileCompleted Status: True Type: Upgradeable pbalogh@pbalogh-mac pbalogh-stat $ oc get storagecluster -n openshift-storage NAME AGE PHASE EXTERNAL CREATED AT VERSION ocs-storagecluster 118m Ready 2021-10-15T13:23:34Z 4.9.0
Please add the doc text