Hi all, I think it's good that we have discussed a number of API that would make sense in the AdminClient. Having done that, I think we should now narrow the focus of this KIP to a small set of methods to get us started. Once we have an AdminClient in the codebase, we can propose subsequent KIPs to enrich it. I would suggest the following:
1. Let's focus on topic management operations: describe, create, alter and delete topics. 2. Let's add an @Unstable annotation to the class and specify in the javadoc that the methods are subject to change (if necessary). Thoughts? Ismael On Fri, Feb 3, 2017 at 6:24 PM, Colin McCabe <cmcc...@apache.org> wrote: > On Thu, Feb 2, 2017, at 21:45, Becket Qin wrote: > > Hi Colin, > > > > Thanks for the KIP. An admin client is probably a must after we block > > direct access to ZK. Some comments and thoughts below: > > > > 1. Do we have a clear scope for the admin client? It might be worth > > thinking about the entire user experience of the admin client. Ideally we > > may want to have a single client to do all the administrative work > > instead > > of having multiple ways to do different things. For example, do we want > > to > > add topic configurations change API in the admin client? What about > > partition movements and preferred leader election? Those are also > > administrative tasks which seem reasonable to be integrated into the > > admin > > client. > > Thanks for the comments, Becket! > > I agree that topic configuration change should be in the administrative > client. I have not thought about partition movement or preferred leader > election. It probably makes sense to put them in the client as well, > but we should probably have a longer discussion about those features > later when someone is ready to implement them ;) > > best, > Colin
