+++ This bug was initially created as a clone of Bug #1773840 +++ Description of problem: sriov operator cannot be upgraded due to lack of 'skipRange' in csv Version-Release number of selected component (if applicable): quay.io/openshift-release-dev/ocp-v4.0-art-dev:v4.3.0-201911132228-ose-sriov-network-operator How reproducible: always Steps to Reproduce: 1. assume the clsuter already setup the sriov operator oc get csv NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.3.0-201911120917 SR-IOV Network Operator 4.3.0-201911120917 Succeeded 2. When the new sriov package has push to quay, see. 4.3.0-201911150628 is newer than 201911120917 # oc rsh -n openshift-marketplace opsrctest-78489ffd96-nr9g4 sh-4.2$ cat downloaded/sriov-network-operator/sriov-network-operator-qz298b9a/ 4.2/ 4.3/ sriov-network-operator.package.yaml sh-4.2$ cat downloaded/sriov-network-operator/sriov-network-operator-qz298b9a/sriov-network-operator.package.yaml channels: - currentCSV: sriov-network-operator.v0.0.1 name: '4.2' - currentCSV: sriov-network-operator.4.3.0-201911150628 name: '4.3' defaultChannel: '4.3' packageName: sriov-network-operator 3. Actual results: sriov operator cannot be upgraded Expected results: sriov operator can be upgraded when new packaged is coming. Additional info:
Based on my understanding, it should be upgraded to sriov-network-operator.4.4.0-201912110523. Correct me if I'm wrong, thanks! sh-4.2$ cat sriov-network-operator.v4.4.0.clusterserviceversion.yaml | grep skip olm.skipRange: ">=4.3.0 <4.4.0-201912110523"
Hi, Nick Yes, you're right. But, logically, I think 201912060615 < 201912110523, it should return true. How can we make it？ I think it's time for us to make the version definition rule. OLM should throw errors if the version definition not match.
There is not a logic bug for OLM to fix here - this is an issue with the skiprange that has been placed on the manifest. The semver spec states: > When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. (see point 11 here: https://semver.org/) That means that this can be fixed by changing the lower bound to `4.3.0-0`. Here's a test showing that this works: https://play.golang.org/p/BrX89RxoHpU There may be some work we want to do on the pipeline side to ensure these ranges are created correctly, but I'm going to go ahead and close this OLM bug.
Verified this bug on 4.3.0-201912190717
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:0581