Bug 1848783

Summary: Changes to probe fields in operator manifests are not applied during upgrade
Product: OpenShift Container Platform Reporter: OpenShift BugZilla Robot <openshift-bugzilla-robot>
Component: Cluster Version OperatorAssignee: Dan Mace <dmace>
Status: CLOSED ERRATA QA Contact: ge liu <geliu>
Severity: high Docs Contact:
Priority: medium    
Version: 4.5CC: aos-bugs, jokerman, lmohanty, wking
Target Milestone: ---   
Target Release: 4.4.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The cluster-version operator ignored several probe properties, including timeoutSeconds. Consequence: Operators which changed their release manifest s to adjust those properties did not get the changes applied to clusters on updating to the new release image. Fix: The cluster-version operator now applies these probe properties. Result: The cluster-version operator ensures that the in-cluster probe state matches the requested state from the operator's release manifests.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-14 01:43:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1848729    
Bug Blocks:    

Description OpenShift BugZilla Robot 2020-06-19 00:13:22 UTC
+++ This bug was initially created as a clone of Bug #1848729 +++

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

Description of problem:

Changing the readiness or liveness probe integer fields (initialDelaySeconds, periodSeconds, failureThreshold, and timeoutSeconds) of an operator deployment manifest aren't being applied to operator deployment resources during upgrades.

How reproducible:

Commit new probe timeout values for a CVO-managed operator, e.g. https://github.com/openshift/machine-config-operator/pull/1818.

Actual results:

On a new installation, the correct values are applied; but when performing a Y or Z upgrade to the new commit, the new values are not applied to the deployment.

Expected results:

The new values should be applied during an upgrade.

--- Additional comment from dmace@redhat.com on 2020-06-16 18:56:44 UTC ---

This blocks a fix for quorum-guard which involves changing probe timeout values (https://bugzilla.redhat.com/show_bug.cgi?id=1829923).

Comment 1 Lalatendu Mohanty 2020-06-22 11:41:19 UTC
We do not have time to fix the bug in this sprint as we are working on higher priority bugs and features.  Hence we are adding UpcomingSprint now, and we'll revisit this in the next sprint.

Comment 2 Dan Mace 2020-06-22 11:49:46 UTC
*** Bug 1849619 has been marked as a duplicate of this bug. ***

Comment 3 Dan Mace 2020-06-22 11:51:35 UTC
Opened https://github.com/openshift/cluster-version-operator/pull/391 for this

Comment 9 errata-xmlrpc 2020-07-14 01:43:52 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:2871