Hi Magnus, Have your concerns been addressed in the KIP?
Thanks, Rajini On Wed, Feb 13, 2019 at 3:33 PM Satish Duggana <satish.dugg...@gmail.com> wrote: > Hi Rajini, > That makes sense, thanks for the clarification. > > Satish. > > On Wed, Feb 13, 2019 at 7:30 PM Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > > Thanks for the reviews! > > > > Hi Satish, > > > > The authorised operations returned will use the same values as the > > operations returned by the existing DescribeAclsResponse. AdminClient > will > > return these using the existing enum AclOperation. > > > > Hi Magnus, > > > > The MetadataResponse contains these two lines: > > > > - Metadata Response => throttle_time_ms [brokers] cluster_id > > controller_id [topic_metadata] [authorized_operations] <== ADDED > > authorized_operations > > - topic_metadata => error_code topic is_internal [partition_metadata] > > [authorized_operations] <== ADDED authorized_operations > > > > The first is for the cluster's authorized operations and the second for > > each topic. Did I misunderstand your question? The full set of operations > > for each resource type is included in the subsection `AdminClient API > > Changes`. > > > > Under `Rejected Alternatives` I have included addition of a separate > > request to get this information rather than extend an existing one. The > > rationale for including all the information in one request is to enable > > clients to get all relevant metadata using a single API rather than have > to > > send multiple requests, get responses and combine the two while resource > or > > ACLs may have changed in between. It seems neater to use a single API > since > > a user getting authorized operations is almost definitely going to do a > > Describe first and access control for both of these is controlled using > > Describe access. If we add new resource types with a corresponding > > Describe, we would simply need to add `authorized_operations` for their > > Describe. > > > > Hi Manikumar, > > > > Added IdempotentWrite for Cluster, thanks for pointing that out! I was > > thinking that if authorizer is not configured, we could return all > > supported operations since the user can perform all operations. Added a > > note to the KIP. > > > > Regards, > > > > Rajini > > > > > > > > On Wed, Feb 13, 2019 at 11:07 AM Manikumar <manikumar.re...@gmail.com> > > wrote: > > > > > Hi, > > > > > > Thanks for the KIP. > > > > > > 1. Can't we include IdempotentWrite/ClusterResource Operations for > Cluster > > > resource. > > > 2. What will be the API behaviour when the authorizer is not > configured?. I > > > assume we return empty list. > > > > > > Thanks, > > > Manikumar > > > > > > On Wed, Feb 13, 2019 at 12:33 AM Rajini Sivaram < > rajinisiva...@gmail.com> > > > wrote: > > > > > > > Hi all, > > > > > > > > I have created a KIP to optionally request authorised operations on > > > > resources when describing resources: > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-430+-+Return+Authorized+Operations+in+Describe+Responses > > > > > > > > This includes only information that users with Describe access can > obtain > > > > using other means and hence is consistent with our security model. > It is > > > > intended to made it easier for clients to obtain this information. > > > > > > > > Feedback and suggestions welcome. > > > > > > > > Thank you, > > > > > > > > Rajini > > > > > > > >
