Hi Ismael,
1. It's worth emphasising that reassigning partitions is a different > process than what happens when a topic is created, so not sure trying to > make it symmetric is beneficial. In addition to what was already discussed, > one should also enable replication throttling before moving the data. Thanks for your responses.The only advantage I can see from having separate APIs for partition count change vs. the other changes is that we expect the former to return synchronously, and the latter to (usually) return asynchronously. Lumping them into the same API forces clients of that API to code for the two possible cases. Is this the particular concern you had in mind, or do you have others? You're right that the proposal doesn't cover setting and clearing a throttle, and it should. I will study the code about how this works before posting back about that. 3. In my opinion, the warning when someone updates configs via > `kafka-topic.sh` was a mistake. Doing the same thing via the configs tool > is quite clunky in comparison. > Is that a request to remove the deprecation warning (and thus to undeprecate using kafka-topic.sh to change configs)? Thanks again for taking the time to respond, Tom On 1 August 2017 at 17:52, Ismael Juma <ism...@juma.me.uk> wrote: > Hi both, > > Thanks for the replies. A few points: > > 1. It's worth emphasising that reassigning partitions is a different > process than what happens when a topic is created, so not sure trying to > make it symmetric is beneficial. In addition to what was already discussed, > one should also enable replication throttling before moving the data. > > 2. HTTP codes are not a great comparison as they are per response while > Kafka responses often include multiple error codes (due to batching). > > 3. In my opinion, the warning when someone updates configs via > `kafka-topic.sh` was a mistake. Doing the same thing via the configs tool > is quite clunky in comparison. > > Ismael > > On Tue, Aug 1, 2017 at 4:52 PM, Tom Bentley <t.j.bent...@gmail.com> wrote: > > > > Regarding adding the possibility to alter the topic config through the > > > AlterTopic API, the current TopicCommand implementation provides a > > warning > > > on doing this suggesting to use the ConfigCommand tool. So it would be > a > > > step back allowing to do the configs change with the alter topic as > well. > > > > > > > To be clear, I'm not proposing that this be supported via the > > kafka-reassign-partitions.sh tool, nor via kafka-topics.sh. It's purely a > > question of whether the API for the AlterTopicsRequest/Response and the > > AdminClient API would support it. As I said, I really don't like the > > duplication of functionality and would prefer to leave it out, even > though > > it makes for a less "symmetric" API wrt CreateTopicsRequest/Response, but > > maybe the community feels otherwise. > > >
