Hi Viktor, Good question. The answer is that the Admin Client knows how to send messages to the controller node. Take a look at electPreferredLeaders, createTopics, deleteTopics, etc. for some examples of how this is done in the code.
kafka-reassign-partitions.sh would be able to simply use the admin client for this functionality. This would require the user to pass a --bootstrap-server argument, as you noted. kafka-reassign-partitions.sh actually already has such an argument (this was added as part of the JBOD work...) best, Colin On Fri, Apr 26, 2019, at 06:34, Viktor Somogyi-Vass wrote: > Hi Colin, > > How would the changed kafka-reassign-partitions.sh command work? Would it > automatically figure out the controller node if you pass some bootstrap > nodes with --bootstrap-server or are we deferring this implementation to > the users? > > Thanks, > Viktor > > On Sat, Apr 20, 2019 at 1:51 AM Colin McCabe <cmcc...@apache.org> wrote: > > > On Wed, Apr 17, 2019, at 17:23, Robert Barrett wrote: > > > 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? > > > > Hmm, good point. That might be more convenient than having to cancel and > > remove before creating a new assignment. > > > > > 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. > > > > It seems like the big change is basically just depending on adminclient > > versus a ZK client. The code itself for converting a JSON file into an > > adminclient call shouldn't be difficult. Maybe we could add a helper > > method to do this, to make it easier to do the conversion. We'll already > > need that code for the command-line tool. > > > > best, > > Colin > > > > > > > > > > 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 > > > > > > > > > > > > > > > > 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 > > > > > > > > > > >
