Description of problem: If olm.bundle.object of the channel head is not set, the operator neither be found with commands 'oc get packagemanifest' nor from the web console. "opm validate" should raise an error message. Version-Release number of selected component (if applicable): zhaoxia@xzha-mac operator-1 % opm version Version: version.Version{OpmVersion:"a768ef8e8", GitCommit:"a768ef8e86e00e25fa8612dbf9f6984721449255", BuildDate:"2021-09-23T08:24:58Z", GoOs:"darwin", GoArch:"amd64"} How reproducible: always Steps to Reproduce: 1. create index.yaml zhaoxia@xzha-mac operator-1 % cat index.yaml --- schema: olm.package name: operator-1 defaultChannel: alpha --- entries: - name: operator-1.v0.1.0 - name: operator-1.v0.2.0 replaces: operator-1.v0.1.0 name: alpha package: operator-1 schema: olm.channel --- image: quay.io/xzhao/operator-1-bundle:v0.1.0 name: operator-1.v0.1.0 package: operator-1 properties: - type: olm.gvk value: group: example.my.domain kind: Operator version: v1alpha1 - type: olm.package value: packageName: operator-1 version: 0.1.0 schema: olm.bundle --- image: quay.io/xzhao/operator-1-bundle:v0.2.0 name: operator-1.v0.2.0 package: operator-1 properties: - type: olm.gvk value: group: example.my.domain kind: Operator version: v1alpha1 - type: olm.package value: packageName: operator-1 version: 0.2.0 schema: olm.bundle 2. run "opm valiate ." zhaoxia@xzha-mac operator-1 % opm validate . zhaoxia@xzha-mac operator-1 % 3. Actual results: "opm validate" do not raise an error message. Expected results: "opm validate" raise an error message to warn the author "If olm.bundle.object of the channel head is not set, the operator neither be found with commands 'oc get packagemanifest' nor from the web console." Additional info:
There is a PR to add a downstream validation step to check for bundle objects on channel heads, https://github.com/openshift/operator-framework-olm/pull/210. The effects of the bug should mostly go away with the changes to render adding bundle objects to rendered bundles by default.
I'm going to move this back to ASSIGNED back on Ankita's previous comment. It sounds like we may get this behavior for free when the new render logic (which should've landed downstream yesterday), so I'm going to mark this as reviewed-in-sprint as well. We may want to investigate whether this is a potential CLOSED/WONTFIX candidate and track opm validate encoding logic to determine whether a bundle has the sufficient metadata to be compliant with the packagemanifest API.