Hi All, Just a note to say the KIP documentation has been updated inline with the current implementation.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-290%3A+Support+for+Prefixed+ACLs Thanks, Andy On 25 May 2018 at 17:44, Andy Coates <a...@confluent.io> wrote: > > Since Resource is a concrete class now, we can't make it an interface > without breaking API compatibility. > > Very true... hummm.... hacky, but we could sub-class Resource. > > > Even if it were possible to do compatibly, I would argue it's a bad > idea. If we need to add another bit of state like case insensitivity, we > don't want to have LiteralCaseInsensistiveResource, > WildcardSuffixedCaseInsensitiveResource, etc. etc. You need 2^n > subclasses classes to represent N bits of state. > > Not sure I agree - I would implement such dimensions using composition, > not different implementations, e.g. new CaseInsenisticeResourceFilter(new > PrefixedResourceFilter("/foo")) to get a case-insensitive prefixed filter. > > > > On 22 May 2018 at 05:15, Colin McCabe <cmcc...@apache.org> wrote: > >> On Mon, May 21, 2018, at 04:53, Andy Coates wrote: >> > Hey Piyush, >> > >> > Thanks for the updated KIP! Couple of minor points from me: >> > >> > When storing wildcard-suffixed Acls in ZK, drop the asterisk of the end >> for >> > the path, e.g. change "*/kafka-wildcard-acl/Topic/teamA*" * to "*/* >> > *kafka-wildcard-acl**/Topic/**teamA"*. This reduces error conditions, >> i.e. >> > this is a place for storing wildcard-suffixed Acls, so it implicitly >> ends >> > in an asterisk. If you include the asterisk in the path then you need to >> > validate each entry, when reading, ends with an asterisk, and do >> something >> > if they don't. If you don't include the training asterisk then there is >> > nothing to validate and you can treat the prefix as a literal, (i.e. no >> > escaping needed). TBH I'd probably drop the asterisk from the in-memory >> > representation as well, for the same reason. >> >> Hi Andy, >> >> I agree. If everything in ZK under /kafka-wildcard-acl/ is a prefix ACL, >> there is no need to include the star at the end. And really, it should be >> called something like /kafka-prefix-acl/, since it's only vaguely related >> to the idea of wildcards. >> >> > >> > Rather than creating an enum to indicate the type of a resource, you >> could >> > instead use polymorphism, e.g. make Resource an interface and have two >> > implementations: LiteralResource and WildcardSuffixedResource. This is >> > also extensible, but may also allow for a cleaner implementation. >> >> Since Resource is a concrete class now, we can't make it an interface >> without breaking API compatibility. >> >> Even if it were possible to do compatibly, I would argue it's a bad >> idea. If we need to add another bit of state like case insensitivity, we >> don't want to have LiteralCaseInsensistiveResource, >> WildcardSuffixedCaseInsensitiveResource, etc. etc. You need 2^n >> subclasses classes to represent N bits of state. >> >> I would argue that there should be a field in Resource like NameType >> which can be LITERAL or PREFIX. That leaves us in a good position when >> someone inevitably comes up with a new NameType. >> >> Does this still have a chance to get in, or has the KIP window closed? I >> would argue with one or two minor changes it's ready to go. Pretty much >> all of the compatibility problems are solved with the separate ZK hierarchy. >> >> best, >> Colin >> >> > >> > Andy >> > >> > On 21 May 2018 at 01:58, Rajini Sivaram <rajinisiva...@gmail.com> >> wrote: >> > >> > > Hi Piyush, Thanks for the KIP! >> > > >> > > +1 (binding) >> > > >> > > Regards, >> > > >> > > Rajini >> > > >> > > On Sun, May 20, 2018 at 2:53 PM, Andy Coates <a...@confluent.io> >> wrote: >> > > >> > > > Awesome last minute effort Piyush. >> > > > >> > > > Really appreciate your time and input, >> > > > >> > > > Andy >> > > > >> > > > Sent from my iPhone >> > > > >> > > > > On 19 May 2018, at 03:43, Piyush Vijay <piyushvij...@gmail.com> >> wrote: >> > > > > >> > > > > Updated the KIP. >> > > > > >> > > > > 1. New enum field 'ResourceNameType' in Resource and >> ResourceFilter >> > > > classes. >> > > > > 2. modify getAcls() and rely on ResourceNameType' field in >> Resource to >> > > > > return either exact matches or all matches based on >> wildcard-suffix. >> > > > > 3. CLI changes to identify if resource name is literal or >> > > wildcard-suffix >> > > > > 4. Escaping doesn't work and isn't required if we're keeping a >> separate >> > > > > path on ZK (kafka-wildcard-acl) to store wildcard-suffix ACLs. >> > > > > 5. New API keys for Create / Delete / Describe Acls request with >> a new >> > > > > field in schemas for 'ResourceNameType'. >> > > > > >> > > > > Looks ready to me for the vote, will start voting thread now. >> Thanks >> > > > > everyone for the valuable feedback. >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > Piyush Vijay >> > > > > >> > > > > >> > > > > Piyush Vijay >> > > > > >> > > > >> On Fri, May 18, 2018 at 6:07 PM, Andy Coates <a...@confluent.io> >> > > wrote: >> > > > >> >> > > > >> Hi Piyush, >> > > > >> >> > > > >> We're fast approaching the KIP deadline. Are you actively >> working on >> > > > this? >> > > > >> If you're not I can take over. >> > > > >> >> > > > >> Thanks, >> > > > >> >> > > > >> Andy >> > > > >> >> > > > >>> On 18 May 2018 at 14:25, Andy Coates <a...@confluent.io> wrote: >> > > > >>> >> > > > >>> OK I've read it now. >> > > > >>> >> > > > >>> 1. I see you have an example: >> > > > >>>> For example: If I want to fetch all ACLs that match ’topicA*’, >> it’s >> > > > not >> > > > >>> possible without introducing new API AND maintaining backwards >> > > > >>> compatibility. >> > > > >>> getAcls takes a Resource, right, which would be either a full >> > > resource >> > > > >>> name or 'ALL', i.e. '*', right? The point of the call is to >> get all >> > > > ACLs >> > > > >>> relating to a specific resource, not a partial resource like >> > > 'topicA*'. >> > > > >>> Currently, I'm guessing / half-remembering that if you ask it >> for >> > > ACLs >> > > > >> for >> > > > >>> topic 'foo' it doesn't include global 'ALL' ACLs in the list - >> that >> > > > would >> > > > >>> be a different call. With the introduction of partial >> wildcards I >> > > > think >> > > > >>> the _most_ backwards compatible change would be to have >> > > > >>> getAcls("topic:foo") to return all the ACLs, including that >> affect >> > > this >> > > > >>> topic. This could include any '*'/ALL Acls, (which would be a >> small >> > > > >>> backwards compatible change), or exclude them as it current >> does. >> > > > >>> Excluding any matching partial wildcard acl, e.g. 'f*' would >> break >> > > > >>> compatibility IMHO. >> > > > >>> >> > > > >>> 2. Example command lines, showing how to add ACLs to specific >> > > resources >> > > > >>> that *end* with an asterisk char and adding wildcard-suffixed >> ACLs, >> > > > would >> > > > >>> really help clarify the KIP. e.g. >> > > > >>> >> > > > >>> bin/kafka-acls.sh --authorizer-properties >> > > zookeeper.connect=localhost: >> > > > >> 2181 >> > > > >>> --add --allow-principal User:Bob --allow-principal User:Alice >> > > > >> --allow-host >> > > > >>> 198.51.100.0 --allow-host 198.51.100.1 --operation Read --group >> > > > my-app-* >> > > > >>> >> > > > >>> With the above command I can't see how the code can know if the >> user >> > > > >> means >> > > > >>> a literal group called 'my-app-*', or a wildcard suffix for any >> group >> > > > >>> starting with 'my-app-'. Escaping isn't enough as the escape >> char can >> > > > >> clash >> > > > >>> too, e.g. escaping a literal to 'my-app-\*' can still clash with >> > > > someone >> > > > >>> wanting a wildcard sufiix matching any group starting with >> > > 'my-app-\'. >> > > > >>> >> > > > >>> So there needs to be a syntax change here, I think. Maybe some >> new >> > > > >>> command line switch to either explicitly enable or disable >> > > > >>> 'wildcard-suffix' support? Probably defaulting to >> wildcard-suffix >> > > > being >> > > > >>> on, (better experience going forward), though off is more >> backwards >> > > > >>> compatible. >> > > > >>> >> > > > >>> >> > > > >>> 3. Again, examples of how to store ACLs for specific resources >> that >> > > > >> *end* with >> > > > >>> an asterisk and wildcard-suffix ACLs, with any escaping would >> really >> > > > >> help. >> > > > >>> >> > > > >>> >> > > > >>> >> > > > >>>> On 18 May 2018 at 13:55, Andy Coates <a...@confluent.io> >> wrote: >> > > > >>>> >> > > > >>>> Hey Piyush, >> > > > >>>> >> > > > >>>> Thanks for getting this in! :D >> > > > >>>> >> > > > >>>> About to read now. But just quickly... >> > > > >>>> >> > > > >>>> 1. I'll read up on the need for getMatchingAcls - but just >> playing >> > > > >> devils >> > > > >>>> advocate for a moment - if a current caller of getAcls() >> expects it >> > > to >> > > > >>>> return the full set of ACLs for a given resource, would post >> this >> > > > change >> > > > >>>> only returning a sub set and requiring them to return >> > > getMatchingAcls >> > > > to >> > > > >>>> get the full set not itself be a break in compatibility? I'm >> > > thinking >> > > > >> about >> > > > >>>> any tooling / UI / etc people may have built on top of this. >> If Im >> > > > >> missing >> > > > >>>> the point, then maybe a concrete example, (if you've not >> already >> > > added >> > > > >> one >> > > > >>>> to the doc), may help. >> > > > >>>> >> > > > >>>> 2. Something must change on the command line, surely? e.g. as >> > > command >> > > > >>>> line user how would the command differ if I wanted to add an >> ACL >> > > onto >> > > > a >> > > > >>>> group called 'foo*' as opposed to a all groups starting with >> 'foo'? >> > > > >>>> >> > > > >>>> 3. Thinking this through, I actually bracktracked - I don't >> think it >> > > > >> will >> > > > >>>> work due to path collisions, even with escaping - as the >> escaped >> > > > version >> > > > >>>> can still collide. >> > > > >>>> >> > > > >>>> Off to read the doc now. >> > > > >>>> >> > > > >>>>> On 18 May 2018 at 13:33, Piyush Vijay <piyushvij...@gmail.com >> > >> > > > wrote: >> > > > >>>>> >> > > > >>>>> Ready to review. Let me know if something looks missing or not >> > > clear. >> > > > >>>>> >> > > > >>>>> Thanks >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> Piyush Vijay >> > > > >>>>> >> > > > >>>>> On Fri, May 18, 2018 at 12:54 PM, Piyush Vijay < >> > > > piyushvij...@gmail.com >> > > > >>> >> > > > >>>>> wrote: >> > > > >>>>> >> > > > >>>>>> Andy, >> > > > >>>>>> >> > > > >>>>>> 1. Updated the KIP about need for getMatchingAcls(). >> Basically, >> > > it's >> > > > >>>>>> required to add an inspection method without breaking >> > > compatibility. >> > > > >>>>>> getAcls() only looks at a single location. >> > > > >>>>>> >> > > > >>>>>> 2. Nothing will change from user's perspective. they will >> add / >> > > > >> delete/ >> > > > >>>>>> list ACLs as earlier. >> > > > >>>>>> >> > > > >>>>>> 3. Good point about moving everything to a v2 path. We might >> still >> > > > >>>>> have to >> > > > >>>>>> support snowflakes but I will this better. >> > > > >>>>>> >> > > > >>>>>> I'm giving it a final read. I'll update here once I think >> it's >> > > > ready. >> > > > >>>>>> >> > > > >>>>>> Thanks >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>> Piyush Vijay >> > > > >>>>>> >> > > > >>>>>> On Fri, May 18, 2018 at 12:18 PM, Piyush Vijay < >> > > > >> piyushvij...@gmail.com >> > > > >>>>>> >> > > > >>>>>> wrote: >> > > > >>>>>> >> > > > >>>>>>> On it, Andy. It should be out in next 30 mins. >> > > > >>>>>>> >> > > > >>>>>>> On Fri, May 18, 2018 at 12:17 PM Andy Coates < >> a...@confluent.io> >> > > > >>>>> wrote: >> > > > >>>>>>> >> > > > >>>>>>>> Hey Piyush, >> > > > >>>>>>>> >> > > > >>>>>>>> How are you getting on updating the KIP? Can we offer any >> > > support? >> > > > >>>>> We're >> > > > >>>>>>>> starting to fly really close to the required 72 hours cut >> off >> > > for >> > > > >>>>> KIPs. >> > > > >>>>>>>> This doesn't leave much room for resolving any issues any >> > > > >> committers >> > > > >>>>>>>> find. >> > > > >>>>>>>> Also, we now require at least three committers to review >> this >> > > KIP >> > > > >>>>> today >> > > > >>>>>>>> _and_ find no issues if we're to get this KIP accepted. >> > > > >>>>>>>> >> > > > >>>>>>>> Thanks, >> > > > >>>>>>>> >> > > > >>>>>>>> Andy >> > > > >>>>>>>> >> > > > >>>>>>>> On 18 May 2018 at 01:21, Piyush Vijay < >> piyushvij...@gmail.com> >> > > > >>>>> wrote: >> > > > >>>>>>>> >> > > > >>>>>>>>> Hi Andy, >> > > > >>>>>>>>> >> > > > >>>>>>>>> I still have some minor changes left to the KIP. I'll >> make them >> > > > >> in >> > > > >>>>> the >> > > > >>>>>>>>> morning. I'm sorry I got caught up in some other things >> today. >> > > > >> But >> > > > >>>>> that >> > > > >>>>>>>>> would still give us 72 hours before the deadline :) >> > > > >>>>>>>>> >> > > > >>>>>>>>> Thanks >> > > > >>>>>>>>> >> > > > >>>>>>>>> >> > > > >>>>>>>>> Piyush Vijay >> > > > >>>>>>>>> >> > > > >>>>>>>>> On Thu, May 17, 2018 at 1:27 PM, Andy Coates < >> > > a...@confluent.io> >> > > > >>>>>>>> wrote: >> > > > >>>>>>>>> >> > > > >>>>>>>>>> Hey Piyush - my bad. Sorry. >> > > > >>>>>>>>>> >> > > > >>>>>>>>>> On 17 May 2018 at 13:23, Piyush Vijay < >> piyushvij...@gmail.com >> > > > >> > > > >>>>>>>> wrote: >> > > > >>>>>>>>>> >> > > > >>>>>>>>>>> It's still not complete. I'll drop a message here when >> I'm >> > > > >> done >> > > > >>>>>>>> with >> > > > >>>>>>>>> the >> > > > >>>>>>>>>>> updates. >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> Thanks >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> Piyush Vijay >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>> On Thu, May 17, 2018 at 12:04 PM, Andy Coates < >> > > > >>>>> a...@confluent.io> >> > > > >>>>>>>>> wrote: >> > > > >>>>>>>>>>> >> > > > >>>>>>>>>>>> Thanks for the update to the KIP Piyush! >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> Reading it through again, I've a couple of questions: >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> 1. Why is there a need for a new 'getMatchingAcls' >> method, >> > > > >>>>> over >> > > > >>>>>>>> the >> > > > >>>>>>>>>>>> existing getAcls method? They both take a Resource >> instance >> > > > >>>>> and >> > > > >>>>>>>>> return >> > > > >>>>>>>>>> a >> > > > >>>>>>>>>>>> set of Acls. What is the difference in their behaviour? >> > > > >>>>>>>>>>>> 2. It's not clear to me from the KIP alone what will >> > > > >> change, >> > > > >>>>>>>> from a >> > > > >>>>>>>>>> users >> > > > >>>>>>>>>>>> perspective, on how they add / list / delete ACLs. I'm >> > > > >>>>> assuming >> > > > >>>>>>>> this >> > > > >>>>>>>>>>> won't >> > > > >>>>>>>>>>>> change. >> > > > >>>>>>>>>>>> 3. Writing ACLs to a new location to get around the >> issues >> > > > >> of >> > > > >>>>>>>>> embedded >> > > > >>>>>>>>>>>> wildcards in existing group ACLs makes sense to me - >> but >> > > > >>>>> just a >> > > > >>>>>>>>>> thought, >> > > > >>>>>>>>>>>> will we be writing all new ACLs under this new path, or >> > > > >> just >> > > > >>>>>>>> those >> > > > >>>>>>>>> that >> > > > >>>>>>>>>>> are >> > > > >>>>>>>>>>>> partial wildcards? I'm assuming its the latter, but it >> > > > >> could >> > > > >>>>>>>> just be >> > > > >>>>>>>>>>> 'all' >> > > > >>>>>>>>>>>> right? As we could escape illegal chars. So we could >> just >> > > > >>>>> make >> > > > >>>>>>>> this >> > > > >>>>>>>>>> new >> > > > >>>>>>>>>>>> path 'v2' rather wildcard. >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> Andy >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>> On 17 May 2018 at 09:32, Colin McCabe < >> cmcc...@apache.org> >> > > > >>>>>>>> wrote: >> > > > >>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> On Thu, May 17, 2018, at 09:28, Piyush Vijay wrote: >> > > > >>>>>>>>>>>>>> I was planning to do that. >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> Another unrelated detail is the presence of the >> support >> > > > >>>>> for >> > > > >>>>>>>> ‘*’ >> > > > >>>>>>>>> ACL >> > > > >>>>>>>>>>>>>> currently. Looks like we’ll have to keep supporting >> > > > >> this >> > > > >>>>> as a >> > > > >>>>>>>>>> special >> > > > >>>>>>>>>>>>> case, >> > > > >>>>>>>>>>>>>> even though using a different location for >> > > > >>>>> wildcard-suffix >> > > > >>>>>>>> ACLs >> > > > >>>>>>>>> on >> > > > >>>>>>>>>>> Zk. >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>> +1. >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>> Thanks, Piyush. >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>> On Thu, May 17, 2018 at 9:15 AM Colin McCabe < >> > > > >>>>>>>> cmcc...@apache.org >> > > > >>>>>>>>>> >> > > > >>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> Thanks, Piyush. +1 for starting the vote soon. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> Can you please also add a discussion about escaping? >> > > > >>>>> For >> > > > >>>>>>>>>> example, >> > > > >>>>>>>>>>>>> earlier >> > > > >>>>>>>>>>>>>>> we discussed using backslashes to escape special >> > > > >>>>>>>> characters. >> > > > >>>>>>>>> So >> > > > >>>>>>>>>>> that >> > > > >>>>>>>>>>>>> users >> > > > >>>>>>>>>>>>>>> can create an ACL referring to a literal "foo*" >> group >> > > > >>>>> by >> > > > >>>>>>>>> creating >> > > > >>>>>>>>>>> an >> > > > >>>>>>>>>>>>> ACL >> > > > >>>>>>>>>>>>>>> for "foo\*" Similarly, you can get a literal >> > > > >> backslash >> > > > >>>>>>>> with >> > > > >>>>>>>>>> "\\". >> > > > >>>>>>>>>>>>> This is >> > > > >>>>>>>>>>>>>>> the standard UNIX escaping mechanism. >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> Also, for the section that says "Changes to >> > > > >> AdminClient >> > > > >>>>>>>> (needs >> > > > >>>>>>>>>>>>>>> discussion)", we need a new method that will allow >> > > > >>>>> users to >> > > > >>>>>>>>>> escape >> > > > >>>>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>>>> group names and other names. So you can feed this >> > > > >>>>> method >> > > > >>>>>>>> your >> > > > >>>>>>>>>>>> "foo\*" >> > > > >>>>>>>>>>>>>>> consumer group name, and it will give you "foo\\\*", >> > > > >>>>> which >> > > > >>>>>>>> is >> > > > >>>>>>>>>> what >> > > > >>>>>>>>>>>> you >> > > > >>>>>>>>>>>>>>> would need to use to create an ACL for this consumer >> > > > >>>>> group >> > > > >>>>>>>> in >> > > > >>>>>>>>>>>>> AdminClient. >> > > > >>>>>>>>>>>>>>> I think that's the only change we need to admin >> > > > >> client >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> regards, >> > > > >>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> On Thu, May 17, 2018, at 08:55, Piyush Vijay wrote: >> > > > >>>>>>>>>>>>>>>> Hi Rajini/Colin, >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> I will remove the wildcard principals from the >> > > > >> scope >> > > > >>>>> for >> > > > >>>>>>>> now, >> > > > >>>>>>>>>>>>> updating >> > > > >>>>>>>>>>>>>>> KIP >> > > > >>>>>>>>>>>>>>>> right now and will open it for vote. >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Thanks >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> Piyush Vijay >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> On Thu, May 17, 2018 at 6:59 AM, Rajini Sivaram < >> > > > >>>>>>>>>>>>> rajinisiva...@gmail.com >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> Hi Piyush, >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> I have added a PR (https://github.com/apache/ >> > > > >>>>>>>>> kafka/pull/5030 >> > > > >>>>>>>>>> ) >> > > > >>>>>>>>>>>> with >> > > > >>>>>>>>>>>>>>> tests >> > > > >>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>> show how group principals can be used for >> > > > >>>>> authorization >> > > > >>>>>>>>> with >> > > > >>>>>>>>>>>> custom >> > > > >>>>>>>>>>>>>>>>> principal builders. One of the tests uses SASL. >> > > > >> It >> > > > >>>>> is >> > > > >>>>>>>> not >> > > > >>>>>>>>>> quite >> > > > >>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>> same as >> > > > >>>>>>>>>>>>>>>>> a full-fledged user groups, but since it works >> > > > >>>>> with all >> > > > >>>>>>>>>>> security >> > > > >>>>>>>>>>>>>>> protocols, >> > > > >>>>>>>>>>>>>>>>> it could be an alternative to wildcarded >> > > > >>>>> principals. >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> Let us know if we can help in any way to get this >> > > > >>>>> KIP >> > > > >>>>>>>>> updated >> > > > >>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>> ready for >> > > > >>>>>>>>>>>>>>>>> voting to include in 2.0.0. >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> Thanks, >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> Rajini >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>> On Wed, May 16, 2018 at 10:21 PM, Colin McCabe < >> > > > >>>>>>>>>>>> cmcc...@apache.org >> > > > >>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> On Tue, May 15, 2018 at 7:18 PM, Rajini >> > > > >>>>> Sivaram < >> > > > >>>>>>>>>>>>>>>>> rajinisiva...@gmail.com >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>> Hi Piyush, >> > > > >>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>> It is possible to configure >> > > > >> PrincipalBuilder >> > > > >>>>> for >> > > > >>>>>>>>> SASL ( >> > > > >>>>>>>>>>>>>>>>>>>> https://cwiki.apache.org/ >> > > > >>>>>>>>> confluence/display/KAFKA/KIP- >> > > > >>>>>>>>>>>>>>>>>>>> 189%3A+Improve+principal+build >> > > > >>>>>>>> er+interface+and+add+ >> > > > >>>>>>>>>>>>>>>>> support+for+SASL). >> > > > >>>>>>>>>>>>>>>>>> If >> > > > >>>>>>>>>>>>>>>>>>>> that satisfies your requirements, perhaps >> > > > >> we >> > > > >>>>> can >> > > > >>>>>>>> move >> > > > >>>>>>>>>>>>> wildcarded >> > > > >>>>>>>>>>>>>>>>>> principals >> > > > >>>>>>>>>>>>>>>>>>>> out of this KIP and focus on wildcarded >> > > > >>>>>>>> resources? >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> +1. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> We also need to determine which characters will >> > > > >>>>> be >> > > > >>>>>>>>> reserved >> > > > >>>>>>>>>>> for >> > > > >>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>> future. I think previously we thought about @, >> > > > >>>>> #, >> > > > >>>>>>>> $, %, >> > > > >>>>>>>>> ^, >> > > > >>>>>>>>>>> &, >> > > > >>>>>>>>>>>> *. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>> On Tue, May 15, 2018 at 7:15 PM, Piyush >> > > > >>>>> Vijay < >> > > > >>>>>>>>>>>>>>>>> piyushvij...@gmail.com> >> > > > >>>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> Hi Colin, >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> Escaping at this level is making sense to >> > > > >> me >> > > > >>>>>>>> but let >> > > > >>>>>>>>>> me >> > > > >>>>>>>>>>>>> think >> > > > >>>>>>>>>>>>>>> more >> > > > >>>>>>>>>>>>>>>>>> and get >> > > > >>>>>>>>>>>>>>>>>>>>> back to you. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> Thanks, Piyush. What questions do you think >> > > > >> are >> > > > >>>>>>>> still >> > > > >>>>>>>>> open >> > > > >>>>>>>>>>>>> regarding >> > > > >>>>>>>>>>>>>>>>>> escape characters? >> > > > >>>>>>>>>>>>>>>>>> As Rajini mentioned, we have to get this in >> > > > >> soon >> > > > >>>>> in >> > > > >>>>>>>> order >> > > > >>>>>>>>>> to >> > > > >>>>>>>>>>>> make >> > > > >>>>>>>>>>>>>>> the KIP >> > > > >>>>>>>>>>>>>>>>>> freeze. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> But should we not just get rid of one of >> > > > >>>>>>>> AclBinding >> > > > >>>>>>>>> or >> > > > >>>>>>>>>>>>>>>>>> AclBindingFilter >> > > > >>>>>>>>>>>>>>>>>>>>> then? Is there a reason to keep both given >> > > > >>>>> that >> > > > >>>>>>>>>>>>>>> AclBindingFilter and >> > > > >>>>>>>>>>>>>>>>>>>>> AclBinding look exact copy of each other >> > > > >>>>> after >> > > > >>>>>>>> this >> > > > >>>>>>>>>>>> change? >> > > > >>>>>>>>>>>>> This >> > > > >>>>>>>>>>>>>>>>> will >> > > > >>>>>>>>>>>>>>>>>> be a >> > > > >>>>>>>>>>>>>>>>>>>>> one-time breaking change in APIs marked as >> > > > >>>>>>>>> "Evolving", >> > > > >>>>>>>>>>> but >> > > > >>>>>>>>>>>>> makes >> > > > >>>>>>>>>>>>>>>>>> sense in >> > > > >>>>>>>>>>>>>>>>>>>>> the long term? Am I missing something >> > > > >> here? >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> AclBinding represents an ACL. AclBindingFilter >> > > > >>>>> is a >> > > > >>>>>>>>> filter >> > > > >>>>>>>>>>>> which >> > > > >>>>>>>>>>>>>>> can be >> > > > >>>>>>>>>>>>>>>>>> used to locate AclBinding objects. Similarly >> > > > >>>>> with >> > > > >>>>>>>>> Resource >> > > > >>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>> ResourceFilter. There is no reason to combine >> > > > >>>>> them >> > > > >>>>>>>>> because >> > > > >>>>>>>>>>>> they >> > > > >>>>>>>>>>>>>>>>> represent >> > > > >>>>>>>>>>>>>>>>>> different things. Although they contain many >> > > > >> of >> > > > >>>>> the >> > > > >>>>>>>> same >> > > > >>>>>>>>>>>> fields, >> > > > >>>>>>>>>>>>>>> they >> > > > >>>>>>>>>>>>>>>>> are >> > > > >>>>>>>>>>>>>>>>>> not exact copies. Many fields can be null in >> > > > >>>>>>>>>>>> AclBindingFilter-- >> > > > >>>>>>>>>>>>>>> fields >> > > > >>>>>>>>>>>>>>>>> can >> > > > >>>>>>>>>>>>>>>>>> never be null in AclBinding. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> For example, you can have an AclBindingFilter >> > > > >>>>> that >> > > > >>>>>>>>> matches >> > > > >>>>>>>>>>>> every >> > > > >>>>>>>>>>>>>>>>>> AclBinding. There is more discussion of this >> > > > >> on >> > > > >>>>> the >> > > > >>>>>>>>>> original >> > > > >>>>>>>>>>>> KIP >> > > > >>>>>>>>>>>>>>> that >> > > > >>>>>>>>>>>>>>>>>> added ACL support to AdminClient. >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> best, >> > > > >>>>>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> Piyush Vijay >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> On Tue, May 15, 2018 at 9:01 AM, Colin >> > > > >>>>> McCabe < >> > > > >>>>>>>>>>>>>>> cmcc...@apache.org> >> > > > >>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> Hi Piyush, >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> I think AclBinding should operate the >> > > > >> same >> > > > >>>>>>>> way as >> > > > >>>>>>>>>>>>>>>>> AclBindingFilter. >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> So you should be able to do something >> > > > >> like >> > > > >>>>>>>> this: >> > > > >>>>>>>>>>>>>>>>>>>>>>> AclBindingFilter filter = new >> > > > >>>>>>>>> AclBindingFiler(new >> > > > >>>>>>>>>>>>>>>>>>>>>> ResourceFilter(ResourceType.GROUP, >> > > > >>>>> "foo*")) >> > > > >>>>>>>>>>>>>>>>>>>>>>> AclBinding binding = new >> > > > >> AclBinding(new >> > > > >>>>>>>>>>>>>>>>>> Resource(ResourceType.GROUP, >> > > > >>>>>>>>>>>>>>>>>>>>>> "foo*")) >> > > > >>>>>>>>>>>>>>>>>>>>>>> assertTrue(filter.matches(binding)); >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> Thinking about this more, it's starting >> > > > >> to >> > > > >>>>>>>> feel >> > > > >>>>>>>>>> really >> > > > >>>>>>>>>>>>> messy >> > > > >>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>> create >> > > > >>>>>>>>>>>>>>>>>>>>> new >> > > > >>>>>>>>>>>>>>>>>>>>>> "pattern" constructors for Resource and >> > > > >>>>>>>>>>>> ResourceFilter. I >> > > > >>>>>>>>>>>>>>> don't >> > > > >>>>>>>>>>>>>>>>>> think >> > > > >>>>>>>>>>>>>>>>>>>>>> people will be able to figure this out. >> > > > >>>>>>>> Maybe we >> > > > >>>>>>>>>>> should >> > > > >>>>>>>>>>>>> just >> > > > >>>>>>>>>>>>>>>>> have a >> > > > >>>>>>>>>>>>>>>>>>>>>> limited compatibility break here, where >> > > > >>>>> it is >> > > > >>>>>>>> now >> > > > >>>>>>>>>>>>> required to >> > > > >>>>>>>>>>>>>>>>> escape >> > > > >>>>>>>>>>>>>>>>>>>>> weird >> > > > >>>>>>>>>>>>>>>>>>>>>> consumer group names when creating ACLs >> > > > >>>>> for >> > > > >>>>>>>> them. >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> To future-proof this, we should reserve >> > > > >> a >> > > > >>>>>>>> bunch of >> > > > >>>>>>>>>>>>> characters >> > > > >>>>>>>>>>>>>>> at >> > > > >>>>>>>>>>>>>>>>>> once, >> > > > >>>>>>>>>>>>>>>>>>>>>> like *, @, $, %, ^, &, +, [, ], etc. If >> > > > >>>>> these >> > > > >>>>>>>>>>>> characters >> > > > >>>>>>>>>>>>>>> appear >> > > > >>>>>>>>>>>>>>>>> in >> > > > >>>>>>>>>>>>>>>>>> a >> > > > >>>>>>>>>>>>>>>>>>>>>> resource name, it should be an error, >> > > > >>>>> unless >> > > > >>>>>>>> they >> > > > >>>>>>>>>> are >> > > > >>>>>>>>>>>>> escaped >> > > > >>>>>>>>>>>>>>>>> with a >> > > > >>>>>>>>>>>>>>>>>>>>>> backslash. That way, we can use them in >> > > > >>>>> the >> > > > >>>>>>>>> future. >> > > > >>>>>>>>>>> We >> > > > >>>>>>>>>>>>>>> should >> > > > >>>>>>>>>>>>>>>>>> create a >> > > > >>>>>>>>>>>>>>>>>>>>>> Resource.escapeName function which adds >> > > > >>>>> the >> > > > >>>>>>>>> correct >> > > > >>>>>>>>>>>> escape >> > > > >>>>>>>>>>>>>>>>>> characters to >> > > > >>>>>>>>>>>>>>>>>>>>>> resource names (so it would translate >> > > > >> foo* >> > > > >>>>>>>> into >> > > > >>>>>>>>>> foo\*, >> > > > >>>>>>>>>>>>> foo+bar >> > > > >>>>>>>>>>>>>>>>> into >> > > > >>>>>>>>>>>>>>>>>>>>>> foo\+bar, etc. etc. >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> best, >> > > > >>>>>>>>>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2018, at 17:08, Piyush >> > > > >>>>> Vijay >> > > > >>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>> Colin, >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> createAcls take a AclBinding, however, >> > > > >>>>>>>> instead >> > > > >>>>>>>>> of >> > > > >>>>>>>>>>>>>>>>>> AclBindingFilter. >> > > > >>>>>>>>>>>>>>>>>>>>> What >> > > > >>>>>>>>>>>>>>>>>>>>>>> are your thoughts here? >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> public abstract DescribeAclsResult >> > > > >>>>>>>>>>>>>>> describeAcls(AclBindingFilter >> > > > >>>>>>>>>>>>>>>>>>>>>>> filter, DescribeAclsOptions options); >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> public abstract CreateAclsResult >> > > > >>>>>>>>>>>> createAcls(Collection< >> > > > >>>>>>>>>>>>>>>>>> AclBinding> >> > > > >>>>>>>>>>>>>>>>>>>>>>> acls, CreateAclsOptions options); >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> public abstract DeleteAclsResult >> > > > >>>>>>>>>>>>>>>>>>>>>>> deleteAcls(Collection< >> > > > >> AclBindingFilter> >> > > > >>>>>>>>> filters, >> > > > >>>>>>>>>>>>>>>>>> DeleteAclsOptions >> > > > >>>>>>>>>>>>>>>>>>>>>>> options); >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> Piyush Vijay >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2018 at 9:26 AM, Andy >> > > > >>>>>>>> Coates < >> > > > >>>>>>>>>>>>>>> a...@confluent.io >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>> +1 >> > > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>> On 11 May 2018 at 17:14, Colin >> > > > >> McCabe >> > > > >>>>> < >> > > > >>>>>>>>>>>>> cmcc...@apache.org >> > > > >>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> Hi Andy, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> I see what you mean. I guess my >> > > > >>>>> thought >> > > > >>>>>>>>> here >> > > > >>>>>>>>>> is >> > > > >>>>>>>>>>>>> that >> > > > >>>>>>>>>>>>>>> if the >> > > > >>>>>>>>>>>>>>>>>>>>> fields >> > > > >>>>>>>>>>>>>>>>>>>>>> are >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> private, we can change it later if >> > > > >>>>> we >> > > > >>>>>>>> need >> > > > >>>>>>>>> to. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> I definitely agree that we should >> > > > >>>>> use >> > > > >>>>>>>> the >> > > > >>>>>>>>>> scheme >> > > > >>>>>>>>>>>> you >> > > > >>>>>>>>>>>>>>>>> describe >> > > > >>>>>>>>>>>>>>>>>> for >> > > > >>>>>>>>>>>>>>>>>>>>>> sending >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> ACLs over the wire (just the >> > > > >> string >> > > > >>>>> + >> > > > >>>>>>>>> version >> > > > >>>>>>>>>>>>> number) >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> cheers, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 11, 2018, at 09:39, >> > > > >> Andy >> > > > >>>>>>>> Coates >> > > > >>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> i think I'm agreeing with you. I >> > > > >>>>> was >> > > > >>>>>>>>> merely >> > > > >>>>>>>>>>>>> suggesting >> > > > >>>>>>>>>>>>>>>>> that >> > > > >>>>>>>>>>>>>>>>>>>>> having >> > > > >>>>>>>>>>>>>>>>>>>>>> an >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> additional field that controls >> > > > >>>>> how the >> > > > >>>>>>>>>> current >> > > > >>>>>>>>>>>>> field >> > > > >>>>>>>>>>>>>>> is >> > > > >>>>>>>>>>>>>>>>>>>>>> interpreted is >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> more >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> flexible / extensible in the >> > > > >>>>> future >> > > > >>>>>>>> than >> > > > >>>>>>>>>>> using a >> > > > >>>>>>>>>>>>>>> 'union' >> > > > >>>>>>>>>>>>>>>>>> style >> > > > >>>>>>>>>>>>>>>>>>>>>>>> approach, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> where only one of several >> > > > >> possible >> > > > >>>>>>>> fields >> > > > >>>>>>>>>>> should >> > > > >>>>>>>>>>>>> be >> > > > >>>>>>>>>>>>>>>>>> populated. >> > > > >>>>>>>>>>>>>>>>>>>>> But >> > > > >>>>>>>>>>>>>>>>>>>>>>>> it's a >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> minor thing. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> On 10 May 2018 at 09:29, Colin >> > > > >>>>> McCabe >> > > > >>>>>>>> < >> > > > >>>>>>>>>>>>>>> cmcc...@apache.org >> > > > >>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Andy, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> The issue that I was trying to >> > > > >>>>> solve >> > > > >>>>>>>>> here >> > > > >>>>>>>>>> is >> > > > >>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>> Java >> > > > >>>>>>>>>>>>>>>>> API. >> > > > >>>>>>>>>>>>>>>>>>>>> Right >> > > > >>>>>>>>>>>>>>>>>>>>>>>> now, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> someone can write "new >> > > > >>>>>>>>>>>>> ResourceFilter(ResourceType. >> > > > >>>>>>>>>>>>>>>>>>>>>> TRANSACTIONAL_ID, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> "foo*") and have a >> > > > >>>>> ResourceFilter >> > > > >>>>>>>> that >> > > > >>>>>>>>>>> applies >> > > > >>>>>>>>>>>>> to a >> > > > >>>>>>>>>>>>>>>>>>>>>> Transactional ID >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> named >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> "foo*". This has to continue >> > > > >> to >> > > > >>>>>>>> work, >> > > > >>>>>>>>> or >> > > > >>>>>>>>>>> else >> > > > >>>>>>>>>>>>> we >> > > > >>>>>>>>>>>>>>> have >> > > > >>>>>>>>>>>>>>>>>> broken >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> compatibility. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> I was proposing that there >> > > > >>>>> would be >> > > > >>>>>>>>>>> something >> > > > >>>>>>>>>>>>> like >> > > > >>>>>>>>>>>>>>> a new >> > > > >>>>>>>>>>>>>>>>>>>>> function >> > > > >>>>>>>>>>>>>>>>>>>>>>>> like >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> ResourceFilter.fromPattern( >> > > > >>>>>>>>>>>>>>>>> ResourceType.TRANSACTIONAL_ID, >> > > > >>>>>>>>>>>>>>>>>>>>>> "foo*") >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> which >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> would create a ResourceFilter >> > > > >>>>> that >> > > > >>>>>>>>> applied >> > > > >>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>> transactional >> > > > >>>>>>>>>>>>>>>>>>>>> IDs >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> starting >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> with "foo", rather than >> > > > >>>>>>>> transactional >> > > > >>>>>>>>> IDs >> > > > >>>>>>>>>>>> named >> > > > >>>>>>>>>>>>>>> "foo*" >> > > > >>>>>>>>>>>>>>>>>>>>>> specifically. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it's important >> > > > >>>>>>>> whether the >> > > > >>>>>>>>>>> Java >> > > > >>>>>>>>>>>>> class >> > > > >>>>>>>>>>>>>>> has >> > > > >>>>>>>>>>>>>>>>> an >> > > > >>>>>>>>>>>>>>>>>>>>>> integer, >> > > > >>>>>>>>>>>>>>>>>>>>>>>> an >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> enum, or two string fields. >> > > > >> The >> > > > >>>>>>>>> important >> > > > >>>>>>>>>>>>> thing is >> > > > >>>>>>>>>>>>>>> that >> > > > >>>>>>>>>>>>>>>>>>>>> there's >> > > > >>>>>>>>>>>>>>>>>>>>>> a >> > > > >>>>>>>>>>>>>>>>>>>>>>>> new >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> static function, or new >> > > > >>>>> constructor >> > > > >>>>>>>>>>> overload, >> > > > >>>>>>>>>>>>> etc. >> > > > >>>>>>>>>>>>>>> that >> > > > >>>>>>>>>>>>>>>>>> works >> > > > >>>>>>>>>>>>>>>>>>>>> for >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> patterns >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> rather than literal strings. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2018, at >> > > > >> 03:30, >> > > > >>>>> Andy >> > > > >>>>>>>>>> Coates >> > > > >>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Rather than having name and >> > > > >>>>>>>> pattern >> > > > >>>>>>>>>> fields >> > > > >>>>>>>>>>>> on >> > > > >>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>> ResourceFilter, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> where >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> it’s only valid for one to >> > > > >> be >> > > > >>>>>>>> set, and >> > > > >>>>>>>>>> we >> > > > >>>>>>>>>>>>> want to >> > > > >>>>>>>>>>>>>>>>>> restrict >> > > > >>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> character >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> set in case future >> > > > >>>>> enhancements >> > > > >>>>>>>> need >> > > > >>>>>>>>>> them, >> > > > >>>>>>>>>>>> we >> > > > >>>>>>>>>>>>>>> could >> > > > >>>>>>>>>>>>>>>>>> instead >> > > > >>>>>>>>>>>>>>>>>>>>>> add a >> > > > >>>>>>>>>>>>>>>>>>>>>>>> new >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> integer ‘nameType’ field, >> > > > >> and >> > > > >>>>> use >> > > > >>>>>>>>>>> constants >> > > > >>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>> indicate >> > > > >>>>>>>>>>>>>>>>>> how >> > > > >>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>> name >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> field should be interpreted, >> > > > >>>>> e.g. >> > > > >>>>>>>> 0 = >> > > > >>>>>>>>>>>>> literal, 1 = >> > > > >>>>>>>>>>>>>>>>>> wildcard. >> > > > >>>>>>>>>>>>>>>>>>>>>> This >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> would >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> be extendable, e.g we can >> > > > >>>>> later >> > > > >>>>>>>> add 2 >> > > > >>>>>>>>> = >> > > > >>>>>>>>>>>>> regex, or >> > > > >>>>>>>>>>>>>>> what >> > > > >>>>>>>>>>>>>>>>>> ever, >> > > > >>>>>>>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> wouldn’t require any >> > > > >> escaping. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> This is very user-unfriendly, >> > > > >>>>>>>> though. >> > > > >>>>>>>>>> Users >> > > > >>>>>>>>>>>>> don't >> > > > >>>>>>>>>>>>>>> want >> > > > >>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>> have >> > > > >>>>>>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> explicitly supply a version >> > > > >>>>> number >> > > > >>>>>>>> when >> > > > >>>>>>>>>>> using >> > > > >>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>> API, >> > > > >>>>>>>>>>>>>>>>>> which >> > > > >>>>>>>>>>>>>>>>>>>>> is >> > > > >>>>>>>>>>>>>>>>>>>>>> what >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> this >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> would force them to do. I >> > > > >> don't >> > > > >>>>>>>> think >> > > > >>>>>>>>>> users >> > > > >>>>>>>>>>>> are >> > > > >>>>>>>>>>>>>>> going >> > > > >>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>> want to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> memorize >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> that version 4 supprted "+", >> > > > >>>>> whereas >> > > > >>>>>>>>>>> version 3 >> > > > >>>>>>>>>>>>> only >> > > > >>>>>>>>>>>>>>>>>> supported >> > > > >>>>>>>>>>>>>>>>>>>>>>>> "[0-9]", >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> or >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> whatever. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Just as an example, do you >> > > > >>>>> remember >> > > > >>>>>>>>> which >> > > > >>>>>>>>>>>>> versions >> > > > >>>>>>>>>>>>>>> of >> > > > >>>>>>>>>>>>>>>>>>>>>> FetchRequest >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> added >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> which features? I don't. I >> > > > >>>>> always >> > > > >>>>>>>> have >> > > > >>>>>>>>>> to >> > > > >>>>>>>>>>>>> look at >> > > > >>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>> code >> > > > >>>>>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> remember. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Also, escaping is still >> > > > >>>>> required any >> > > > >>>>>>>>> time >> > > > >>>>>>>>>>> you >> > > > >>>>>>>>>>>>>>> overload a >> > > > >>>>>>>>>>>>>>>>>>>>>> character to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> mean >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> two things. Escaping is >> > > > >>>>> required >> > > > >>>>>>>> in the >> > > > >>>>>>>>>>>> current >> > > > >>>>>>>>>>>>>>>>> proposal >> > > > >>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>> be >> > > > >>>>>>>>>>>>>>>>>>>>>> able >> > > > >>>>>>>>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> create a pattern that matches >> > > > >>>>> only >> > > > >>>>>>>>> "foo*". >> > > > >>>>>>>>>>>> You >> > > > >>>>>>>>>>>>>>> have to >> > > > >>>>>>>>>>>>>>>>>> type >> > > > >>>>>>>>>>>>>>>>>>>>>> "foo\*" >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> It >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> would be required if we forced >> > > > >>>>>>>> users to >> > > > >>>>>>>>>>>> specify >> > > > >>>>>>>>>>>>> a >> > > > >>>>>>>>>>>>>>>>>> version, as >> > > > >>>>>>>>>>>>>>>>>>>>>> well. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> best, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7 May 2018, at 05:16, >> > > > >>>>> Piyush >> > > > >>>>>>>>> Vijay >> > > > >>>>>>>>>> < >> > > > >>>>>>>>>>>>>>>>>>>>>> piyushvij...@gmail.com> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Makes sense. I'll update >> > > > >> the >> > > > >>>>>>>> KIP. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Does anyone have any other >> > > > >>>>>>>> comments? >> > > > >>>>>>>>>> :) >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Piyush Vijay >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 3, 2018 at >> > > > >>>>> 11:55 >> > > > >>>>>>>> AM, >> > > > >>>>>>>>>> Colin >> > > > >>>>>>>>>>>>> McCabe < >> > > > >>>>>>>>>>>>>>>>>>>>>>>> cmcc...@apache.org >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah, I guess that's a >> > > > >> good >> > > > >>>>>>>> point. >> > > > >>>>>>>>>> It >> > > > >>>>>>>>>>>>> probably >> > > > >>>>>>>>>>>>>>>>> makes >> > > > >>>>>>>>>>>>>>>>>>>>> sense >> > > > >>>>>>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> support the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prefix scheme for >> > > > >> consumer >> > > > >>>>>>>> groups >> > > > >>>>>>>>> and >> > > > >>>>>>>>>>>>>>> transactional >> > > > >>>>>>>>>>>>>>>>>> IDs >> > > > >>>>>>>>>>>>>>>>>>>>> as >> > > > >>>>>>>>>>>>>>>>>>>>>> well >> > > > >>>>>>>>>>>>>>>>>>>>>>>> as >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> topics. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree that the current >> > > > >>>>>>>> situation >> > > > >>>>>>>>>>> where >> > > > >>>>>>>>>>>>>>> anything >> > > > >>>>>>>>>>>>>>>>>> goes in >> > > > >>>>>>>>>>>>>>>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> group >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> names and transactional >> > > > >> ID >> > > > >>>>>>>> names is >> > > > >>>>>>>>>> not >> > > > >>>>>>>>>>>>>>> ideal. I >> > > > >>>>>>>>>>>>>>>>>> wish we >> > > > >>>>>>>>>>>>>>>>>>>>>> could >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> rewind the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clock and impose >> > > > >>>>> restrictions >> > > > >>>>>>>> on >> > > > >>>>>>>>> the >> > > > >>>>>>>>>>>> names. >> > > > >>>>>>>>>>>>>>>>>> However, it >> > > > >>>>>>>>>>>>>>>>>>>>>> doesn't >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> seem >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> practical at the moment. >> > > > >>>>>>>> Adding >> > > > >>>>>>>>> new >> > > > >>>>>>>>>>>>>>> restrictions >> > > > >>>>>>>>>>>>>>>>>> would >> > > > >>>>>>>>>>>>>>>>>>>>>> break a >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> lot of >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> existing users after an >> > > > >>>>>>>> upgrade. >> > > > >>>>>>>>> It >> > > > >>>>>>>>>>>> would >> > > > >>>>>>>>>>>>> be a >> > > > >>>>>>>>>>>>>>>>>> really >> > > > >>>>>>>>>>>>>>>>>>>>> bad >> > > > >>>>>>>>>>>>>>>>>>>>>>>> upgrade >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> experience. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> However, I think we can >> > > > >>>>> support >> > > > >>>>>>>>> this >> > > > >>>>>>>>>>> in a >> > > > >>>>>>>>>>>>>>>>> compatible >> > > > >>>>>>>>>>>>>>>>>> way. >> > > > >>>>>>>>>>>>>>>>>>>>>> From >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> perspective of >> > > > >>>>> AdminClient, we >> > > > >>>>>>>> just >> > > > >>>>>>>>>>> have >> > > > >>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>> add a >> > > > >>>>>>>>>>>>>>>>> new >> > > > >>>>>>>>>>>>>>>>>>>>> field >> > > > >>>>>>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ResourceFilter. >> > > > >>>>> Currently, it >> > > > >>>>>>>> has >> > > > >>>>>>>>>> two >> > > > >>>>>>>>>>>>> fields, >> > > > >>>>>>>>>>>>>>>>>>>>> resourceType >> > > > >>>>>>>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> name: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /** >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * A filter which matches >> > > > >>>>>>>> Resource >> > > > >>>>>>>>>>>> objects. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * The API for this class >> > > > >>>>> is >> > > > >>>>>>>> still >> > > > >>>>>>>>>>>> evolving >> > > > >>>>>>>>>>>>>>> and we >> > > > >>>>>>>>>>>>>>>>>> may >> > > > >>>>>>>>>>>>>>>>>>>>> break >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility in minor >> > > > >>>>>>>> releases, if >> > > > >>>>>>>>>>>>> necessary. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> */ >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>> @InterfaceStability.Evolving >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public class >> > > > >>>>> ResourceFilter { >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> private final >> > > > >>>>> ResourceType >> > > > >>>>>>>>>>>>> resourceType; >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> private final String >> > > > >>>>> name; >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We can add a third field, >> > > > >>>>>>>> pattern. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So the API will basically >> > > > >>>>> be, >> > > > >>>>>>>> if I >> > > > >>>>>>>>>>>> create a >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> ResourceFilter(resourceType=GR >> > > > >>>>> OUP, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name=foo*, pattern=null), >> > > > >>>>> it >> > > > >>>>>>>>> applies >> > > > >>>>>>>>>>> only >> > > > >>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>>>>>>>>>>> group >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> named >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "foo*". If I create a >> > > > >>>>>>>>>>>>>>>>> ResourceFilter(resourceType=GR >> > > > >>>>>>>>>>>>>>>>>>>>> OUP, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> name=null, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern=foo*), it applies >> > > > >>>>> to >> > > > >>>>>>>> any >> > > > >>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>> group >> > > > >>>>>>>>>>>>>>>>>> starting >> > > > >>>>>>>>>>>>>>>>>>>>> in >> > > > >>>>>>>>>>>>>>>>>>>>>>>> "foo". >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> name >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and pattern cannot be >> > > > >> both >> > > > >>>>> set >> > > > >>>>>>>> at >> > > > >>>>>>>>> the >> > > > >>>>>>>>>>>> same >> > > > >>>>>>>>>>>>>>> time. >> > > > >>>>>>>>>>>>>>>>>> This >> > > > >>>>>>>>>>>>>>>>>>>>>> preserves >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility at the >> > > > >>>>>>>> AdminClient >> > > > >>>>>>>>>> level. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's possible that we >> > > > >> will >> > > > >>>>>>>> want to >> > > > >>>>>>>>>> add >> > > > >>>>>>>>>>>> more >> > > > >>>>>>>>>>>>>>> types >> > > > >>>>>>>>>>>>>>>>> of >> > > > >>>>>>>>>>>>>>>>>>>>>> pattern in >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> future. So we should >> > > > >>>>> reserve >> > > > >>>>>>>>>> "special >> > > > >>>>>>>>>>>>>>> characters" >> > > > >>>>>>>>>>>>>>>>>> such >> > > > >>>>>>>>>>>>>>>>>>>>> as >> > > > >>>>>>>>>>>>>>>>>>>>>> +, /, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> &, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> %, #, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $, etc. These characters >> > > > >>>>>>>> should be >> > > > >>>>>>>>>>>>> treated as >> > > > >>>>>>>>>>>>>>>>>> special >> > > > >>>>>>>>>>>>>>>>>>>>>> unless >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> they are >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prefixed with a backslash >> > > > >>>>> to >> > > > >>>>>>>> escape >> > > > >>>>>>>>>>> them. >> > > > >>>>>>>>>>>>> This >> > > > >>>>>>>>>>>>>>>>> will >> > > > >>>>>>>>>>>>>>>>>>>>> allow >> > > > >>>>>>>>>>>>>>>>>>>>>> us to >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> add >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> support for using these >> > > > >>>>>>>> characters >> > > > >>>>>>>>> in >> > > > >>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>> future >> > > > >>>>>>>>>>>>>>>>>> without >> > > > >>>>>>>>>>>>>>>>>>>>>>>> breaking >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> At the protocol level, we >> > > > >>>>> need >> > > > >>>>>>>> a >> > > > >>>>>>>>> new >> > > > >>>>>>>>>>> API >> > > > >>>>>>>>>>>>>>> version >> > > > >>>>>>>>>>>>>>>>> for >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> CreateAclsRequest / >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> DeleteAclsRequest. The >> > > > >>>>> new API >> > > > >>>>>>>>>> version >> > > > >>>>>>>>>>>>> will >> > > > >>>>>>>>>>>>>>> send >> > > > >>>>>>>>>>>>>>>>> all >> > > > >>>>>>>>>>>>>>>>>>>>>> special >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> characters >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> over the wire escaped >> > > > >>>>> rather >> > > > >>>>>>>> than >> > > > >>>>>>>>>>>> directly. >> > > > >>>>>>>>>>>>>>> (So >> > > > >>>>>>>>>>>>>>>>>> there >> > > > >>>>>>>>>>>>>>>>>>>>> is no >> > > > >>>>>>>>>>>>>>>>>>>>>>>> need >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> for >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> equivalent of both "name" >> > > > >>>>> and >> > > > >>>>>>>>>>> "pattern"-- >> > > > >>>>>>>>>>>>> we >> > > > >>>>>>>>>>>>>>>>>> translate >> > > > >>>>>>>>>>>>>>>>>>>>> name >> > > > >>>>>>>>>>>>>>>>>>>>>>>> into a >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> validly >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> escaped pattern that >> > > > >>>>> matches >> > > > >>>>>>>> only >> > > > >>>>>>>>> one >> > > > >>>>>>>>>>>>> thing, by >> > > > >>>>>>>>>>>>>>>>>> adding >> > > > >>>>>>>>>>>>>>>>>>>>>> escape >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> characters as >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> appropriate.) The broker >> > > > >>>>> will >> > > > >>>>>>>>>> validate >> > > > >>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>> new API >> > > > >>>>>>>>>>>>>>>>>>>>> version >> > > > >>>>>>>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> reject >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> malformed of unsupported >> > > > >>>>>>>> patterns. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> At the ZK level, we can >> > > > >>>>>>>> introduce a >> > > > >>>>>>>>>>>>> protocol >> > > > >>>>>>>>>>>>>>>>> version >> > > > >>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>> data >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> in >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> ZK-- >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or store it under a >> > > > >>>>> different >> > > > >>>>>>>> root. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> best, >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Colin >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2018, at >> > > > >>>>> 18:09, >> > > > >>>>>>>>>> Piyush >> > > > >>>>>>>>>>>>> Vijay >> > > > >>>>>>>>>>>>>>> wrote: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you everyone for >> > > > >> the >> > > > >>>>>>>>> interest >> > > > >>>>>>>>>>> and, >> > > > >>>>>>>>>>>>>>> prompt >> > > > >>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>> valuable >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> feedback. I >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> really appreciate the >> > > > >>>>> quick >> > > > >>>>>>>>>>> turnaround. >> > > > >>>>>>>>>>>>> I’ve >> > > > >>>>>>>>>>>>>>> tried >> > > > >>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>> organize >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> the >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comments >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into common headings. >> > > > >> See >> > > > >>>>> my >> > > > >>>>>>>>> replies >> > > > >>>>>>>>>>>>> below: >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Case of ‘*’ might >> > > > >>>>> already be >> > > > >>>>>>>>>> present >> > > > >>>>>>>>>>> in >> > > > >>>>>>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>>>>>>> groups >> > > > >>>>>>>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> transactional >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ids* >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - We definitely need >> > > > >>>>>>>> wildcard >> > > > >>>>>>>>> ACLs >> > > > >>>>>>>>>>>>> support >> > > > >>>>>>>>>>>>>>> for >> > > > >>>>>>>>>>>>>>>>>>>>> resources >> > > > >>>>>>>>>>>>>>>>>>>>>> like >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> consumer >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> groups and >> > > > >> transactional >> > > > >>>>>>>> ids for >> > > > >>>>>>>>>> the >> > > > >>>>>>>>>>>>> reason >> > > > >>>>>>>>>>>>>>> Andy >> > > > >>>>>>>>>>>>>>>>>>>>>> mentioned. A >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> big >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>> win >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this feature is that >> > > > >>>>> service >> > > > >>>>>>>>>>> providers >> > > > >>>>>>>>>>>>> don’t >> > > > >>>>>>>>>>>>>>>>> have >> > > > >>>>>>>>>>>>>>>>>> to >> > > > >>>>>>>>>>>>>>>>>>>>>> track >> > > > >>>>>>>>>>>>>>>>>>>>>>>> and >> > > > >>>>>>>>>>>>>>>>>>>>>>>>> keep >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> up-to-date all the >> > > > >>>>> consumer >> > > > >>>>>>>>> groups >> > > > >>>>>>>>>>>> their >> > > > >>>>>>>>>>>>>>>>>> customers are >> > > > >>>>>>>>>>>>>>>>>>>>>> using. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - I agree with Andy’s >> > > > >>>>>>>> thoughts >> > > > >>>>>>>>> on >> > > > >>>>>>>>>>> the >> > > > >>>>>>>>>>>>> two >> > > > >>>>>>>>>>>>>>>>> possible >> > > > >>>>>>>>>>>>>>>>>>>>> ways. >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - My vote would be to >> > > > >>>>> do the >> > > > >>>>>>>>>>> breaking >> > > > >>>>>>>>>>>>> change >> > > > >>>>>>>>>>>>>>>>>> because >> > > > >>>>>>>>>>>>>>>>>>>>> we >> > > > >>>>>>>>>>>>>>>>>>>>>>>> should >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> restrict >> > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the format of consumer >> > > > >>>>>>>> groups >> > > > >>>>>>>>> and >> > > > >>>>>>>>>>>>>>> transactional >> > > > >>>>>>>>>>>>>>>>>> ids >> > > > >>>>>>>>>>>>>>>>>>>>>> sooner >> > > > >>>>>>>>>>>>>>>>>>>> >> > > > >>>>> >> > > > >>>> ... >> > > > >>> >> > > > >>> [Message clipped] >> > > > >> >> > > > >> > > >> > >
