Based on the initial discussion here, and the draft KIP-133, it sounds like the plan is to have AdminClient APIs like: addAcls, removeAcls, listAcls, listConfig, changeConfig (roughly speaking).
However, just to play devil's advocate here a bit, wouldn't AdminClient users find it more natural to view all of those things as topic modifications or descriptions? For example, why can't I find the configuration or ACLs applied to topics when calling describeTopics? Why can't I have an alterTopics API that can alter both ACLs and configuration? And if we decide to have APIs like that, shouldn't we have AlterTopicsRequest and DescribeTopicsRequest instead of ListAclsRequest, ListConfigurationRequest, AlterAclsRequest, AlterConfigurationRequest? I'm curious which approach seems better. cheers, Colin On Thu, Apr 13, 2017, at 14:38, Ismael Juma wrote: > Hi Colin, > > Thanks for coordinating with Grant and reviving this. I agree that having > a > separate delete request makes sense. This also came up in the original > discussion thread and I think people were in favour. > > Ismael > > On 13 Apr 2017 10:21 pm, "Colin McCabe" <cmcc...@apache.org> wrote: > > > Hi all, > > > > KIP-4 described some RPCs for implementing centralized administrative > > operations for Kafka. Now that the adminclient work is going forward, > > I'd like to re-open the discussion about the ACL-related RPCs. This is > > a continuation of the email thread Grant Henke started while back. (See > > http://search-hadoop.com/m/Kafka/uyzND18EGG22cFMXg?subj=+ > > DISCUSS+KIP+4+ACL+Admin+Schema > > ) > > > > I think the idea of sending a batch of ACL-related operations all at > > once is good for efficiency. However, I wonder if it is simpler to > > separate the add and remove ACLs operations, or if we really ought to > > combine them into one RP It seems that when both add and remove > > operations are combined into one RPC, there are some thorny questions > > about ordering (does a delete ACL operation on a topic happen first, or > > an add ACL operation?) > > > > best, > > Colin > >
