...

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: DraftUNDER DISCUSS

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: here [Change the link from KAFKA-1 to your own ticket]

...

1. Broker static reporting: Brokers report their static (non-sensitive) configurations to the controller during registration. This enables the controller to perform pre-flight validation of static configs during metadata version upgrades. On the broker side, BrokerLifecycleManager is responsible for collecting and sending static configs. During registration, it iterates  over all config entries need to be validated.

2. Metadata-Version-Aware Validators: Configuration definitions are enhanced to support metadata-version-aware validators. The ConfigDef.define() method accepts a mvValidators parameter — Uses NavigableMap.floorEntry() to find the validator registered at the highest feature level ≤ the given featureLevel. This allows  constraints to be introduced incrementally across metadata versions.

   1. When an administrator runs kafka-storage format --release-version <version>, the tool now validates the broker's static configs from  server.properties against the MV constraints of the specified release version. If any config violates the constraints, the format command fails with a descriptive error before writing any data to disk.
   2. During AlterConfigs and IncrementalAlterConfigs operations, the Metadata-Version-Aware validators will be invoked to ensure that any proposed changes are compliant with the cluster's current metadata version. Any configuration During AlterConfigs and IncrementalAlterConfigs operations, the Metadata-Version-Aware validators will be invoked to ensure that any proposed changes are compliant with the cluster's current metadata version. Any configuration that fails this runtime validation will be rejected with an INVALID_CONFIG error.
   3. When an administrator performs a metadata.version upgrade or downgrade, the Controller will execute a comprehensive audit of all existing configurations—both static (via BrokerRegistrationRecord) and dynamic (via ConfigRecord). The transition will only proceed if all current settings satisfy the constraints of the target metadata version, ensuring a safe and atomic version migration.When an administrator runs kafka-storage format --release-version <version>, the tool now validates the broker's static configs from  server.properties against the MV constraints of the specified release version. If any config violates the constraints, the format command fails with a descriptive error before writing any data to disk

Example:

Suppose IBP_4_4_IV1 raises the minimum allowed value for log.segment.bytes from 1 byte to 3 MB. This constraint is registered as an MV-aware validator on the log.segment.bytes config key. Because log.segment.bytes now has an MV validator, it will be included in the static config payload that brokers send to the controller during registration.

1. Format time:  An administrator prepares a new broker with log.segment.bytes=1024 in server.properties and runs kafka-storage format --release-version 4.4. Before writing any data to disk, the tool validates the static configs against the constraints of IBP_4_4_IV1 and finds that log.segment.bytes=1024 violates the minimum of 3 MB. The command fails with a descriptive error, prompting the administrator to fix server.properties before retrying.
2. AlterConfigs at runtime: Once the cluster is running at IBP_4_4_IV1, an administrator attempts to set log.segment.bytes=1024 on a topic via AlterConfigs. The controller validates the proposed value against the current MV's constraints and immediately rejects the request with an INVALID_CONFIG error before any change is persisted.
3. Metadata version upgrade: A cluster is running at IBP_4_3_IV0, where brokers do not yet report static configs to the controller, leaving it with no visibility into each broker's server.properties. Broker node-3 has log.segment.bytes=2048 in its server.properties, but the controller is unaware of this. As the administrator performs a rolling binary upgrade, each restarted broker begins sending StaticConfigs in  BrokerRegistrationRequest version 6; since log.segment.bytes now has an MV validator registered, it is included in the payload and stored by the controller in memory even while the cluster is still at  IBP_4_3_IV0. When the administrator then requests an upgrade to IBP_4_4_IV1 — the version that simultaneously introduces static config reporting and the new log.segment.bytes minimum constraint — the  controller performs a pre-flight audit using the reported static configs and finds that node-3's log.segment.bytes=2048 violates the new minimum of 3 MB. The upgrade is rejected with a descriptive error identifying the broker and the offending value. Since the cluster is still at IBP_4_3_IV0 and fully operational, the administrator can issue an AlterConfigs request to set a cluster-wide dynamic override for log.segment.bytes to a compliant value, which takes precedence over the static value in server.properties without requiring any file editing or broker restart. The administrator then retries the upgrade, the pre-flight audit finds all effective configs compliant, and the upgrade proceeds successfully.

Public Interfaces

ConfigDef

...