Description of problem (please be detailed as possible and provide log snippests): Version of all relevant components (if applicable): 4.2.1 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? This is necessary for working in restricted network environments Is there any workaround available to the best of your knowledge? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? Yes Can this issue reproduce from the UI? No Steps to Reproduce: 1. Use oc adm catalog build and oc adm catalog mirror from 4.3.0+ to mirror images 2. Note none of the OCS operand containers are found 3. Review the CSV to see spec.relatedImages is missing Actual results: Operand containers are not mirrored Expected results: Operand containers are mirrored. Additional info:
This looks valid, ACKing it.
Unless I am missing something, it looks like the relatedImages field is still a proposal and is not part of the ClusterServiceVersion spec yet design proposal: https://github.com/operator-framework/operator-lifecycle-manager/blob/4edf102c1054b9e7e8de772f9d0316425cca6513/doc/contributors/design-proposals/related-images.md clusterserviceversion_types.go: https://github.com/operator-framework/operator-lifecycle-manager/blob/82553746c788454fa18dc32c98a0237668deee42/pkg/api/apis/operators/clusterserviceversion_types.go @jmontleo, any idea what is the status of that?
It looks like the csv is eventually parsed as json and the relatedImages are read from there (https://github.com/operator-framework/operator-registry/blob/d5d62c23c8a04d277d5e2dbca16c3fd794e69a79/pkg/registry/csv.go#L210)
This was implemented and is used by current oc versions to build a list of images to mirror: https://github.com/operator-framework/operator-registry/commit/8415c1896add93bf8ad51e1be6acc8648e52e180
A reminder that OCS 4.3 need to be supported on both OCP 4.3 and 4.2. Since this is a change in the spec, does this mean making this change will break the OCS 4.3 CSV on OCP 4.2?
No. relatedImages is supported on 4.2 as well. Our operator has this and installs just fine on 4.2 (and 4.1 I believe).
disconnected environment is out of 4.3. According to discussion with Nimrod, I am moving this to 4.4
although the disconnected cluster is out of 4.3 I think this fix should be included in 4.3. without the relatedImages in the CSV in quay.io we won't be able to validate the installation in a disconnected env
(In reply to Danny from comment #12) > although the disconnected cluster is out of 4.3 I think this fix should be > included in 4.3. > without the relatedImages in the CSV in quay.io we won't be able to validate > the installation in a disconnected env We are not usually putting some code into a release for a feature in order to be able to test that feature with a product version before the product actually supports it. So I'd like to understand why having the patch in master / upstream / custom builds is not enough to test it? We can also bring it in the very first OCS 4.4 build d/s. Just trying to understand the reasoning why this needs to be in 4.3.0. :-)
I will let Danny answer regarding the technical reasons, but there is still hope (backed up by high demand of customers) to have it ASAP, so 4.3.z is an option if we'd be able to make it.
And in order to reduce the time spent in waiting for builds and merges, I think it should be a part of 4.3
(In reply to Nimrod Becker from comment #15) > And in order to reduce the time spent in waiting for builds and merges, I > think it should be a part of 4.3 Well, I still disagree with the reason: Whatever is the next release 4.3.z or 4.4.0, we'll have to do at least one build for that anyway. And we can have this in the very first build for it. Not saying that we can not put the patch into 4.3.0, but I'm still not convinced by the reasoning. If we can have it in the dev freeze build, and it does not harm - fine. But with my current understanding I would disagree with blocking for it.
@michael the relatedImages field is used by openshift client during the process of mirroring the registry. As far as I understand it is done by going over the catalog DB and mirror any related image in the process I guess it can be done also by supplying a custom catalog image, but without this field in the released csv, we won't be able to validate it end to end before the release. I think it's a low-risk fix, although I understand your concerns
This is lacking qa_ack. We can not yet take it for 4.4 like this.
d/s PR merged
Hey Danny, where we can see relatedImages parameter in the CSV? http://pastebin.test.redhat.com/857880 This is CSV for build v4.4.0-412.ci but no mention of: relatedImages If it was suppose to be there than it failed QE. Thanks
Hi Petr. I talked to Boris Ranto to try and figure it out. you can see the relatedImages in the generated CSV here: http://pkgs.devel.redhat.com/cgit/containers/ocs-olm/tree/manifests/4.4.0-412.ci/ocs-operator.v4.4.0-412.ci.clusterserviceversion.yaml?h=ocs-4.4-rhel-8 where did you get the CSV you pasted? if you get it from an installed cluster using `oc get csv`, then that explains it. the relatedImages field is not part of the clusterServiceVersion type in go (see here: https://github.com/operator-framework/operator-lifecycle-manager/blob/82553746c788454fa18dc32c98a0237668deee42/pkg/api/apis/operators/clusterserviceversion_types.go). it is used as an annotation for `oc adm catalog mirror` command, and it is stored in the text yaml in the OLM catalog. once it is applied to a cluster it is converted to a binary structure. since it's not part of the type it is ignored. hope that answers your question
Hey Danny, yep it was directly from `oc get csv`. I think that Daniel commented directly in KNIP with other issues he hit today with testing with internal builds. Thanks for explanation. Daniel if you have some issue you can also report here directly in BZ
Hi Danny, when I compare images mentioned somewhere in the ocs-operator*clusterserviceversion.yaml file with the images mentioned at the end of the file in relatedImages section, there are two images mentioned in the body of the file which are not mentioned in the relatedImages section - one of them is ocs-operator image, the second one ose-csi-external-resizer-rhel7 image. For ocs-olm-operator:4.4.0-420.ci it is those two images: quay.io/rhceph-dev/ocs-operator@sha256:fd9542d11caacf402cb3e5e99ece556fb56947e4fd4e35edcca88263e4a44246 registry.redhat.io/openshift4/ose-csi-external-resizer-rhel7@sha256:e7302652fe3f698f8211742d08b2dcea9d77925de458eb30c20789e12ee7ae33 Is it expected? Shouldn't be those two images also mentioned in the relatedImages section?
Hi Daniel. Thanks, good catch. the ocs-operator image doesn't have to be in the relatedImages, but the ose-csi-external-resizer-rhel7 is indeed missing. it was probably added to the csv-merger without adding it to the relatedImages generating code.
ocs-olm-operator csv now contains relatedImages section: $ podman run --rm --entrypoint /usr/bin/cat \ quay.io/rhceph-dev/ocs-olm-operator:4.4.0-437.ci \ /manifests/4.4.0-437.ci/ocs-operator.v4.4.0-437.ci.clusterserviceversion.yaml ...truncated... relatedImages: - image: quay.io/rhceph-dev/rook-ceph@sha256:708c5e3b3d075235b8031618e2342d4d8df383d191e197fb81a7f7416494eb14 name: rook-container - image: quay.io/rhceph-dev/cephcsi@sha256:6b0b8fe1b7c809381f93e874c8b89b3cbb0ad7f183c8bc06c441efe48cf0a746 name: rook-csi - image: registry.redhat.io/openshift4/ose-csi-driver-registrar@sha256:85dedabd1e0dc51fda054fc51eee571d274f3ae3a088acf768c18ad73d60406c name: rook-csi-registrar - image: registry.redhat.io/openshift4/ose-csi-external-provisioner-rhel7@sha256:535379c05aa75405254bf0139dfad43dd8568ae6de37650746c8c961e473dcf2 name: rook-csi-provisioner - image: registry.redhat.io/openshift4/ose-csi-external-attacher@sha256:19a6384b7a17e5781358a5264a8f9d137e2a2118c903ae8010c3c216e0f8e588 name: rook-csi-attacher - image: quay.io/rhceph-dev/rhceph@sha256:9e521d33c1b3c7f5899a8a5f36eee423b8003827b7d12d780a58a701d0a64f0d name: ceph-container - image: quay.io/rhceph-dev/mcg-operator@sha256:701eae453b29646182533719fa312731bebf1fb53414762894324813b0d7a17a name: noobaa-operator - image: quay.io/rhceph-dev/mcg-core@sha256:527b648dbb9d2754eaecd24d6d9eaf36c4434994ad59d65013d18e06ae400c23 name: noobaa-core - image: registry.redhat.io/rhscl/mongodb-36-rhel7@sha256:fa0d0c43f79410d7b2edeb78329e6bf5c9ca5ced141b12341eb34a4042a1dc0a name: noobaa-db version: 4.4.0-437.ci There is one image (ose-csi-external-resizer-rhel7) mentioned in the csv but not listed in the relatedImages section, this is reported as bug 1840708. >> 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, 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:2393