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


   Hey @jsancio , 
   
   I added some work in progress to this branch including new APIs for this 
feature. 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).
 These changes allow for a more expressive and well-defined interface. 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. 
Should I just update the current kip? 
   
   I am also working on having the clients register the configs that they 
support with the brokers. I tried tying the registration to connectionId in the 
hopes that this would give a unique identifier to each running application. 
However, this will not work since the connectionId can change while a client is 
active. Similarly, tying registration to ip:port will not work because a client 
talks to different brokers on different ports. 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?
   
   EDIT: I updated the KIPs rejected alternatives section with a design that 
ties config registration to <user,client-id> along with ClientInformation. This 
update would allow the user to see what dynamic configs are supported for each 
permutation of client software name and version that is requesting the configs 
associated with a <user, client-id>.


----------------------------------------------------------------
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:
us...@infra.apache.org


Reply via email to