Page History

...

KIP-133 introduced AlterConfigPolicy  to enforce validations when requesting configuration changes for Kafka entities (e.g. Topics), similar to how KIP-108 introduced policies for Topic creation.

These 2 policies differ on the following: CreateTopicPolicy  includes all configurations, which allow validations between related configurations; but AlterConfigPolicy  only includes the configuration passed on the request, but not the existing configurations or configurations to delete.

At that time, the AlterConfigs  API included all the configurations to be applied (usually after gathering all the current configurations first using DescribeConfigs  call). This has changed after KIP-339 was introduced. With IncrementalAlterConfigs , only configurations to be changed are including to the request and changes are calculated on the broker-side.

This current context only enables This force users to a very limited type of validation validations (e.g. config x  cannot not be y ), when while most important validations have a dependency between configurations (e.g. if value of a=b  and c=d  then x  cannot be y ). Even morefurther, having these configuration some policies available only on creation , but not on alter when altering means the effort put to validate on creation is wasted when alteringon later changes.

If this KIP is accepted, plugin implementations should be able to apply the same policies on creation and on alter config time.

...