Bug 1770183 - local-storage-operator CSV is not upgraded
Summary: local-storage-operator CSV is not upgraded
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.5.0
Assignee: aos-storage-staff@redhat.com
QA Contact: Qin Ping
URL:
Whiteboard:
: 1817353 (view as bug list)
Depends On: 1783863
Blocks: 1817826
TreeView+ depends on / blocked
 
Reported: 2019-11-08 11:59 UTC by Petr Balogh
Modified: 2024-01-06 04:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1779545 1817826 (view as bug list)
Environment:
Last Closed: 2020-05-13 21:52:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift local-storage-operator pull 61 0 'None' closed Bug 1770183: Allow operator to be upgraded automatically 2020-11-19 08:32:20 UTC
Github openshift local-storage-operator pull 96 0 None closed Bug 1813115 and Bug 1770183: Fix version being displayed in UI 2020-11-19 08:32:19 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-13 21:52:35 UTC

Description Petr Balogh 2019-11-08 11:59:55 UTC
Description of problem:
After deploying OCP 4.2 and OCS 4.2 on top of it I see that version of CSV didn't get upgraded after there the new version appeared in catalog source.

$ oc get csv -n openshift-storage
NAME                                        DISPLAY                                VERSION              REPLACES                PHASE
local-storage-operator.4.2.0-201910101614   Local Storage                          4.2.0-201910101614                           Succeeded
ocs-operator.v0.0.213                       Openshift Container Storage Operator   0.0.213              ocs-operator.v0.0.196   Succeeded
$ oc get packagemanifest -n openshift-marketplace |grep local-storag
local-storage-operator                       Red Hat Operators             2d13h
$ oc get packagemanifest -n openshift-marketplace local-storage-operator -o yaml |grep currentCSV
  - currentCSV: local-storage-operator.4.2.1-201910221723


So you can see: Installed version:  4.2.0-201910101614  , from packageManifest: 4.2.1-201910221723

$ oc get subscription -n openshift-storage local-storage-operator-4.2-redhat-operators-openshift-marketplace -o yaml | Grep Automatic
  installPlanApproval: Automatic

I think that this install plan should automatically roll to new build.

This is problematic for me cause I want to in upgrade test and checks on long running cluster if the CSVs are in right version and in success shape.

Is there other way how to get CSV name than from PackageManifest? For example if installPlanApproval will be set to Manual and new build will appear how I can get the current installed name of the CSV? Currently it contain the version in the name: local-storage-operator.4.2.0-201910101614, so if I would like to do oc get local-storage-operator-version I will need to have way how to know which one is installed and suppose to be latest. Thanks

Version-Release number of selected component (if applicable):
CSV:    containerImage: quay.io/openshift/origin-local-storage-operator:4.2.0
Server Version: 4.2.0-0.nightly-2019-11-05-111920
Kubernetes Version: v1.14.6+488792c

How reproducible:
Deployed cluster, kept it running for 2 days, probably new build was pushed to the registry but didn't get rolled.

Steps to Reproduce:
1. Deploy OCP and OCS
2. Wait till new build of local-storage pushed to the registry
3. No upgrade is rolled for that CSV

Actual results:
No upgrade is happening

Expected results:
Roll to the new version of CSV local-storage-operator.4.2.1-201910221723

Not sure how the CSV is defined but is there replaces or skipRange defined? We had similar issue in OCS CSV described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1767400


Additional info:
I have must-gather logs if needed tell me and I will provide them. Also I have the cluster still running.

Comment 6 Liang Xia 2019-12-19 09:18:54 UTC
QE installed a OCP 4.4 cluster with local-storage today,

$ oc get csv -n local-storage | grep local-storage 
local-storage-operator.4.4.0-201912170523   Local Storage            4.4.0-201912170523              Succeeded

$ oc get packagemanifest -n openshift-marketplace local-storage-operator -o yaml | grep -w currentCSV
  - currentCSV: local-storage-operator.4.2.11-201912131719
  - currentCSV: local-storage-operator.4.2.11-201912131719-s390x
  - currentCSV: local-storage-operator.4.3.0-201912130552
  - currentCSV: local-storage-operator.4.4.0-201912170523

Will check back later.

Comment 7 Liang Xia 2020-01-03 05:54:24 UTC
Move back to dev to investigate.

Comment 10 Qin Ping 2020-03-26 13:05:08 UTC
Verified with:
$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.5.0-0.nightly-2020-03-25-223812   True        False         11h     Cluster version is 4.5.0-0.nightly-2020-03-25-223812


$ oc get csv
NAME                                        DISPLAY         VERSION              REPLACES                                    PHASE
local-storage-operator.4.5.0-202003261016   Local Storage   4.5.0-202003261016   local-storage-operator.4.5.0-202003181016   Succeeded

Comment 11 Nick Hale 2020-03-26 15:55:59 UTC
*** Bug 1817353 has been marked as a duplicate of this bug. ***

Comment 17 errata-xmlrpc 2020-05-13 21:52:32 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

Comment 18 Red Hat Bugzilla 2024-01-06 04:27:08 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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