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

Bug 1783009

Summary: [4.3] Scaling an ingresscontroller causes a rolling update
Product: OpenShift Container Platform Reporter: Miciah Dashiel Butler Masters <mmasters>
Component: NetworkingAssignee: Miciah Dashiel Butler Masters <mmasters>
Networking sub component: router QA Contact: Hongan Li <hongli>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: high CC: aos-bugs, dmace, hongli
Version: 4.4   
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: 1783007 Environment:
Last Closed: 2020-01-23 11:18:56 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:
Bug Depends On: 1783007    
Bug Blocks:    

Description Miciah Dashiel Butler Masters 2019-12-12 19:38:03 UTC 
+++ This bug was initially created as a clone of Bug #1783007 +++

Description of problem:

The ingress operator computes a hash value for the deployment for an ingress controller and uses this hash value in the pod template spec's labels and affinity policy.  This hash value includes the deployment's spec.replicas field, which is copied from the same field on the ingresscontroller, which means that scaling the ingresscontroller causes a rolling update of the deployment.  This rolling update is unnecessary and should not happen.



Version-Release number of selected component (if applicable):

The deployment hashing is added in 4.3.


How reproducible:

The behavior is deterministic.


Steps to Reproduce:
1. Scale an ingresscontroller: `oc -n openshift-ingress-operator scale ingresscontroller/default --replicas=3`


Actual results:

The ingresscontroller's deployment performs a rolling update (i.e., it scales up a new replicaset and scales down the old one).


Expected results:

Scaling the ingresscontroller should not trigger a rolling update (i.e., the existing replicaset should scale up or down, and the deployment should not create a new replicaset).


Additional info:

https://github.com/openshift/cluster-ingress-operator/pull/280/commits/0f6fd1c67dd719508c33e475ebda3f6e47052501 added the deployment hashing logic.
Comment 2 Hongan Li 2019-12-16 02:35:11 UTC 
verified with 4.3.0-0.nightly-2019-12-13-180405 and issue has been fixed.

$ oc get rs -n openshift-ingress
NAME                        DESIRED   CURRENT   READY   AGE
router-default-85dc747cd8   2         2         2       46m

$ oc scale ingresscontrollers.operator.openshift.io/default --replicas=1 -n openshift-ingress-operator
ingresscontroller.operator.openshift.io/default scaled

$ oc get rs -n openshift-ingress
NAME                        DESIRED   CURRENT   READY   AGE
router-default-85dc747cd8   1         1         1       47m
Comment 4 errata-xmlrpc 2020-01-23 11:18:56 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