Hi Colin,
Thanks for KIP-455! yes. KIP-236, etc. will depend on it. It is the good
direction to go for the RPC.
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.
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
<[email protected]> 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
