[ 
https://issues.apache.org/jira/browse/KAFKA-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16163291#comment-16163291
 ] 

Tom Bentley edited comment on KAFKA-5693 at 9/25/17 10:26 AM:
--------------------------------------------------------------

Some of KIP-179 subsequently got split into KIP-195 and applying the 
{{TopicCreationPolicy}} to the addition of partitions to a topic was mentioned 
in the KIP-195 [DISCUSS] thread. 

[~ijuma] said:

bq. About using the create topics policy, I'm not sure. Aside from the naming 
issue, there's also the problem that the policy doesn't know if a creation or 
update is taking place. This matters because one may not want to allow the 
number of partitions to be changed after creation as it affects the semantics 
if keys are used. One option is to introduce a new interface that can be used 
by create, alter and delete with a new config. And deprecate CreateTopicPolicy. 

Additionally KAFKA-5497/KIP-170 proposes to add a {{DeleteTopicPolicy}}. 

At this point the problem isn't so much that the TopicCreationPolicy and 
AlterConfigsPolicy overlap, it's that we're in danger of having a number of 
policies which overlap and are generally inconsistent.


was (Author: tombentley):
Some of KIP-179 subsequently got split into KIP-195 and applying the 
{{TopicCreationPolicy}} to the addition of partitions to a topic was mentioned 
in the KIP-195 [DISCUSS] thread. 

[~ijuma] said:

bq. About using the create topics policy, I'm not sure. Aside from the
naming issue, there's also the problem that the policy doesn't know if a
creation or update is taking place. This matters because one may not want
to allow the number of partitions to be changed after creation as it
affects the semantics if keys are used. One option is to introduce a new
interface that can be used by create, alter and delete with a new config.
And deprecate CreateTopicPolicy. 

Additionally KAFKA-5497/KIP-170 proposes to add a {{DeleteTopicPolicy}}. 

At this point the problem isn't so much that the TopicCreationPolicy and 
AlterConfigsPolicy overlap, it's that we're in danger of having a number of 
policies which overlap and are generally inconsistent.

> TopicCreationPolicy and AlterConfigsPolicy overlap
> --------------------------------------------------
>
>                 Key: KAFKA-5693
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5693
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Tom Bentley
>            Priority: Minor
>
> The administrator of a cluster can configure a {{CreateTopicPolicy}}, which 
> has access to the topic configs as well as other metadata to make its 
> decision about whether a topic creation is allowed. Thus in theory the 
> decision could be based on a combination of of the replication factor, and 
> the topic configs, for example. 
> Separately there is an AlterConfigPolicy, which only has access to the 
> configs (and can apply to configurable entities other than just topics).
> There are potential issues with this. For example although the 
> CreateTopicPolicy is checked at creation time, it's not checked for any later 
> alterations to the topic config. So policies which depend on both the topic 
> configs and other topic metadata could be worked around by changing the 
> configs after creation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to