[GitHub] [kafka] dielhennr edited a comment on pull request #9101: KAFKA-10325: KIP-649 implementation

[GitBox <gi...@apache.org>]

dielhennr edited a comment on pull request #9101:
URL: https://github.com/apache/kafka/pull/9101#issuecomment-683076305


   Hi @jsancio I hope you're doing well. I added some work in progress to this branch that includes new APIs and basic functionality for this feature using the new APIs. Fitting user and client-id into the `DescribeConfigs` API was awkward so I thought that the next best step would be to create a specialized set of APIs, similar to  [KIP-546](https://cwiki.apache.org/confluence/display/KAFKA/KIP-546%3A+Add+Client+Quota+APIs+to+the+Admin+Client). I'm wondering if I should create a new KIP and branch so that the old implementation can be referenced without digging into commit or page history. Do you have a preference? 
   
   I am also working on having the clients register the configs that they support, and I'm running into a few issues. I tried tying the registration to connectionId. This includes ip:port of the client as well as the broker. The issue here is that even if registration was tied to ip:port of a client, the client talks to the least loaded node when requesting configs. If the least loaded node is different than the last one the client talked to, the client will use a different port. This leads me to believe that tying supported config registration to the port of a client will not work. Would it be safe to assume that clients with the same ip address are all the same version? Do you have any suggestions for what identifier config registration should be tied to if this assumption cannot be made? 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org