Hello Gwen, The purpose here is for maintaining compatibility old clients, who do not have functionality to do re-routing admin requests themselves. New clients can of course do this themselves by detecting who's the controller.
Hello Colin / Boyang, Regarding the usage of the envelope, I'm curious what are the potential future use cases that would require request forwarding and hence envelope would be useful? Originally I thought that the forwarding mechanism is only temporary as we need it for the bridge release, and moving forward we will get rid of this to simplify the code base. If we do have valid use cases in the future which makes us believe that request forwarding would actually be a permanent feature retained on the broker side, I'm on board with adding the envelope request protocol. Guozhang On Wed, Apr 22, 2020 at 8:22 AM Gwen Shapira <g...@confluent.io> wrote: > Hey Boyang, > > Sorry if this was already discussed, but I didn't see this as rejected > alternative: > > Until now, we always did client side routing - the client itself found the > controller via metadata and directed requests accordingly. Brokers that > were not the controller, rejected those requests. > > Why did we decide to move to broker side routing? Was the client-side > option discussed and rejected somewhere and I missed it? > > Gwen > > On Fri, Apr 3, 2020, 4:45 PM Boyang Chen <reluctanthero...@gmail.com> > wrote: > > > Hey all, > > > > I would like to start off the discussion for KIP-590, a follow-up > > initiative after KIP-500: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-590%3A+Redirect+Zookeeper+Mutation+Protocols+to+The+Controller > > > > This KIP proposes to migrate existing Zookeeper mutation paths, including > > configuration, security and quota changes, to controller-only by always > > routing these alterations to the controller. > > > > Let me know your thoughts! > > > > Best, > > Boyang > > > -- -- Guozhang
