Hi Luke and Omnia, Thanks for the feedback on the payload size — you're both right.
Luke is correct that "10 KB < 18 KB" was not a real justification. The criterion isn't size, it's **usefulness**: a config the controller has no validator for can't be validated anyway, so shipping it is pure overhead. To address the size concern directly, we can make reporting **explicit opt-in**: a config is sent only when its author marks it as something the controller actually needs to validate. That keeps the payload to exactly "the configs we have a concrete controller-side validation for" — minimizing metadata-log overhead by construction. We start with only what the current validations (KAFKA-20544, KIP-1256, KIP-1294) need and add others one at a time as real validations land. This also answers Omnia's point about silent growth: nothing is reported by default, so the set only grows when someone *deliberately* marks a new config — which already goes through KIP/PR review. Does the opt-in approach address the size concern? If so I'll update the KIP to this selection and fix the framing. Thanks, TaiJuWu Omnia Ibrahim <[email protected]> 於 2026年6月16日週二 下午5:55寫道： > Hi TaiJuWu, > Thanks for the KIP! Same worry as Luke about the per-broker size > especially on large clusters. On top of that; this will keep growing as > brokers get more configs over time, so we’d need to keep checking the size > impact every time configs are added. > > Thanks > Omnia > > > On 15 Jun 2026, at 05:14, Luke Chen <[email protected]> wrote: > > > > Hi TaiJuWu, > > > > Thanks for the KIP. > > > > LC1: From the rejective alternative: > > "Reporting all non-sensitive configs (~388 entries, ~18 KB per broker) > was > > considered. While simpler in filtering logic, it includes 163 configs > that > > have no ConfigDef validator. The additional ~8 KB per broker adds up in > > large clusters (8 MB for 1000 brokers) with no practical benefit — > configs > > without validators cannot be validated regardless of whether they are > > reported. The chosen approach (only configs with validators, ~225 > entries, > > ~10 KB per broker) keeps the payload smaller and automatically expands > when > > new validators are added in future KIPs." > > > > So, ~ 10 KB per broker now, and in 1000 brokers cluster, it'll be 10MB > > metadata log increase, right? > > I'm not convinced that this is necessary after reading the KIP. > > If you think 18 KB per broker is "big", then I don't know why 10 KB per > > broker is acceptable? > > > > > > Thanks, > > Luke > > > > > > On Thu, Jun 4, 2026 at 4:34 PM TaiJu Wu <[email protected]> wrote: > > > >> Hi chia: > >> > >> Thanks for your feedback. > >> > >> chia_00: I have removed this section, we don't change ConfigDef and add > >> test plan to cover server-side filter helper. > >> chia_01: thanks for catching this, I have updated KIP. > >> chia_02: I added following description to this KIP. > >> If a broker reports an empty StaticConfigs, the controller should > reject > >> the registration and prevent the broker from joining the cluster by > >> returning *INVALID_REGISTRATION*. > >> > >> Thanks, > >> TaiJuWu > >> > >> > >> > >> Chia-Ping Tsai <[email protected]> 於 2026年6月1日週一 上午11:05寫道： > >> > >>> chia_2: should the controller reject the request which has empty static > >>> configs? > >>> > >>> On 2026/04/30 14:47:05 TaiJu Wu 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 > >>>> > >>> > >> > >
