On Tue, Apr 30, 2019, at 23:33, George Li wrote: > Hi Colin, > > Thanks for KIP-455! yes. KIP-236, etc. will depend on it. It is the > good direction to go for the RP > > Regarding storing the new reassignments & original replicas at the > topic/partition level. I have some concerns when controller is failing > over, and the scalability of scanning the active reassignments from ZK > topic/partition level nodes. Please see my reply to Jason in the > KIP-236 thread.
Hi George, The controller already has to rescan this information from ZooKeeper when starting up, for unrelated reasons. The controller needs to know about stuff like who is in the ISR for each partition, what the replicas are, and so forth. So this doesn't add any additional overhead. best, Colin > > Once the decision is made where new reassignment and original replicas > is stored, I will modify KIP-236 accordingly for how to cancel/rollback > the reassignments. > > Thanks, > George > > > On Monday, April 15, 2019, 6:07:44 PM PDT, Colin McCabe > <cmcc...@apache.org> 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 >
