Hi Edoardo,
Thanks for the feedback and for pointing me back to KIP-170 and KIP-201.
I understand the concern. Adding deletedConfigs() and
configsWithoutNullValues() solves the immediate inconsistency, but it also
extends an interface whose request model still does not clearly distinguish:
- the operations explicitly requested by the client;- the configuration before
the request; and- the configuration that would exist after the request.
That leaves similar limitations for SET, APPEND, SUBTRACT, legacy AlterConfigs,
and future configuration operations.
Instead of adding more methods to the existing RequestMetadata, I’m open to
revising KIP-1382 around a new policy contract while leaving AlterConfigPolicy
unchanged for compatibility. The new request metadata could expose the
resource, request type, explicit operations, current configuration state, and
proposed configuration state. Explicit deletions would then be represented
naturally rather than inferred from null values or generated records.
I would prefer to keep this KIP focused on configuration alterations rather
than revive the full scope of KIP-201, which also covered topic creation,
deletion, reassignment, partition changes, and record deletion. However, the
new contract can be designed so it does not repeat the limitations identified
by KIP-201.
Would that focused successor to AlterConfigPolicy address your concern, or do
you think the KIP should cover the broader topic-management policy model as
well?
Thanks, Arnab
Thanks and regardsArnab Nandy
On Friday, 16 October 2026 at 09:13:23 pm IST, Edoardo Comar
<[email protected]> wrote:
Hi Arnab,
thanks for the KIP and for starting this discussion.
As I mentioned when we looked at your PR
https://github.com/apache/kafka/pull/23310#issuecomment-5805162526
There have ben previous attempts at improving the policies interfaces:
https://cwiki.apache.org/confluence/spaces/KAFKA/pages/71012345/KIP-170+Enhanced+TopicCreatePolicy+and+introduction+of+TopicDeletePolicy
https://cwiki.apache.org/confluence/spaces/KAFKA/pages/73637960/KIP-201+Rationalising+Policy+interfaces
Personally I think that adding methods to the current policy for
working around the inconsistency of the arguments isn't optimal.
We keep the limitations of the polices but with a wider interface that
we must support for backwards compatibility.
I would like to see a KIP expanding the capabilities of the policy
check, rather than just fixing the arguments for the different Alter
config operations.
Thanks,
Edo
On Fri, 16 Oct 2026 at 13:03, Arnab nandy via dev <[email protected]> wrote:
>
> Hi Team,
> I'd like to start a discussion about KIP-1382, proposes to expose explicit
> configuration deletions to AlterConfigPolicy.
> https://cwiki.apache.org/confluence/spaces/KAFKA/pages/451979367/KIP-1382+Expose+Explicit+Configuration+Deletions+to+AlterConfigPolicy
>
> Thanks and regardsArnab Nandy
