Description of problem: If create a sub without setting the channel, the default channel does not work. the sub will not update, and cannot set the channel from the GUI. Version-Release number of selected component (if applicable): [root@preserve-olm-agent-test ~]# oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.9.0-0.nightly-2021-07-21-081948 True False 158m Cluster version is 4.9.0-0.nightly-2021-07-21-081948 How reproducible: always Steps to Reproduce: 1. creat a sub without setting the channel. zhaoxia@xzha-mac test % cat sub_eclipse_che.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: test-1 namespace: test-2130 spec: installPlanApproval: Manual name: eclipse-che source: community-operators sourceNamespace: openshift-marketplace startingCSV: "eclipse-che.v7.32.0" zhaoxia@xzha-mac test % oc apply -f sub_eclipse_che.yaml subscription.operators.coreos.com/test-1 created 2. approve the installplan 3. checking the sub status. the sub cannot be updated in the default channel. Actual results: the sub cannot be updated in the default channel. And Cannot set the channel to be correct one from GUI. Expected results: the sub can be updated in the default channel, Can set the channel from GUI. Additional info: The GUI output: https://user-images.githubusercontent.com/77608951/126738778-c6dc6cb2-309e-4c06-b301-7d83e1cee9bc.png
> the sub can be updated in the default channel, Can set the channel from GUI. These seem like separate issues. If the operator is unable to properly step through an update that it defined in its upgrade path, then we would need more information to determine if there's actually an OLM bug here -- operators can fail to update for many valid installation reasons. The second issue, that the channel can't be updated from the UI isn't an issue for the OLM component, it would be a problem on the console. I'm reassigning this BZ to the Console for further triage on that issue. If you can reproduce a specific OLM related bug around an upgrade failing when it should be succeeding, please feel free to file another BZ.
(In reply to Kevin Rizza from comment #1) > > the sub can be updated in the default channel, Can set the channel from GUI. > > > These seem like separate issues. If the operator is unable to properly step > through an update that it defined in its upgrade path, then we would need > more information to determine if there's actually an OLM bug here -- > operators can fail to update for many valid installation reasons. > > The second issue, that the channel can't be updated from the UI isn't an > issue for the OLM component, it would be a problem on the console. > > I'm reassigning this BZ to the Console for further triage on that issue. If > you can reproduce a specific OLM related bug around an upgrade failing when > it should be succeeding, please feel free to file another BZ. hi Kevin, I think this issue and sub/channel here you are referring to is with respect to knative/serverless right? which is powered by the installation of OpenShift Serverless operator? the sub you are trying as in the description is not of knative it has `apiVersion: operators.coreos.com/v1alpha1` and spec is as well not of knative subscription, below is the sample for Knative Subscription ``` apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: name: my-subscription namespace: default spec: channel: apiVersion: messaging.knative.dev/v1 kind: Channel name: example-channel subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display ``` If Subscription is created before as above and has reference to channel in spec and channel/knative service created with GUI then they got connected and even show up in topology view in dev console documentation can be seen here for channels/subscription. https://docs.openshift.com/container-platform/4.8/serverless/channels/serverless-channels.html let me know if am missing anything.
If this issue is not wrt to knative/serverless then appropriate component would be `Management Console` or `OLM` as `Dev Console` is mainly associated with dev perspective in OCP
@xzha @yapei It seems that I can update the sub in the default channel using integrity-shield-operator in the cluster version 4.9.0-0.nightly-2021-09-09-145014. Could you please retest? Let me know if you have any concerns. See attached.
Verify: zhaoxia@xzha-mac abc % oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.9.0-0.nightly-2022-02-24-113925 True False 85s Cluster version is 4.9.0-0.nightly-2022-02-24-113925 1) create ns zhaoxia@xzha-mac abc % oc new-project test-2130 2) create og/sub zhaoxia@xzha-mac abc % cat og.yaml kind: OperatorGroup apiVersion: operators.coreos.com/v1 metadata: name: og-single namespace: test-2130 spec: targetNamespaces: - test-2130 zhaoxia@xzha-mac abc % cat sub.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: test-yaks namespace: test-2130 spec: installPlanApproval: Automatic name: yaks source: community-operators sourceNamespace: openshift-marketplace startingCSV: "yaks-operator.v0.5.0" zhaoxia@xzha-mac abc % oc apply -f og.yaml operatorgroup.operators.coreos.com/og-single created zhaoxia@xzha-mac abc % oc apply -f sub.yaml subscription.operators.coreos.com/test-yaks created 3) check csv zhaoxia@xzha-mac abc % oc get csv NAME DISPLAY VERSION REPLACES PHASE yaks-operator.v0.5.0 YAKS Operator 0.5.0 yaks-operator.v0.4.0 Installing later: zhaoxia@xzha-mac abc % oc get csv NAME DISPLAY VERSION REPLACES PHASE yaks-operator.v0.8.0 YAKS Operator 0.8.0 yaks-operator.v0.7.0 Succeeded The CSV has been updated to the latest. Check GUI, it is also OK. https://user-images.githubusercontent.com/77608951/155673995-34b5eaef-ae8d-47be-a554-fd35758d2b8c.png LGTM, verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.9.24 bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:0798