Description of problem (please be detailed as possible and provide log snippests): ---------------------------------------------------------------------- The CSV generation scripts are not putting noobaa-core image, noobaa-db image and ocs-operator image in the relatedImages field. Version of all relevant components (if applicable): ---------------------------------------------------------------------- All Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? ---------------------------------------------------------------------- Yes Is there any workaround available to the best of your knowledge? ---------------------------------------------------------------------- We have a workaround in the DS pipeline but we should fix this in the code. Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? ---------------------------------------------------------------------- Can this issue reproducible? ---------------------------------------------------------------------- Always Can this issue reproduce from the UI? ---------------------------------------------------------------------- If this is a regression, please provide more details to justify this: ---------------------------------------------------------------------- Steps to Reproduce: ---------------------------------------------------------------------- 1. Generate the ocs-operator CSV 2. 3. Actual results: ---------------------------------------------------------------------- No noobaa-core, noobaa-db and ocs-operator images are mentioned in the relatedImages fields. This fails the mirroring/disconnected environments. Expected results: ---------------------------------------------------------------------- The images are present in the relatedImages field. Additional info: ----------------------------------------------------------------------
You merged the following MR as a workaround for this: https://gitlab.cee.redhat.com/ceph/rhodf/-/merge_requests/90/diffs#diff-content-7fd0dd211347568bcbcd101c8ee399bcb030c104 My question is... why? Does the *ocs-operator* bundle need to specify these? Shouldn't the noobaa-operator bundle have these references? I don't see anything about it here, and I'm wondering if there should be: https://gitlab.cee.redhat.com/ceph/rhodf/-/blob/rhodf-4.10-rhel-8/distgit/containers/noobaa-operator-bundle/render_templates.in Is it taken care of by the NooBaa command that generates the CSV?
You still reference noobaa images (noobaa-core and noobaa-db) in the ocs-operator CSV, see here: http://pkgs.devel.redhat.com/cgit/containers/ocs-operator-bundle/tree/bundle/manifests/ocs-operator.clusterserviceversion.yaml?h=rhodf-4.10-rhel-8#n2427 This part is even being run -- that is how we discovered this issue. The issue is that if the images are not in the relatedImages field, the mirroring won't work properly -- the noobaa images won't get translated to the mirrored registry and ocs-operator is trying to access the images in the original registry. When doing a build we do mirror the images to quay.io and the original references do not exist -- they were not shipped to the RH registry, yet. This also breaks things like disconnected environment installations. Another option would be to drop the references to the images altogether. I am not sure if the code that references the noobaa images is actually needed or not.
Ah-ha... yes, that might be redundant at this point. I see that the NooBaa CSV already seems to be referencing them properly: http://pkgs.devel.redhat.com/cgit/containers/noobaa-operator-bundle/tree/manifests/mcg-operator.clusterserviceversion.yaml?h=ocs-4.9-rhel-8#n845 This could just be a vestige that we missed when moving NooBaa to its own CSV, so I would want to see if we can remove them from the ocs-operator CSV entirely.
Given that we have a workaround for the DS builds, and we're not stuck on this in our upstream testing, I think this should no longer be considered a potential blocker. We should probably still invest some time in digging further into this issue, but it's not hihg priority enough for me to consider it for ODF 4.10 relative to all the other work we're already doing. I don't think we have the engineering bandwidth to properly resolve this. Moving to ODF 4.11.
Hmm, besides regression testing, could QE team test this directly somehow?
Well, not really in a final build as we have the hack in the DS scripts that adds the missing related images to the CSV. Well, a way to test would be to try to generate the manifests directly from the ocs-operator repo and check what images are missing or not.
Ok then, QE will cover this via regression testing only.
Is this BZ still relevant?
Yes, we have a DS hack in place that adds these related images to the CSV but it would be better if ocs-operatore generated the related images properly and we could drop the hack.