Activity log for bug #1830634

Date Who What changed Old value New value Message
2019-05-27 15:58:32 Brent Rowsell bug added bug
2019-05-27 15:58:50 Brent Rowsell tags stx.2.0 stx.config
2019-05-27 17:33:54 Ghada Khalil bug added subscriber Bill Zvonar
2019-05-27 17:33:57 Ghada Khalil starlingx: importance Undecided High
2019-05-27 17:34:00 Ghada Khalil starlingx: status New Triaged
2019-05-27 17:34:18 Ghada Khalil tags stx.2.0 stx.config stx.2.0 stx.config stx.containers
2019-05-27 17:35:09 Ghada Khalil starlingx: assignee David Sullivan (dsullivanwr)
2019-05-27 17:41:37 Brent Rowsell description Brief Description ----------------- isolcpu's does not play nice with besteffort or burstable pods. With isolcpu's enabled these pods will get stuck on the core where they were first scheduled vs floating. Overlaying exlusive cpu's with this, one can end up in a situation where the besteffort/burstable pods are running on the same cpu as the exclusive pods. There will always be some besteffort or burstable pods on a worker node as the system pods (calico et) fall into the category. Severity -------- Major Steps to Reproduce ------------------ Launch pods with exclusive CPU's Expected Behavior ------------------ Pods using defaultCpuSet should be able to float across that set Actual Behavior ---------------- See description Reproducibility --------------- 100% System Configuration -------------------- Low-latency worker Branch/Pull Time/Commit ----------------------- BUILD_DATE="2019-05-24 17:42:34 -0400" Last Pass --------- Never Timestamp/Logs -------------- N/A Test Activity ------------- Other Brief Description ----------------- isolcpu's does not play nice with besteffort or burstable pods. With isolcpu's enabled these pods will get stuck on the core where they were first scheduled vs floating. Overlaying exlusive cpu's with this, one can end up in a situation where the besteffort/burstable pods are running on the same cpu as the exclusive pods. There will always be some besteffort or burstable pods on a worker node as the system pods (calico et) fall into the category. So for worker nodes that do not have the openstack-compute label assigned we need to remove the isolcpu's boot arg. I believe the change would be at line 581 in platform.py plugin. Severity -------- Major Steps to Reproduce ------------------ Launch pods with exclusive CPU's Expected Behavior ------------------ Pods using defaultCpuSet should be able to float across that set Actual Behavior ---------------- See description Reproducibility --------------- 100% System Configuration -------------------- Low-latency worker Branch/Pull Time/Commit -----------------------  BUILD_DATE="2019-05-24 17:42:34 -0400" Last Pass --------- Never Timestamp/Logs -------------- N/A Test Activity ------------- Other
2019-05-28 17:16:02 OpenStack Infra starlingx: status Triaged In Progress
2019-05-28 20:59:03 OpenStack Infra starlingx: status In Progress Fix Released