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

Bug 1904501

Summary:	[Descheduler] descheduler does not evict any pod when PodTopologySpreadConstraint strategy is set
Product:	OpenShift Container Platform	Reporter:	RamaKasturi <knarra>
Component:	kube-scheduler	Assignee:	Mike Dame <mdame>
Status:	CLOSED ERRATA	QA Contact:	RamaKasturi <knarra>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.7	CC:	aos-bugs, maszulik, mfojtik
Target Milestone:	---	Keywords:	UpcomingSprint
Target Release:	4.7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-02-24 15:37:53 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:

Description RamaKasturi 2020-12-04 16:05:20 UTC

Description of problem:
Descheduler does not evict any pod when PodTopologySpreadConstraint strategy is set


Version-Release number of selected component (if applicable):
clusterkubedescheduleroperator.4.7.0-202012031911.p0

How reproducible:
Always

Steps to Reproduce:
1. Install latest 4.7 cluster, install descheduler
2. Enable profile TopologyAndDuplicates
3. label two nodes with zone=zoneA & zone=zoneB respectively
3. Now create 3 pods on one node and one pod on another node

Actual results:
Descheduler does not evict anypod

Expected results:
Descheduler should evict pods to get 2 = 2, i.e 2 pods on one node another 2 pods on second node.

Additional info:
o it works for me to run the descheduler without the operator, but with the operator it doesn’t evict anything. The only difference is that we’re passing in a list of excluded namespaces in the operator, so I think this line might be breaking it: https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/strategies/topologyspreadconstraint.go#L113
in this case includedNamespaces is empty, so it won’t have the namespace… but included+excluded is >0 since we’re passing a list of excluded namespaces. So this is skipping every namespace

Comment 2 RamaKasturi 2020-12-07 16:56:03 UTC

Verified bug with payload below and i see that pods get evicted when PodTopologySpreadConstraint is enabled.

[knarra@knarra openshift-client-linux-4.7.0-0.nightly-2020-12-04-013308]$ ./oc get csv
NAME                                                   DISPLAY                            VERSION                 REPLACES   PHASE
clusterkubedescheduleroperator.4.7.0-202012050255.p0   Kube Descheduler Operator          4.7.0-202012050255.p0              Succeeded

[knarra@knarra openshift-client-linux-4.7.0-0.nightly-2020-12-04-013308]$ ./oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.7.0-0.nightly-2020-12-04-013308   True        False         13h     Cluster version is 4.7.0-0.nightly-2020-12-04-013308

registry.redhat.io/openshift4/ose-descheduler@sha256:1da501059d77a6fa72e6d10b0b1a7a0cc50f2abdffa07daef742b77c889964ea
registry.redhat.io/openshift4/ose-cluster-kube-descheduler-operator@sha256:3585a22428dd6fb2cd3b363667b134e1374dd250a6bc381ff665003e9a303381

I1207 16:37:54.002204       1 topologyspreadconstraint.go:109] "Processing namespaces for topology spread constraints"
I1207 16:37:54.102887       1 evictions.go:117] "Evicted pod" pod="knarra/mypod2h5l2k" reason=" (PodTopologySpread)"
I1207 16:37:54.117557       1 evictions.go:117] "Evicted pod" pod="knarra/mypod2d67q5" reason=" (PodTopologySpread)"

Based on the above moving bug to verified state.

Comment 5 errata-xmlrpc 2021-02-24 15:37:53 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 (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), 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/RHSA-2020:5633