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

Reply via email to