Thanks for the KIP, Colin. I have a couple questions: 1. What's the reasoning for requiring cancellation of a reassignment before submitting a new one? It seems like overriding an existing reassignment could be done with a single update to /brokers/topics/[topic]/partitions/[partitionId]/state and a single LeaderAndIsrRequest. Maybe we could include a flag in the request so that the client can explicitly request to override an existing reassignment? 2. I agree that supporting the old ZK API for in the long term is a bad idea. However, while the number of tools that use the ZK API may be small, this would be a non-trivial change for them. Could we temporarily support both, with a config enabling the new behavior to prevent users from trying to use both mechanisms (if the config is true, the old znode is ignored; if the config is false, the Admin Client API returns an error indicating that it is not enabled)? We could then remove the ZK API in a later release, to give people time to update their tools.
Thanks, Bob On Mon, Apr 15, 2019 at 9:33 PM Colin McCabe <cmcc...@apache.org> wrote: > link: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-455%3A+Create+an+Administrative+API+for+Replica+Reassignment > > C. > > On Mon, Apr 15, 2019, at 18:07, Colin McCabe wrote: > > Hi all, > > > > We've been having discussions on a few different KIPs (KIP-236, > > KIP-435, etc.) about what the Admin Client replica reassignment API > > should look like. The current API is really hard to extend and > > maintain, which is a big source of problems. I think it makes sense to > > have a KIP that establishes a clean API that we can use and extend > > going forward, so I posted KIP-455. Take a look. :) > > > > best, > > Colin > >
