Bug 1776605

Summary:	[sriov] sriov operator cannot be upgraded
Product:	OpenShift Container Platform	Reporter:	Peng Liu <pliu>
Component:	Networking	Assignee:	Peng Liu <pliu>
Networking sub component:	SR-IOV	QA Contact:	zhaozhanqi <zzhao>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	urgent
Priority:	urgent	CC:	bandrade, jfan, nhale, scolange, tbuskey, zzhao
Version:	4.3.0	Keywords:	Reopened, TestBlocker
Target Milestone:	---
Target Release:	4.4.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1773840
Clones:	1783111 (view as bug list)		Environment:
Last Closed:	2020-05-04 11:17:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1773840, 1783111

Description Peng Liu 2019-11-26 04:55:54 UTC

+++ 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:

Comment 5 Jian Zhang 2019-12-12 07:57:16 UTC

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"

Comment 9 Jian Zhang 2019-12-13 05:58:55 UTC

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.

Comment 10 Evan Cordell 2019-12-13 13:37:25 UTC

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.

Comment 15 zhaozhanqi 2019-12-20 03:15:57 UTC

Verified this bug on 4.3.0-201912190717

Comment 18 errata-xmlrpc 2020-05-04 11:17:08 UTC

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