kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Bentley (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (KAFKA-5693) TopicCreationPolicy and AlterConfigsPolicy overlap
Date Mon, 25 Sep 2017 10:27:00 GMT

    [ 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)

Mime
View raw message