Hi Muralidhar Basani,
Thanks for your feedback.
mb-0:
Importance and "should be sent to the controller" are two unrelated
concerns. A HIGH-importance label means operators
should pay attention to a value; it has nothing to do with whether the
controller needs to know it. The criterion for
inclusion is whether the controller can validate the value — i.e.,
whether the config has a validator. A config
without a validator gives the controller nothing to enforce, so sending
its value would just bloat the metadata log
with data the controller cannot act on.
Under this rule, your three examples are internally consistent:
- replica.fetch.min.bytes — no validator → excluded
- replica.fetch.max.bytes — has atLeast(0) validator → included
- replica.lag.time.max.ms — no validator → excluded
The cases that look surprising — HIGH-importance configs that lack
validators — are a Kafka codebase issue: those
configs should have validators added, after which this KIP picks them up
automatically with no further code change.
That cleanup is independent of this KIP.
mb-1:
The inclusion rule should track the actual signal we care about: "the
controller can run the same validator the broker
runs." Validator presence captures that signal directly; an opt-in flag
does not. With explicit opt-in, the
wire-level set drifts away from that signal — configs that gain a
validator stay excluded until someone remembers to
flip a flag, and configs without validators can be opted in despite the
controller having nothing to enforce on them.
The maintenance overhead of tagging every config is a real cost on top,
but the bigger issue is the misalignment.
Your underlying concern about silent inclusion when a future PR adds a
validator to an ssl.* config is
legitimate. I'll add a two-state policy on ConfigKey:
enum ControllerReportPolicy { DEFAULT, NEVER }
NEVER guarantees the config is never reported, regardless of validator
presence or future filter changes. Plus a
defineSecurity(...) overload that fixes the policy at NEVER:
.defineSecurity(SslConfigs.SSL_KEYSTORE_PASSWORD_CONFIG, PASSWORD, null,
MEDIUM, SslConfigs.SSL_KEYSTORE_PASSWORD_DOC)
All SSL/SASL/PASSWORD entries in BrokerSecurityConfigs move to
defineSecurity, including ssl.client.auth.
mb-2:
Thanks for catching this, I will update KIP to according mb-1, hope it
can answer this question.
Best regards,
TaiJuWu
Muralidhar Basani via dev <[email protected]> 於 2026年5月1日週五 上午1:08寫道：
> Hi TaiJuWu,
>
> Thanks for the kip. I have a few thoughts below.
>
> mb-0 : I have gone through the rejected alternatives. If only configs which
> have validator are included, there are several configs which don't have a
> validator, true.
>
> For ex :
> replica.fetch.min.bytes has no validator (excluded)
> replica.fetch.max.bytes has a validator (included)
> replica.lag.time.max.ms has no validator, (excluded but HIGH importance)
>
> There are many examples like these. thinking what exactly controller needs
> to check or what could be the deciding factor for the config to be part of
> BrokerRegistrationRecord?
>
> mb-1 : If an author today adds a validator to an existing config, it
> silently ends up in controller. How about an opt-in flag
> (sendToController)?
> Many configs like ssl.* and sasl.* have no validator and they are excluded
> which is good. But if a future pr changes them like adding NonEmptyString,
> will end up in controller.
>
> mb-2 : Config like SSL_CLIENT_AUTH_CONFIG = "ssl.client.auth" have a
> validator. It is a BrokerSecurityConfig. I am not sure if it's considered
> into the push record? But kip mentions ... "this naturally excludes most
> security/SSL/SASL configs.". Thought of clarifying.
>
> Thanks,
> Murali
>
> On Thu, Apr 30, 2026 at 4:48 PM TaiJu Wu <[email protected]> wrote:
>
> > Hi all,
> >
> > I would like to discuss KIP-1326
> > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1326%3A+Include+broker+static+configurations+in+BrokerRegistrationRequest
> > >
> > which
> > proposes that brokers report a subset of their static configuration
> values
> > to the controller as part of BrokerRegistrationRequest.
> >
> > WIKI:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1326%3A+Include+broker+static+configurations+in+BrokerRegistrationRequest
> >
> > Best,
> > TaiJuWu
> >
>
