Bug 1827723
Summary: | OPM fails to infer package | ||||||
---|---|---|---|---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Bruno Andrade <bandrade> | ||||
Component: | OLM | Assignee: | Bowen Song <bsong> | ||||
OLM sub component: | OLM | QA Contact: | Bruno Andrade <bandrade> | ||||
Status: | CLOSED ERRATA | Docs Contact: | |||||
Severity: | medium | ||||||
Priority: | medium | CC: | bsong, ecordell, jiazha, kuiwang | ||||
Version: | 4.5 | ||||||
Target Milestone: | --- | ||||||
Target Release: | 4.5.0 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
Cause:
If a bundle in the package belongs to a set of channels that does not include the current default channel, the cmd would fail on verification. This was because after a bundle is released, the default channel may change or get created that is not part of the channels the old bundle belongs to.
Consequence:
Verification ensures that the default channel is also included in the set of channels a bundle belongs to. Since verification is triggered upon writing annotations.yaml file, the cmd would fail.
Fix:
The default channel is an optional field and since bundle's original default channel is no longer the correct one for the package and is the subject of inference, not specified by the user, the inference will leave the default channel blank since there is no way of getting this optional information.
Result:
Default Channel will be left blank for the bundle if the current default channel is not part of the channel set for the bundle.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-07-13 17:31:25 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: | |||||||
Attachments: |
|
Description
Bruno Andrade
2020-04-24 15:58:47 UTC
Uhmm... I uhhh. I know this is confusing. would you please provide your package directory? [bowensong@red-bowen etcd]$ tree . ├── 0.6.1 │ ├── etcdclusters.etcd.database.coreos.com.crd.yaml │ └── etcdoperator-community.v0.6.1.clusterserviceversion.yaml ├── 0.9.2 │ ├── etcdbackups.etcd.database.coreos.com.crd.yaml │ ├── etcdclusters.etcd.database.coreos.com.crd.yaml │ ├── etcdoperator.v0.9.2.clusterserviceversion.yaml │ └── etcdrestores.etcd.database.coreos.com.crd.yaml └── etcd.package.yaml [bowensong@red-bowen etcd]$ cat etcd.package.yaml channels: - name: alpha currentCSV: etcdoperator.v0.9.2 - name: beta currentCSV: etcdoperator.v0.9.0 - name: stable currentCSV: etcdoperator.v0.9.2 defaultChannel: alpha packageName: etcd [bowensong@red-bowen operator-registry]$ ./bin/opm alpha bundle generate --directory ../community-operators/upstream-community-operators/etcd/0.9.2/ INFO[0000] Bundle channels and package name information not provided, inferring from parent package directory INFO[0000] Inferred channels: alpha,stable INFO[0000] Inferred package name: etcd INFO[0000] Inferred default channel: alpha INFO[0000] Building annotations.yaml INFO[0000] Building Dockerfile [bowensong@red-bowen etcd]$ cat metadata/annotations.yaml annotations: operators.operatorframework.io.bundle.channel.default.v1: alpha operators.operatorframework.io.bundle.channels.v1: alpha,stable operators.operatorframework.io.bundle.manifests.v1: manifests/ operators.operatorframework.io.bundle.mediatype.v1: registry+v1 operators.operatorframework.io.bundle.metadata.v1: metadata/ operators.operatorframework.io.bundle.package.v1: etcd My Git Log [bowensong@red-bowen operator-registry]$ git log commit 5c21e0f3b9b2f6b07ee1e08322199abd54475dd8 (HEAD -> bug/understandsingBundles1827723, upstream/master) Merge: bf0c8f1 dc99201 Author: OpenShift Merge Robot <openshift-merge-robot.github.com> Date: Thu Apr 30 08:16:22 2020 +0200 Merge pull request #312 from benluddy/deps-not-found-optional Bug 1827992: Clarify log message to indicate that dependencies.yaml is optional. commit dc99201b1c7499cc2d7defd12345ea3158ead622 Author: Ben Luddy <bluddy> Date: Thu Apr 30 00:48:27 2020 -0400 Clarify log message to indicate that dependencies.yaml is optional. commit bf0c8f1590d21e54e97c1446b09fae72ade51280 (origin/master, origin/HEAD, master) Merge: 6e6a14d cfb8d0f Author: OpenShift Merge Robot <openshift-merge-robot.github.com> Date: Tue Apr 28 02:59:56 2020 +0200 Merge pull request #289 from dinhxuanvu/fix-dep-types Bug 1826766: fix(types): Fix GetDependencies func that returns duplicate items Hi Bowen, I'm using manifests from operator-registry at the latest version. Did the instructions as you requested, please let me know if you need something else from my side. Thanks git log --pretty=format:'%h' -n 1 d21c6e7 rm -rf manifests/etcd/bundle.Dockerfile manifests/etcd/metadata/ git status # On branch master nothing to commit, working directory clean cat 0.9.2/etcdoperator.v0.9.2.clusterserviceversion.yaml | grep "etcdoperator.v0.9.2" name: etcdoperator.v0.9.2 cd manifests/etcd opm alpha bundle generate --directory ./0.9.2 INFO[0000] Bundle channels and package name information not provided, inferring from parent package directory INFO[0000] Inferred channels: beta INFO[0000] Inferred package name: etcd INFO[0000] Inferred default channel: INFO[0000] Building annotations.yaml INFO[0000] Building Dockerfile cat bundle.Dockerfile FROM scratch LABEL operators.operatorframework.io.bundle.mediatype.v1=registry+v1 LABEL operators.operatorframework.io.bundle.manifests.v1=manifests/ LABEL operators.operatorframework.io.bundle.metadata.v1=metadata/ LABEL operators.operatorframework.io.bundle.package.v1=etcd LABEL operators.operatorframework.io.bundle.channels.v1=beta LABEL operators.operatorframework.io.bundle.channel.default.v1= COPY 0.9.2 /manifests/ COPY metadata /metadata/ could you please attach your directory on this bug? thanks. Created attachment 1687131 [details]
Etcd Manifest
found the problem lies in this testing package directory: [bowensong@red-bowen operator-registry]$ tree ~/Downloads/etcd_manifest/etcd/ /home/bowensong/Downloads/etcd_manifest/etcd/ ├── 0.6.1 │ ├── etcdcluster.crd.yaml │ └── etcdoperator.clusterserviceversion.yaml ├── 0.9.2 │ ├── etcdbackup.crd.yaml │ ├── etcdcluster.crd.yaml │ ├── etcdoperator.v0.9.0.yaml │ ├── etcdoperator.v0.9.2.clusterserviceversion.yaml │ └── etcdrestore.crd.yaml └── etcd.package.yaml In 0.9.2/ directory, both `etcdoperator.v0.9.0.yaml` and `etcdoperator.v0.9.2.clusterserviceversion.yaml` are CSVs. We have a hard assumption that each bundle has one CSV, in this case should be the one matching the operator version 0.9.2. In etcdoperator.v0.9.2.clusterserviceversion.yaml, there is no `installMode` either which is required for CSV. we expect the annotations.yaml for `0.9.2` to be: annotations: operators.operatorframework.io.bundle.channel.default.v1: alpha operators.operatorframework.io.bundle.channels.v1: alpha,stable operators.operatorframework.io.bundle.manifests.v1: manifests/ operators.operatorframework.io.bundle.mediatype.v1: registry+v1 operators.operatorframework.io.bundle.metadata.v1: metadata/ operators.operatorframework.io.bundle.package.v1: etcd Which i was able to generate after the change. Please let me know if you agree with the assumption and the outcome. Thank you Got it, thanks, in that case, do you think we can add a warning/error informing the user that inference could not work due to that matter? fair enough, adding it! LGTM, marking as verified. The following message is shown when more than one CSV in the directory if the command is run without package and default channel arguments. opm alpha bundle generate --directory 0.9.2/ INFO[0000] Bundle channels and package name information not provided, inferring from parent package directory Error: please manually input channels and packageName, error interpreting bundle from directory /home/vagrant/operator-registry/manifests/etcd/0.9.2, error loading CSV from bundle directory, more than one ClusterServiceVersion is found in bundle Thanks 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, 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-2020:2409 |