Bug 2087685 - KASO should not be able to apply LowUpdateSlowReaction from Default WorkerLatencyProfile
Summary: KASO should not be able to apply LowUpdateSlowReaction from Default WorkerLat...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 4.11
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.11.0
Assignee: Swarup Ghosh
QA Contact: Weinan Liu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-18 08:55 UTC by Harshal Patil
Modified: 2022-08-10 11:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Rejection of extreme worker latency profile transition from/to Default <-> LowUpdateSlowReaction profile(s) through admission validation of nodes.config.openshift.io/v1/cluster object Reason: Operator(s) involved in updating the worker latency profile via Kubelet, Kube API Server and Kube Controller Manager on the cluster should not allow transition to/from Default <-> LowUpdateSlowReaction latency profiles as that could destabilize the cluster during transition. Result: Users cannot update the latency profile to and fro between extreme profiles on the config node object supported via resource validation admission.
Clone Of:
Environment:
Last Closed: 2022-08-10 11:12:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift kubernetes pull 1287 0 None open Bug 2087685: Worker Latency Profiles: Config node object validation for extreme profile transition 2022-06-07 06:18:59 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 11:13:11 UTC

Description Harshal Patil 2022-05-18 08:55:28 UTC 
During the testing with the latest nightly it appears that Kube API Server Operator is able to apply LowUpdateSlowReaction even though the cluster is at Default WorkerLatencyProfile. 


This violates the cluster stability analysis [1]. Transition from Default to LowUpdateSlowReaction and vice-versa should be prohibited. 


[1] https://github.com/openshift/enhancements/blob/master/enhancements/worker-latency-profile/worker-latency-profile.md#default---lowupdateslowreaction
Comment 1 Swarup Ghosh 2022-06-14 11:11:02 UTC 
The fix is merged through https://github.com/openshift/kubernetes/pull/1287. 
So essentially OpenShift/k8s API Server admission will reject any updates on the nodes.config.openshift.io/cluster object to/from Default <-> LowUpdateSlowReaction worker latency profile on the cluster, thus user will not be able to directly jump extreme profiles which helps favour cluster stability as described above. 

If users want to set LowUpdateSlowReaction profile for their cluster they should either do it at Day-0 or transition Default -> MediumUpdateAverageReaction -> LowUpdateSlowReaction in succession.
Comment 7 errata-xmlrpc 2022-08-10 11:12: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 (Important: OpenShift Container Platform 4.11.0 bug fix and security 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-2022:5069
Note You need to log in before you can comment on or make changes to this bug.