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 >>> >>
