...

This current context only enables a very limited type of validations (e.g. config x  cannot not be y ), 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 further, having some policies available only on creation but not when altering means the effort put to validate on creation is wasted on later changes.

If The purpose of this KIP is accepted, plugin implementations should be able to apply to allow the same policies on incremental alter configs, considering all resulting configurations (similar to topic creation and on alter config timepolicies, and; to some extend; to legacy alter configs).

There has been related KIPs that included this proposal:

...

• resultingConfigs  includes the altered configurations: existing and proposed configurations merged.
• proposedConfigs includes the requested configurations, including null or empty values when configuration is requested to be deleted.

For users using (legacy) alter configurations:

• They can still rely on proposed configs field to include all configurations.

For users using incremental alter configurations:

• They can use the new resulting configs field to apply the same policies as when creating topics or legacy alter configs.

Proposed Changes

Enable Managers to use the new property:

...

Existing policy implementations should not be safeaffected, as new attribute won't be expected. New policy implementations will have to be deployed on brokers running newer versions including existing configurations.

...