...

We propose updating RegisterBrokerRecord to Version 5. This version introduces a new tagged field StaticConfigs, which is a collection of BrokerStaticConfig objects. This allows the Controller to persist the broker's reported static settings directly within the metadata log.

BrokerRegerationRecord.json

...

Proposed Changes

Broker side

sendBrokerRegistration() is updated to collect non-sensitive static configuration entries from KafkaConfig and include them in the request when the negotiated protocol version is 6 or above.

...

Only configurations that have a validator defined in ConfigDef are included. This naturally excludes most security/SSL/SASL configs (which have no ConfigDef validator and rely on their own validation paths), as well as string/boolean configs that only have type checking. Sensitive configurations (ConfigDef.Type.PASSWORD) are also excluded.

Controller side

When receiving a BrokerRegistrationRequest v6 and the current MetadataVersion supports static configs, the controller copies the StaticConfigs field into the RegisterBrokerRecord.

...

Unit test , integration test to cover this new feature.

Rejected Alternatives

...

• Only report configs with non-default values - During a rolling upgrade, different brokers may be running different Kafka versions with different defaults for the same config. A broker running an older version may omit a config because it matches its own default, but that default may differ from the controller's version. The controller cannot reliably fill in the "correct" default because it only knows its own version's defaults, not the defaults of every broker version in the cluster.

• Report all non-sensitive config - 

  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.