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]
>>
