On Wed, May 10, 2017, at 17:41, Jason Gustafson wrote:
> >
> > Hmm... I agree that the request is invalid, but it's invalid because the
> > version is not supported. I guess I think UnsupportedVersionException
> > is a very specific exception that tells users exactly what is wrong
> > (aha! it's t
>
> Hmm... I agree that the request is invalid, but it's invalid because the
> version is not supported. I guess I think UnsupportedVersionException
> is a very specific exception that tells users exactly what is wrong
> (aha! it's the version!) whereas InvalidRequestException is kind of a
> gener
On Wed, May 10, 2017, at 15:54, Jason Gustafson wrote:
> Hey Colin,
>
> Thanks, I think continuing to bump the protocol makes sense. It's nice to
> be consistent with the other APIs. In the KIP, you have the following:
>
> > If the client is newer than the broker, some of the fields may show up a
Hey Colin,
Thanks, I think continuing to bump the protocol makes sense. It's nice to
be consistent with the other APIs. In the KIP, you have the following:
> If the client is newer than the broker, some of the fields may show up as
UNKNOWN on the broker side. In this case, the filter will get an
Hi Jason,
Thanks for taking a look.
I think it's likely that we will bump the ApiVersion of the various
requests if we add a new resource type, operation type, or permission
type. Although it may not strictly be required, bumping the version
number makes it a little bit clearer that the protocol
Hi Colin,
Thanks for the KIP. Looks good overall. One thing I wasn't too clear about
is whether new resource types, operations, or permissions require a version
bump for the three new request types. On reading the proposal, it sort of
sounds like the intent is not to bump the versions and let the
Thanks for the KIP, +1(binding) from me. Colin, it may make sense to start
a new thread for this as GMail is currently hiding it in the middle of the
discuss thread. Please mention the date the thread was started along with
the 3 +1s (1 binding) so far.
Ismael
On Sat, Apr 29, 2017 at 1:09 AM, Col
Hi Colin,
Comments inline.
On Tue, May 9, 2017 at 10:37 PM, Colin McCabe wrote:
> On Tue, May 9, 2017, at 08:00, Ismael Juma wrote:
> Good question. I guess the answer is that I couldn't come up with any
> per-element error codes in DescribeAclsResponse.
Thanks for the explanation.
>
> > 2.
value) and "any". For example, when your deletionFilter has
> > > > > principal="User:*" you are not deleting ACLs for all users. Just
> > ACLs
> > > > > that have the principal field set to "User:*" If you want to delete
> > > > > ACL
> > > principal="User:*" you are not deleting ACLs for all users. Just
> ACLs
> > > > that have the principal field set to "User:*" If you want to delete
> > > > ACLs for all users, you can use principal=null. Similarly,
> > >
actual ACL that is
> > > applied to a resource.
> > >
> > > best,
> > > Colin
> > >
> > > >
> > > > Otherwise, lgtm!
> > > >
> > > >
> > > > Guozhang
> > > >
>
> principal=null is only valid in a filter, not in an actual ACL that is
> > applied to a resource.
> >
> > best,
> > Colin
> >
> > >
> > > Otherwise, lgtm!
> > >
> > >
> > > Guozhang
> > >
> > >
>
t;
> > Otherwise, lgtm!
> >
> >
> > Guozhang
> >
> >
> > On Fri, Apr 28, 2017 at 10:37 PM, Dongjin Lee wrote:
> >
> > > +1
> > >
> > > On 29 Apr 2017, 9:51 AM +0900, Michael Pearce ,
> > > wrote:
> &
hang
>
>
> On Fri, Apr 28, 2017 at 10:37 PM, Dongjin Lee wrote:
>
> > +1
> >
> > On 29 Apr 2017, 9:51 AM +0900, Michael Pearce ,
> > wrote:
> > > +1
> > > ________________
> > > From: Colin McCabe > > Se
Saturday, April 29, 2017 1:09:25 AM
> > To: dev@kafka.apache.org
> > Subject: [VOTE] KIP-140: Add administrative RPCs for adding, deleting,
> and listing ACLs
> >
> > Hi all,
> >
> > I'd like to start the voting for KIP-140: Add administrative RPCs for
>
+1
On 29 Apr 2017, 9:51 AM +0900, Michael Pearce , wrote:
> +1
>
> From: Colin McCabe Sent: Saturday, April 29, 2017 1:09:25 AM
> To: dev@kafka.apache.org
> Subject: [VOTE] KIP-140: Add administrative RPCs for adding, deleting, and
> l
+1
From: Colin McCabe
Sent: Saturday, April 29, 2017 1:09:25 AM
To: dev@kafka.apache.org
Subject: [VOTE] KIP-140: Add administrative RPCs for adding, deleting, and
listing ACLs
Hi all,
I'd like to start the voting for KIP-140: Add administrative
Hi all,
I'd like to start the voting for KIP-140: Add administrative RPCs for
adding, deleting, and listing ACLs. This provides an API for adding,
deleting, and listing the access control lists (ACLs) which are used to
control access on Kafka topics and brokers.
The wiki page is here:
https://cw
18 matches
Mail list logo
