Bug 1776605 - [sriov] sriov operator cannot be upgraded
Summary: [sriov] sriov operator cannot be upgraded
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.3.0
Hardware: All
OS: All
urgent
urgent
Target Milestone: ---
: 4.4.0
Assignee: Peng Liu
QA Contact: zhaozhanqi
URL:
Whiteboard:
Depends On:
Blocks: 1773840 1783111
TreeView+ depends on / blocked
 
Reported: 2019-11-26 04:55 UTC by Peng Liu
Modified: 2020-05-04 11:17 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1773840
: 1783111 (view as bug list)
Environment:
Last Closed: 2020-05-04 11:17:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift sriov-network-operator pull 125 0 'None' closed [release-4.3] BUG 1776605: Prepare operator bundle for 4.3 2020-02-04 13:12:30 UTC
Github openshift sriov-network-operator pull 129 0 'None' closed [release-4.3] BUG 1776605: update the CSV file skipRange 2020-02-04 13:12:30 UTC
Github openshift sriov-network-operator pull 139 0 None closed Bug 1776605: Update the olm.skipRange in operator bundle 2020-02-04 13:12:31 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-04 11:17:36 UTC

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


Note You need to log in before you can comment on or make changes to this bug.