...

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. 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. Topic payments has a long-standing dynamic override of log.segment.bytes=1024. , 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 also has has log.segment.bytes=2048 in its server.properties; since log.segment.bytes has an MV validator, this value was reported to the controller during registration and persisted in the metadata log. When the administrator requests an upgrade to IBP_4_4_IV1, the controller audits all effective configs — both dynamic overrides and the static configs reported by each broker — and finds two violations. The upgrade is rejected with a descriptive error listing both  the topic and the broker. The administrator fixes both values and retries, at which point , 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.

...