Current state: "retired" - superseded by KIP-201: Rationalising Policy interfaces
Discussion thread: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
As stated in KIP-108, the operators of a Kafka cluster need to validate users' self-service topic creation and deletion.
In the case of IBM MessageHub we found that the decision about permitting a topic creation requires more information than just whether the request metadata falls within acceptable boundaries.
We also needed to validate that against the current amount of resources already used in the cluster (eg number of partitions).
We also found that the action of deleting a topic had to be validated against the topic being in use by other services/applications.
This last point has the implicit assumption that such usages can be easily checked against a registry of some sort.
This KIP proposes to extend KIP-108 with :
- Provide the Create Topic Policy with a convenient API for querying the cluster topics' metadata
- Introduce a Delete Topic Policy
- A newer DeleteTopicRequest protocol message version that can include a boolean for verification only
- A newer DeleteTopicResponse message version that can include an error message to be returned to the user
The initial interface proposed for querying the cluster metadata has intentionally been kept with somewhat narrow capabilities (what MessageHub actually required)
rather than being provided with speculative generality. We await major community feedback on this point.
The Delete policy we had to implement had no requirements on querying cluster metadata, but it should be easy to make it similar to the Create interface
New Java interfaces in the client project corresponding to pluggable policies :
New configuration in
delete.topic.policy.class.name : The delete topic policy class that should be used for validation. The class should implement the
New versions of DeleteTopicRequest/DeleteTopicResponse protocol messages:
kafka.server.AdminManager will be enhanced
- to instantiate a TopicDeletePolicy - in a similar fashion as what it currently does for the topic creation
- to invoke the valdate method of TopicDeletePolicy when handing a request to delete topics
- to skip performing the actual deletion (via
AdminUtils.deleteTopic) if the request is for validate only
- check if a topic creation policy implements
CreateTopicPolicyV2and in that case set a
CreateTopicPolicyV2.TopicPartitionMetadataProvideron the policy
The TopicPartitionMetadataProvider interface could be implemented by the kafka.server.AdminManager itself or by another class, depending on how rich the Provider interface will turn out to be.
For the initial proposal, both provider methods
Map<String, Integer> topicsPartitionCount();
boolean isTopicMarkedForDeletion(String topicName);
can be easily implemented by
The metadata itself can be retrieved by enhancing the
MetadataCache held by the
Compatibility, Deprecation, and Migration Plan
- What impact (if any) will there be on existing users?
- If we are changing behavior how will we phase out the older behavior?
- If we need special migration tools, describe them here.
- Not needed
- When will we remove the existing behavior?
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.