Thanks for looking at the KIP, Manikumar.
On Mon, Jan 31, 2022, at 11:21, Manikumar wrote:
> Thanks for the KIP. LGTM once we get consensus on bootstrapping logic.
>
The current plan for bootstrapping is to use super.users for now. Later, we'll
have a separate KIP that will allow us to bootstrap
Thanks for the KIP. LGTM once we get consensus on bootstrapping logic.
1. When do we say, ACL is created (or deleted)? Is it after we persist it
durably by a majority of peers?.
2. Can we add a metric for total acl count (This was missing in ZK
Authoriser).
On Thu, Jan 13, 2022 at 2:26 AM David A
Sounds good on the ordering, and yea I agree we can look at atomic ACL
modifications in the future. Thanks!
On Wed, Jan 12, 2022 at 3:53 PM Colin McCabe wrote:
> Hi David,
>
> On Wed, Dec 15, 2021, at 07:28, David Arthur wrote:
> > 5) Ok, gotcha. So will the StandardAuthorizer be replaying recor
Hi David,
On Wed, Dec 15, 2021, at 07:28, David Arthur wrote:
> 5) Ok, gotcha. So will the StandardAuthorizer be replaying records
> directly, or will it get an *Image like other metadata consumers on the
> broker?
>
It reads the information out of the MetadataDelta, being careful to preserve
th
5) Ok, gotcha. So will the StandardAuthorizer be replaying records
directly, or will it get an *Image like other metadata consumers on the
broker?
6) I was thinking since the CreateAcl and DeleteAcl requests can modify
multiple ACL in one request, that we should reflect that by committing the
resu
On Tue, Dec 14, 2021, at 10:13, David Arthur wrote:
> Thanks for the KIP, Colin!
>
> 4) For the various "Type" fields in the AccessControlEntityRecord, is it
> worth explicitly enumerating the allowed types in the KIP? E.g.,
> PermissionType = {Any, Deny, Allow}. If these are listed out in another
On Tue, Dec 14, 2021, at 08:27, José Armando García Sancio wrote:
> Thanks for the additional information Colin.
>
...
>
> It sounds to me like KIP-801 is assuming that this "bootstrapping KIP"
> will at least generate a snapshot with this information in all of the
> controllers. I would like to un
Thanks for the KIP, Colin!
4) For the various "Type" fields in the AccessControlEntityRecord, is it
worth explicitly enumerating the allowed types in the KIP? E.g.,
PermissionType = {Any, Deny, Allow}. If these are listed out in another
KIP, maybe we can just reference that.
5) You mention "Stand
Thanks for the additional information Colin.
On Mon, Dec 13, 2021 at 4:43 PM Colin McCabe wrote:
>
> Hi José,
>
> I think these are good questions. We have a few situations like this where
> there is something brokers have to know before they can contact the
> controller quorum -- or something
Hi José,
I think these are good questions. We have a few situations like this where
there is something brokers have to know before they can contact the controller
quorum -- or something controllers have to know before they can accept broker
connections. Basically, the bootstrapping problem.
Of
Hi Colin,
Thanks for the KIP.
1. Can you talk about how the set of ACLs needed to authorize
controllers and brokers will get bootstrapped? I am particularly
interested in how we are going to configure a new cluster so that the
controllers nodes can authorize each other's requests to establish
quo
Hi all,
I have written a new KIP describing an Authorizer that stores data in the
__cluster_metadata topic. It is designed to be used in KRaft mode. Please take
a look here: https://cwiki.apache.org/confluence/x/h5KqCw
best,
Colin
12 matches
Mail list logo
