Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

Colin, I would like to leave the framework that is in KAFKA-17316 as it makes testing the new implementations easier. But let's discuss that elsewhere (I will start another discussion for 17316 and 17423 together). PatternType.GLOB makes sense, I will adjust the KIP to use that terminology. I u

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

Hi Claude, I think this is great work. Speeding up the Authorizer will be a big win for us. I don't think we need to add additional interfaces for this, though. Just get rid of the old slower implementation that I wrote, and replace it with your newer, faster one. Also, I think we should conti

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

I made it easier to replace the existing StandardAuthorizerData with a different implementation in order show the Trie implementation met all the requirements of the StandardAuthorizerData and could be replaced without changing the StandardAuthorizer implementation. Replacing the current StandardA

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

On Thu, Aug 29, 2024, at 01:34, Claude Warren, Jr wrote: > Colin, > > Thanks for your insightful comments. I came to the same conclusion. > > I do have 2 Jira tickets to simplify some of this. > > 1) KAFKA-17316 - Makes > developing a new Au

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

Colin, Thanks for your insightful comments. I came to the same conclusion. I do have 2 Jira tickets to simplify some of this. 1) KAFKA-17316 - Makes developing a new Authorizer by creating a new implementation of the StandardAuthorizerData ea

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

On Sat, Jul 27, 2024, at 04:20, Claude Warren, Jr wrote: > I have updated the KIP with results from the Trie implementation and they > are dramatic to say the least. For most searches they are at least an > order of magnitude faster and use less memory. The wildcard search is not > a regular expr

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

I have updated the KIP with results from the Trie implementation and they are dramatic to say the least. For most searches they are at least an order of magnitude faster and use less memory. The wildcard search is not a regular expression but rather a file type wild card (*=1 or more character, ?

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

I think that if we put in a trie based system we should be able to halve the normal searhc times and still be able to locate wild card matches very quickly. Users should be warned that "head wildcard" matches are slow and to use them sparingly. I am going to see if I can work out how to do wildca

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

There are some test results mentioned in the Test Plan section of the Kip, but we need to do more testing with various patterns and permission types. As mentioned in the discuss thread, the trie implementation could potentially surpass the current speed of ACL match. However, we can only accuratel

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

My concern is that the extra complexity may actually slow us down. In general people already complain about the speed of ACL matches, and adding another "degree of freedom" seems likely to make things worse. It would be useful to understand how much faster or slower the code is with the propsed

Re: [VOTE] KIP-1042: Support for wildcard when creating new acls

I give this a cautious +1 (non binding) as development may yield better head wildcard results. I think the adoption criteria for the ACL search needs to be specified in the KIP. We do not have a good handle on how long the current searches take. If the wildcard tests can be merged into a trie se