Updating the discussion with the latest comments.
1. We discussed adding 2 new API's (AlterConfig and DescribeConfig). I'll
update KIP-21 with details on these.
2. Discussed during the KIP hangout. We are in agreement.
(1) has a dependency on KIP-4 being completed. Rest of the work in the KIP can
be implemented independently. Any concerns if we tackle it as two separate work
items implementation wise?
We also discussed changing the AlterTopic command in KIP-4 to not include
config changes. Instead, all config changes will pass through the newly
proposed AlterConfig. If no-one objects, I can make some changes to KIP-4 to
reflect this.
Aditya
________________________________________
From: Jay Kreps [jay.kr...@gmail.com]
Sent: Tuesday, May 19, 2015 10:51 AM
To: dev@kafka.apache.org
Subject: Re: [VOTE] KIP-21 Dynamic Configuration
Hey Aditya,
Two comments:
1. Yeah we need to reconcile this with the APIs in KIP-4. I think it does
make sense to allow setting config during topic creation. I agree with your
summary that having alter topic and alter config may be confusing, but
there are also some non-config changes such as replication factor and
partition count that alter topic can carry out. What is the final state you
are proposing?
2. This is implementation related so probably can be removed from the KIP
entirely, but you seem to be proposing a separate config manager for each
config override type. Should we just generalize TopicConfigManager to be
ConfigOverrideManager and have it handle all the override types we will
have? I think I may just be unclear on what you are proposing...
-Jay
On Mon, May 18, 2015 at 1:34 PM, Aditya Auradkar <
aaurad...@linkedin.com.invalid> wrote:
> Yeah, that was just a typo. I've fixed it. Thanks for calling it out.
>
> In KIP-4, I believe we have 3 types of requests: CreateTopic, AlterTopic
> and DeleteTopic. The topic configs are a sub-type of the Create and Alter
> commands. I think it would be nice to simply have a AlterConfig command
> that can alter any type of config rather than having a specific
> ClientConfig.
>
> AlterConfig => [ConfigType [AddedConfigEntry] [DeletedConfig]]
> ConfigType => string
> AddedConfigEntry => ConfigKey ConfigValue
> ConfigKey => string
> ConfigValue => string
> DeletedConfig => string
>
> The downside of this approach is that we will have 2 separate ways of
> changing topic configs (AlterTopic and AlterConfig). While a general
> AlterConfig only makes sense if we plan to have more than two types of
> entity configs.. it's definitely more future proof. Thoughts?
>
> Aditya
>
> ________________________________________
> From: Todd Palino [tpal...@gmail.com]
> Sent: Monday, May 18, 2015 12:39 PM
> To: dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-21 Dynamic Configuration
>
> Agree with Jun here on the JSON format. I think your intention was likely
> to have actual JSON here and it was just a typo in the wiki?
>
> -Todd
>
> On Mon, May 18, 2015 at 12:07 PM, Jun Rao <j...@confluent.io> wrote:
>
> > Aditya,
> >
> > Another thing to consider. In KIP-4, we are adding a new RPC request to
> > change and retrieve topic configs. Do we want to add a similar RPC
> request
> > to change configs per client id? If so, do we want to introduce a
> separate
> > new request or have a combined new request for both topic and client id
> > level config changes?
> >
> > A minor point in the wiki, for the json format in ZK, we should change
> > {X1=Y1,
> > X2=Y2..} to a json map, right?
> >
> > Thanks,
> >
> > Jun
> >
> >
> > On Mon, May 18, 2015 at 9:48 AM, Aditya Auradkar <
> > aaurad...@linkedin.com.invalid> wrote:
> >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-21+-+Dynamic+Configuration
> > >
> > > Aditya
> > >
> >
>
