+++ 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):
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
- currentCSV: sriov-network-operator.v0.0.1
- currentCSV: sriov-network-operator.4.3.0-201911150628
sriov operator cannot be upgraded
sriov operator can be upgraded when new packaged is coming.
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"
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.