Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1719791

Summary:	OLM installed operators are not getting new version numbers in the release pipeline
Product:	OpenShift Container Platform	Reporter:	Jessica Forrester <jforrest>
Component:	Release	Assignee:	Luke Meyer <lmeyer>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jian Zhang <jiazha>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.1.z	CC:	aos-bugs, chezhang, chuo, jiazha, jokerman, lmeyer, mmccomas, sponnaga, tbielawa, vlaad, wsun
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	4.1.5
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1717627	Environment:
Last Closed:	2019-09-10 16:02:54 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:

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)