Hi Mickael, Thanks for the KIP. I can understand the motivation, but to be honest I have a doubt about this.
Taking the ACLs first, by allowing multiple filters with the current proposal isn't there the chance that the same ACL will match multiple filters, and be returned multiple times in the response. In fact, in the worst case couldn't the client (by intent or accident) just request all ACLs be included in the response an arbitrary number of times? This could result in some pretty large responses. One way to avoid inflating the response like this would be for the broker to deduplicate the ACLs in the response by assigning an id for each, serialising each once and then using the id to enumerate the matches for each pattern. It's worth noting that the AccessControlEntryRecord used for KRaft clusters already has a Uuid. So for the KRaft case it might be possible to use this, rather than the broker having to deduplicate when handing the request. Another wrinkle is that if the broker calls Authorizer.acls(AclBindingFilter) once for each pattern there's no guarantee that the results are consistent (they could be modified between calls). It could be made consistent with appropriate locking, but since in practice this would be a very rare occurrence maybe we could just document that as a limitation. Thanks again, Tom On Fri, 18 Nov 2022 at 18:00, Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi, > > I have opened KIP-888 to allow describing ACLs and Quotas in batches: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-888%3A+Batch+describe+ACLs+and+describe+client+quotas > > Let me know if you have any feedback or suggestions. > > Thanks, > Mickael > >
