Bug 1764017

Summary:	The CVO wrongly makes an API server update call and return modified true
Product:	OpenShift Container Platform	Reporter:	Alberto <agarcial>
Component:	Cluster Version Operator	Assignee:	Abhinav Dahiya <adahiya>
Status:	CLOSED ERRATA	QA Contact:	sheng.lao <shlao>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.3.0	CC:	aos-bugs, jokerman, shlao
Target Milestone:	---
Target Release:	4.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-23 11:08:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alberto 2019-10-22 07:29:52 UTC

Description of problem:
The CVO wrongly makes an API server update call and return modified true when comparing replicas number

Version-Release number of the following components:
rpm -q openshift-ansible
rpm -q ansible
ansible --version

How reproducible:

Steps to Reproduce:
Use the ensureDeployment func from CVO library and see it return modified for identical manifests with same replica number.

Actual results:
The CVO does an update call to reconcile deployment manifest and return modified=true

Expected results:
The CVO does not do the update call and return modified=false

Additional info:

Comment 1 Alberto 2019-10-22 07:31:00 UTC

https://github.com/openshift/cluster-version-operator/pull/256

Comment 2 sheng.lao 2019-10-23 10:32:11 UTC

It's easy to understand from go syntax that comparing pointers' address is wrong while we want to compare values pointed by pointers.

But, how to create such env that EnsureDeployment doesn't work well?

Comment 4 sheng.lao 2019-10-24 15:54:34 UTC

It is difficult for QE to reproduce the error, I run cmd `go test` under directory `lib/resourcemerge/`. It is passed

then I upgrade cluster from 4.3.0-0.nightly-2019-10-24-110808 to 4.3.0-0.nightly-2019-10-24-122524, it works too.

# oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.3.0-0.nightly-2019-10-24-110808   True        True          15s     Working towards 4.3.0-0.nightly-2019-10-24-122524: downloading update

# oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.3.0-0.nightly-2019-10-24-122524   True        False         20m     Cluster version is 4.3.0-0.nightly-2019-10-24-122524

# sh check_cluster_health.sh 4.3.0-0.nightly-2019-10-24-122524
Passed

Comment 6 errata-xmlrpc 2020-01-23 11:08:30 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:0062