Bug 1719791 - OLM installed operators are not getting new version numbers in the release pipeline
Summary: OLM installed operators are not getting new version numbers in the release pi...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Release
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Luke Meyer
QA Contact: Jian Zhang
URL:
Whiteboard: 4.1.5
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-12 14:48 UTC by Jessica Forrester
Modified: 2019-09-10 16:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1717627
Environment:
Last Closed: 2019-09-10 16:02:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jessica Forrester 2019-06-12 14:48:29 UTC
+++ This bug was initially created as a clone of Bug #1717627 +++

+++ This bug was initially created as a clone of Bug #1717623 +++

The ClusterServiceVersions for:
Template Service Broker Operator
Ansible Service Broker Operator
Cluster Logging Operator
ElasticSearch Operator

are not being automatically updated in the ART release pipeline with new version numbers, this means we would not be able to upgrade existing installed operators that went out with 4.1.0

Because the automation is not there we are manually updating the 4 operators to have a 4.1.1 version number.

See:
https://github.com/openshift/elasticsearch-operator/pull/151
https://github.com/openshift/template-service-broker-operator/pull/44
https://github.com/openshift/ansible-service-broker/pull/1226
https://github.com/openshift/cluster-logging-operator/pull/196

When these are merged we should be able to update from a 4.1.0 installed operator to the 4.1.1 version of the operator.

Note: this is a one-off fix for 4.1.1, we may have to do the same for 4.1.2 but we will be automating this as soon as possible.
++++++++++++++++++++

This is the cloned bug to cover making the same fixes for 4.1.2 if necessary, or if the automation is done to make any changes to support the automation.

--- Additional comment from Sudha Ponnaganti on 2019-06-11 13:11:35 UTC ---

One off fix need to be checked for 4.1.2 as well.

---------------



Continuing to track this for 4.1.3 since the automation work is in progress.

Comment 4 Jian Zhang 2019-07-01 08:42:57 UTC
Hi, Luke

What's the mapping relation between the cluster's and operator's version?
Could you give more details about this automation workflow? Thanks! Change status to ASSIGNED first.
I installed elasticsearch-operator in OCP 4.1.4, but its version is 4.1.2. See below:

mac:~ jianzhang$ oc get csv -n openshift-operators 
NAME                            DISPLAY                  VERSION   REPLACES   PHASE
elasticsearch-operator.v4.1.2   Elasticsearch Operator   4.1.2                Succeeded

mac:~ jianzhang$ oc get csv -n openshift-operators elasticsearch-operator.v4.1.2 -o yaml|grep name:
  name: elasticsearch-operator.v4.1.2
...

mac:~ jianzhang$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.1.4     True        False         6h11m   Cluster version is 4.1.4

The elasticsearch-operator version in Quay is "2.0.0", like below:
mac:~ jianzhang$  oc logs redhat-operators-75b6797585-dhp2j  -n openshift-marketplace |grep elastic
...
time="2019-07-01T02:17:43Z" level=info msg="decoded successfully" port=50051 repository="redhat-operators/elasticsearch-operator:2.0.0" type=appregistry

Comment 7 Luke Meyer 2019-08-01 04:24:20 UTC
(In reply to Jian Zhang from comment #4)

> What's the mapping relation between the cluster's and operator's version?
> Could you give more details about this automation workflow? Thanks! Change
> status to ASSIGNED first.
> I installed elasticsearch-operator in OCP 4.1.4, but its version is 4.1.2.

That was a problem with the process in earlier releases. The operator versions we ship now should match the cluster's version (although we've had problems getting the metadata published in the app registries).

I'm pretty sure this has been solved for the last month. Can you verify and we can just close this? (I don't see a need to include in advisory, don't think we ever actually shipped one with the wrong version in operator manifest)


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