+1
-------- Original message --------From: Stephane Maarek
<steph...@simplemachines.com.au> Date: 5/21/18 3:15 AM (GMT-08:00) To:
dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-290: Support for wildcard
suffixed ACLs
+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,
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>
