Bug 1783009 - [4.3] Scaling an ingresscontroller causes a rolling update
Summary: [4.3] Scaling an ingresscontroller causes a rolling update
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Routing
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.3.0
Assignee: Miciah Dashiel Butler Masters
QA Contact: Hongan Li
Depends On: 1783007
TreeView+ depends on / blocked
Reported: 2019-12-12 19:38 UTC by Miciah Dashiel Butler Masters
Modified: 2020-01-23 11:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1783007
Last Closed: 2020-01-23 11:18:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-ingress-operator pull 341 0 None None None 2019-12-13 12:25:56 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:19:14 UTC

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.


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