> This yields `v1.0.0-1.2.3 < v1.0.0-1.1.55` which is then mapped back to `v1.2.3+1.2.3 < v.1.2.3+1.1.55` Does it follow the typical semver precedence rules? If yes, I guess it should be `v1.0.0-1.1.55 < v1.0.0-1.2.3`, right? Sorry, I couldn't reproduce this issue with an old opm. For example, am I missing something? Or what's the difference between opm and the build command in http://pub.devel.redhat.com/pub/task/340215/log/stdout.log? [root@preserve-olm-env data]# opm index add -b registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1 -f registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7 -t registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7-bug --overwrite-latest INFO[0000] building the index bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]" INFO[0000] Pulling previous image registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7 to get metadata bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]" INFO[0000] resolved name: registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7 bundles="[registry.stage.redhat.io/openshift-is ... ... INFO[0020] [podman build --format docker -f index.Dockerfile879176593 -t registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.7-bug .] bundles="[registry.stage.redhat.io/openshift-istio/kiali-operator-metadata:2.3-1]" [root@preserve-olm-env data]# opm version Version: version.Version{OpmVersion:"v1.14.3-94-g6183dbb", GitCommit:"6183dbb", BuildDate:"2021-02-04T09:33:47Z", GoOs:"linux", GoArch:"amd64"} It works well too with the olm opm: - `registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.5` - `registry-proxy.engineering.redhat.com/rh-osbs/iib-pub-pending:v4.6` registry.stage.redhat.io/openshift-service-mesh/istio-rhel8-operator-metadata:2.0.1.1-6
Hi Jian, So the problem that we ran into here is that there is one operator in the stage index that was using buildId as part of its versioning. So it was explicitly *not* using semantic versioning. This generally isn't a problem in replaces mode except in the case where bundles are batch added as a set into an index all at once (which happens either when you pass several bundles into an index add command or whenever using --overwrite-latest). So, this edge case is specifically when buildId is set on two bundles in a given channel and the version is otherwise identical. more detail here: https://github.com/operator-framework/operator-registry/pull/571#issue-563493254 Basically, the fix here is that we now consider buildId when attempting to internally decide what order to insert a set of bundles when more than one is passed in.
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 (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), 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/RHSA-2021:2438