Closed camaeel closed 1 month ago
Hi @camaeel, Thank you for rising this issue. Currently there is no logic to handle multiple StartupCPUBoosts targeting same PODs - for a given pod the first matching boost is used. Having overlapping StartupCPUBoosts is undesired situation IMO and I would avoid it via validation. For a namespace wide StartupCPUBoost I would introduce separate resource with an ordering like: StartupCPUBoost --no match -> NamespaceStartupCPUBoost --nomatch -> ClusterStartupCPUBoost (as requested in #55 )
An alternative approach would be to allow for overlapping StartupCPUBoost objects and to introduce some sort of priority attribute. This would introduce unnecessary complexity IMO and I don't clearly see any use case for this. Feel free to share your opinion as well.
Thank you for clarification.
What will be the behaviour of this tool if multiple StartupCPUBoost resources target the same pod? For example I could set a namespace default StartupCPUBoost without any selectors and the for some of deployments I would need to set it to bigger increases.