You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Karpenter's settings.SettingsStore currently updates at runtime to avoid having to restart the controller on any settings changes. This tracking has become difficult to manage and creates some development burden on the controller developer to handle constant requeueing while a given feature flag isn't enabled so that the controller can properly begin to react when a feature is enabled.
Rather than handle the burden of having to deal with this constant requeueing, it would be simpler to just restart the container when the settings change, meaning that settings can be assumed to be consistent for the lifetime of the process.
This is a consistent pattern throughout the Kubernetes community, where changes to configuration that are not bound to be particularly frequent require a pod restart.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Take away burden from the controller developer to handle runtime changes in Karpenter's settings.
Are you currently working around this issue?
Yes, we are having to do a constant requeue inside of controllers that use feature-flags.
Additional Context
No response
Attachments
No response
Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
The text was updated successfully, but these errors were encountered:
Tell us about your request
Karpenter's
settings.SettingsStore
currently updates at runtime to avoid having to restart the controller on any settings changes. This tracking has become difficult to manage and creates some development burden on the controller developer to handle constant requeueing while a given feature flag isn't enabled so that the controller can properly begin to react when a feature is enabled.Rather than handle the burden of having to deal with this constant requeueing, it would be simpler to just restart the container when the settings change, meaning that settings can be assumed to be consistent for the lifetime of the process.
This is a consistent pattern throughout the Kubernetes community, where changes to configuration that are not bound to be particularly frequent require a pod restart.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Take away burden from the controller developer to handle runtime changes in Karpenter's settings.
Are you currently working around this issue?
Yes, we are having to do a constant requeue inside of controllers that use feature-flags.
Additional Context
No response
Attachments
No response
Community Note
The text was updated successfully, but these errors were encountered: