Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@kafka.apache.org
Date: Wed, 2 Aug 2017 17:04:00 +0000 (UTC)
From: "Tom Bentley (JIRA)" <jira@apache.org>
To: jira@kafka.apache.org
Message-ID: <JIRA.13091941.1501692786000.75707.1501693440063@Atlassian.JIRA>
In-Reply-To: <JIRA.13091941.1501692786000@Atlassian.JIRA>
References: <JIRA.13091941.1501692786000@Atlassian.JIRA> <JIRA.13091941.1501692786974@jira-lw-us.apache.org>
Subject: [jira] [Commented] (KAFKA-5693) TopicCreationPolicy and
 AlterConfigsPolicy overlap
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 02 Aug 2017 17:04:04 -0000


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

Tom Bentley commented on KAFKA-5693:
------------------------------------

One (obvious) part solution to this is that the {{CreateTopicPolicy}} should be applied not just at topic creation, but also for every topic modification, whether it's a change to the topic configs or something else. Unless there's a valid use case for configuring changed topics differently to freshly created topics?

By symmetry, unless it's OK for a noop topic config change to be rejected by the {{AlterConfigPolicy}}, maybe the topic config supplied during topic creation should also be run through the {{AlterConfigPolicy}}. Again, maybe there are valid use cases for allowing a topic config at creation which would be disallowed in a later modification, but I can't think of any.


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