Hi Jiunn-Yang, Thanks for your feedback.
JY0: If we want to allow describeConfig from controller, we need all static config including non-validator. Consider it will cause a lot of meta data overhead for large cluster so I don't have plan to do it. JY1: I have updated KIP. JY2: This scenario doesn't actually arise. An MV upgrade is gated on all brokers already supporting the target MV, and every binary upgrade restarts the broker — which sends a fresh BrokerRegistrationRequest with the new ConfigDef. So by the time KIP-1294's validation runs, every broker has re-registered against the new schema. The mixed-binary partial-view window is real but transient, and the controller has the new-schema value for some.config from all of them Best regard, TaiJuWu 黃竣陽 <[email protected]> 於 2026年5月2日週六 下午10:38寫道： > Hi TaiJu, > > Thanks for the KIP. > > JY0: Since the controller now holds brokers' static configs, are there any > plans to > allow the DescribeConfigs API to serve static config queries directly from > the > controller side? > > JY1: There's a typo in the KIP where RegisterBrokerRecord is misspelled as > BrokerRegerationRecord. > > JY2: Since the filtering rule is "include configs that have a Validator," > what happens > when a config gains a validator in a newer version? > For example, suppose some.config has no validator in 4.X but gains one in > 4.X+1. > 4.X brokers would not report it (since no validator exists). As a result, > the 4.X+1 controller > would have only a partial view. This can be problematic for downstream > KIP-1294, where the > controller must verify that all brokers satisfy a constraint before > allowing a MetadataVersion > upgrade. If some brokers never report the config, the controller may fail > to validate those > configs correctly. > > Best Regards, > Jiunn-Yang > > > > TaiJu Wu <[email protected]> 於 2026年5月2日 下午2:01 寫道： > > > > 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 > >>> > >> > >
