+1 non binding

On Mon., 21 May 2018, 2:44 pm 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
> > >>>>>>>>>>>>>>> s

Reply via email to