Allow enabling and disabling policy sources #544
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR builds on top of the approach taken in #525 but allows a more flexible way to define which policy sources should be enabled.
It introduces a new configuration block called
source
that can be placed within the existingpolicy
block. Currently this block takes only a label that specifies which source it controls and a boolean attribute to enable or disable it:Both
file
andnomad
sources are initially enabled by default, withfile
requiring thatpolicy -> dir
is also defined to be fully enabled, so everything remains backwards compatible.The CLI flag parsing is a bit different than others, and it special cases the existing policy sources. This seems fine to me, as all policy sources are internal and having CLI flags to disable them sounds pretty useful.
If no policy source is enabled, the Autoscaler agent will fail and exit, since it won't be able to do any work without policies. In the future, we may want to implement a full reload of policy sources via
SIGHUP
so that sources can be enabled/disabled dynamically.Possible future enhancements
This approach allows further customization of policy sources, such as moving the current
policy -> dir
into a newconfig
map inside thefile
source:With this, we could start supporting multiple configurations for the same policy source, such as reading policies from multiple paths:
Another possibility would be to start supporting external policy source plugins:
This pattern of disabling internal components via a
enabled
attribute could also be used for plugins:Closes #524