since we have one branch for the bundle that serves all CNV versions, we can have only one Dockerfiles, which means only one version, so this is expected. Since the bundle isn't customer-facing (it's hidden in the container registry) I don't think it's a problem. If you still think that the version should be changed, we can fix it with the help of the operator team.
It is ugly, but I don't think that this is a block. We don't have any alternative at the moment to handle multiple channels. Ying, Nelly: how can a customer see that he is pulling a bunddle tagged v2.2.0? Unless there is a functional harm, I don't think that we should fix this in 2.3
Back then we discussed that the bundle would always be provided by the "stable" branch, thus here we could (a) update cnv 2.3 branch correctly and (b) change the automation to continue to update 2.3 branch. This way the bundle would contain the correct version. I'd say that we still have enought ime to do this change, although I'm also not considering this to be a blocker. And I do not yet see any negative side effects. Gal, Simone, what about changing the default branch to 2.3?
Following an offline discussion. Indeed there is not functionality issue here, hence lowering priority and this is not a blocker, but we are going to rebuild with the correct tag, so it will match the Openshift image - CNV2.3 is built on OCP4.4 So while not a blocker, Im still voting yes to fix it ASAP
(In reply to Nelly Credi from comment #6) > So while not a blocker, Im still voting yes to fix it ASAP +1, I am also voting yes to fix it in 2.3.
I agree, from my point of view everything is ready. It's "just" about moving the automation to point to 2.3 branch in distgit.
Issue fixed. `hco-bundle-registry-container-v2.3.0-19` is in the errata.
VERIFIED on hco-bundle-registry-container-v2.3.0-48. version information consistent with our release CNV 2.3 now. and the HCO deploys in ipi env. it works well. 'index': {'digests': {'application/vnd.docker.distribution.manifest.list.v2+json': 'sha256:55dd13c3d6fff77ac8628c3a9c5da5ad87b23e149cd6518e2c11a78208cf5f96'}, 'floating_tags': ['latest', 'v2.3.0', 'v2.3'], 'pull': ['registry-proxy.engineering.redhat.com/rh-osbs/container-native-virtualization-hco-bundle-registry@sha256:55dd13c3d6fff77ac8628c3a9c5da5ad87b23e149cd6518e2c11a78208cf5f96', 'registry-proxy.engineering.redhat.com/rh-osbs/container-native-virtualization-hco-bundle-registry:v2.3.0-48'], 'tags': ['v2.3.0-48'], 'unique_tags': ['cnv-2.3-rhel-8-containers-candidate-57994-20200323143545']},
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/RHEA-2020:2011