Bug 1783007 - Scaling an ingresscontroller causes a rolling update
Summary: Scaling an ingresscontroller causes a rolling update
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Routing
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.4.0
Assignee: Miciah Dashiel Butler Masters
QA Contact: Hongan Li
URL:
Whiteboard:
Depends On:
Blocks: 1783009
TreeView+ depends on / blocked
 
Reported: 2019-12-12 19:29 UTC by Miciah Dashiel Butler Masters
Modified: 2020-05-13 21:55 UTC (History)
1 user (show)

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.
Clone Of:
: 1783009 (view as bug list)
Environment:
Last Closed: 2020-05-13 21:55:05 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cluster-ingress-operator pull 339 None closed Bug 1783007: Ignore spec.replicas in deployment hash 2020-04-27 20:45:44 UTC
Red Hat Product Errata RHBA-2020:0581 None None None 2020-05-13 21:55:06 UTC

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


Note You need to log in before you can comment on or make changes to this bug.