Bug 1868714

Summary: operatorframework.io arch label not applied
Product: OpenShift Container Platform Reporter: Roddie Kieley <rkieley>
Component: OLMAssignee: lgallett
OLM sub component: OperatorHub QA Contact: Jian Zhang <jiazha>
Status: CLOSED NOTABUG Docs Contact:
Severity: high    
Priority: medium CC: bluddy, dageoffr, danili, jiazha, krizza, nhale, tbueno
Version: 4.6   
Target Milestone: ---   
Target Release: 4.7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-30 20:00:56 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:
Bug Depends On:    
Bug Blocks: 1880739    

Description Roddie Kieley 2020-08-13 15:07:20 UTC
Description of problem:

Recently to resolve customer issues
- https://issues.redhat.com/browse/ENTMQBR-3724
"OperatorHub pulling System Z operator image on x86_64 architecture"

The following labels were added to the productized and released AMQ Broker Operator container image for System Z:
  operatorframework.io/arch.s390x: supported
  operatorframework.io/os.linux: supported

As per https://operator-framework.github.io/olm-book/docs/multiarch.html

This was done via the addition of a new metadata manifest version 0.10.1 whereas the original 0.10.0 did NOT have the labeling at all and was using the implicit defaults of arch.amd64 and os.linux supported.

However recently when testing another issue in an internally deployed OCP 4.6 instance I reviewed the OperatorHub list I continued to see BOTH the x86_64 and s390x entries. When reviewing the PackageManifest for the new 0.10.1 version, which appeared to be correctly made available, I see that the label was arch.amd64 supported and NOT arch.s390x supported as expected and verified to be a part of the manifest in the shipped container image.


Version-Release number of selected component (if applicable):

amq-broker-rhel8-operator-container-0.10-16


How reproducible:

Every time I checked.


Steps to Reproduce:
1. Deploy OCP 4.6
2. Open OperatorHub
3. See correct x86_64 'Red Hat Integration - AMQ Broker' and incorrect s390x 'AMQ Broker' operators BOTH listed.

Actual results:

See BOTH x86_64 and s390x labeled operators in OperatorHub.


Expected results:

Do NOT see arch.s390x labeled operator in x86_64 OCP 4.6 OperatorHub.


Additional info:

Comment 5 Jian Zhang 2020-08-28 06:04:55 UTC
Hi Kevin,

Apologize for the late repy, I guess you want to ask the reporter in comment 3.
> Can you run oc get packagemanifests --all-namespaces and post the result here? Are you looking for a way to mark two different operator packages as the same on the console?

Comment 6 Roddie Kieley 2020-09-08 13:13:34 UTC
Hi, apologies for the late reply. At this point the cluster and the setup where this was observed is no longer available however at the time I did take some screenshots, but I'm not sure that's meaningful given the question asked. A feature was previously already added to to disambiguate multiarch manifests inside the embedded OperatorHub as per https://operator-framework.github.io/olm-book/docs/multiarch.html. This feature was utilized as per direct instruction to resolve multiple arch's manifests from showing up in the same OperatorHub, e.g. s390x manifest showing up in an x86_64 based OCP deployment. However even with the appropriate labeling the multiple arch manifests still show up in the embedded OperatorHub such that operator manifests for s390x and x86_64 are both incorrectly shown as per the example.

Comment 11 lgallett 2020-11-05 16:22:20 UTC
If this is still a an active customer case, I need access to such a cluster to reproduce and further investigate. How can I get access to such a cluster?

Comment 13 lgallett 2020-11-30 20:00:56 UTC
The labels in 0.10.1 are not properly set. They should be defined under metadata.labels instead of labels.

In dist-git today:

```
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: amq-broker-operator.v0.10.1-on-z
labels:
  operator-activemqartemis: "true"
  operatorframework.io/arch.s390x: supported
  operatorframework.io/os.linux: supported
```

but it should be

```
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: amq-broker-operator.v0.10.1-on-z
  labels:
    operator-activemqartemis: "true"
    operatorframework.io/arch.s390x: supported
    operatorframework.io/os.linux: supported
```

Comment 14 Roddie Kieley 2020-12-07 10:26:00 UTC
Spoke with lgalletti directly to review status, updated instructions, and next steps.