Bug 1783007

Summary: 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: unspecified    
Priority: unspecified CC: aos-bugs
Version: 4.4   
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: In order to configure affinity policy and detect when an IngressController's Deployment needs to be updated, the ingress operator computes a hash value from the IngressController's Deployment and uses this hash value in the Deployment's pod template spec. This hash value included the Deployment's spec.replicas field, which is copied from the same field on the corresponding IngressController. Consequence: Scaling an IngressController would cause an unnecessary rolling update of its Deployment. Fix: The ingress operator now ignores the Deployment's spec.replicas field when computing the Deployment's hash. Result: Scaling an IngressController no longer causes a rolling update of the corresponding Deployment.
 Story Points: ---
Clone Of:
: 1783009 (view as bug list) Environment:
Last Closed: 2020-05-13 21:55:05 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:
Bug Depends On:    
Bug Blocks: 1783009    

Description Miciah Dashiel Butler Masters 2019-12-12 19:29:41 UTC 
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-23 03:20:46 UTC 
verified with 4.4.0-0.nightly-2019-12-20-210709 and issue has been fixed.

$ oc get rs -n openshift-ingress
NAME                        DESIRED   CURRENT   READY   AGE
router-default-568c75cc44   2         2         2       49m

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

$ oc get rs -n openshift-ingress
NAME                        DESIRED   CURRENT   READY   AGE
router-default-568c75cc44   1         1         1       50m
Comment 4 errata-xmlrpc 2020-05-13 21:55:05 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:0581