Rajini
Thanks for putting this together. It is looking good. I have few questions...
1. List<AuthorizationResult> authorize(..., List<Action> actions). Do you see
a scenario where the broker will call authorize for multiple topics at the same
time? I can understand that during creating/deleting ACLS, multiple permissions
for multiple resources might be done. For authorize call, would this be a case?
And does the Authorize implementation will be able to do performance
optimization because of this? Or should we just keep it simple? I don't see it
as an issue from Apache Ranger side, but just checking to see whether we need
to be aware of something.
2. Should I assume that the SecurityProtocol passed during start and the one
return by KafkaRequestContext.securityProtocol() will be the same?
CompletableFuture<Void> start(String listenerName, SecurityProtocol
securityProtocol);
KafkaRequestContext.securityProtocol()
3. What is the purpose of AuthorizationMode? How does the broker decide what
mode to use when the authorize() method is called?
4. Can we clarify "count" in Action a bit more? How is it used?
5. Do you feel having "stop" along with "start" be helpful? E.g. In Ranger we
try to optimize the Audit writing by caching the logs for a fixed interval. But
when the Broker terminates, we do a forced flush. Having an explicit "stop"
might give us a formal way to flush our audits.
Thanks
Bosco
On 8/7/19, 3:59 PM, "Rajini Sivaram" <rajinisiva...@gmail.com> wrote:
Hi Ron/Harsha/Satish,
Thanks for reviewing the KIP!
We should perhaps have a wider discussion outside this KIP for refactoring
clients so that others who are not following this KIP also notice the
discussion. Satish, would you like to start a discussion thread on dev?
Regards,
Rajini
On Wed, Aug 7, 2019 at 6:21 PM Satish Duggana <satish.dugg...@gmail.com>
wrote:
> I felt the same need when we want to add a pluggable API for core
> server functionality. This does not need to be part of this KIP, it
> can be a separate KIP. I can contribute those refactoring changes if
> others are OK with that.
>
> It is better to have a structure like below.
>
> kafka-common:
> common classes which can be used in any of the other modules in Kafka
> like client, Kafka-server-common and server etc.
>
> kafka-client-common:
> common classes which can be used in the client module. This can be
> part of client module itself.
>
> kafka-server-common:
> classes required only for kafka-server.
>
> Thanks.
> Satish.
>
> On Wed, Aug 7, 2019 at 9:28 PM Harsha Chintalapani <ka...@harsha.io>
> wrote:
> >
> > Thanks for the KIP Rajini.
> > Quick thought, it would be good to have a common module outside of
> clients
> > that only applies to server side interfaces & changes. It looks like we
> are
> > increasingly in favor of using Java interface for pluggable modules on
> the
> > broker side.
> >
> > Thanks,
> > Harsha
> >
> >
> > On Tue, Aug 06, 2019 at 2:31 PM, Rajini Sivaram <rajinisiva...@gmail.com
> >
> > wrote:
> >
> > > Hi all,
> > >
> > > I have created a KIP to replace the Scala Authorizer API with a new
> Java
> > > API:
> > >
> > > -
> > > https://cwiki.apache.org/confluence/display/KAFKA/
> > > KIP-504+-+Add+new+Java+Authorizer+Interface
> > >
> > > This is replacement for KIP-50 which was accepted but never merged.
> Apart
> > > from moving to a Java API consistent with other pluggable interfaces
> in the
> > > broker, KIP-504 also attempts to address known limitations in the
> > > authorizer. If you have come across other limitations that you would
> like
> > > to see addressed in the new API, please raise these on the discussion
> > > thread so that we can consider those too. All suggestions and feedback
> are
> > > welcome.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
>
