If there are no other concerns or suggestions, I will start vote on this KIP later today.
Thanks, Rajini On Mon, Feb 18, 2019 at 10:09 AM Rajini Sivaram <rajinisiva...@gmail.com> wrote: > 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 >> > > > >> > > >> >
