-
Notifications
You must be signed in to change notification settings - Fork 604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config
: add cluster configuration validation to redpanda
preload process
#25123
base: dev
Are you sure you want to change the base?
Conversation
is this related to #24987 ? |
…storage` To be able to use it in the `configuration` library (otherwise, a circular dependency is formed in the bazel BUILD).
e6a597d
to
66d3360
Compare
Yes, it is the idea I presented in my comment here: #24987 (comment) |
src/v/config/configuration.h
Outdated
@@ -772,4 +772,31 @@ bool development_feature_property<T>::development_features_enabled( | |||
|
|||
configuration& shard_local_cfg(); | |||
|
|||
// TODO: Move to anonymous namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This TODO is addressed in the later commit here: 116cb04
CI test resultstest results on build#62074
test results on build#62110
|
Requesting a review from an enterprise member as well 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks legit. just a few questions. nothing blocking i think
Moves the existing multi-property validation portion of the function from `admin/server.cc` into `config::configuration` as a static member function. The rest of the existing function which validate schema registry and admin endpoint users is left in `admin/server.cc`. This encapsulates the logic better, and also allows it to be re-used in other parts of the code which need to perform validation on cluster configs. Also, change in/out `std::map` parameters to a return struct, containing a `set` of properties that need to be unset in case of a bad configuration, as well as the `map` of properties and their corresponding errors.
To reject invalid configurations at start-up.
66d3360
to
5313abb
Compare
Force push to:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. i kinda feel like the whole exercise would be easier to make sense of if the first 4 commits were squashed into one, but that's just an aesthetic preference.
I'm still learning people's preferences on how commits should be split up 😅 will see if any other reviewers feel the same and I can edit the history from there. |
all good. totally your call at the end of the day 👍 |
Follow up to idea here: #24987 (comment)
There existed a
config_multi_property_validation()
function inadmin/server.cc
, the purpose of which was to validatethe cluster config AFTER all updates made via the admin endpoint had been applied.
The other location where changes to the cluster config can be made is externally, in the
config_cache.yaml
file.If a user were to modify this file with an invalid (per the rules of
config_multi_property_validation()
) configuration, it would not be caught until the next time the config was edited via the admin endpoint.This PR moves
config_multi_property_validation()
into the static member functionconfig::configuration::validate_config()
. It is still used inadmin/server.cc
, but now it is also used inconfig/config_manager.cc
to validate the cluster config set in the preload process.If any invalid properties are set, they are reset to their default values at start-up.
Backports Required
Release Notes
Improvements
redpanda
cluster configs by checking them at start-up.