Hey Colin, I still need to finish reading and understanding the KIP, but I have a couple of comments despite being ignorant of most of the KRaft stuff. (Sorry!)
Firstly, does it make sense to create an extension of the current AdminClient only to handle these specific KRaft use cases? It seems cumbersome to have two sets of bootstrap configurations to make the AdminClient generic enough to handle these specific cases, instead, maybe it is more obvious (to me) to just extend the AdminClient. What I'm thinking is KraftAdminClient which continuously uses *bootstrap.servers*, but make this class only serves the Kraft controllers APIs. Secondly, if we want to continue with the design, I'm not yet sure why we can't continue using the *bootstrap.servers*? I assume when the client gets the metadata, it should know who it is talking to. I'm just reconsidering your alternative again. A bad idea: Why don't we continue using *bootstrap.servers* but have a separated config like *kraft.controller* = true/false. I feel like most users might not know what is a controller and causes some mistakes down the road. Thanks, P On Wed, Apr 19, 2023 at 2:18 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi all, > > I wrote a short KIP about allowing AdminClient to talk directly with the > KRaft controller quorum. Check it out here: > > https://cwiki.apache.org/confluence/x/Owo0Dw > > best, > Colin >
