+1. under ismael's "facet" approach we could always start with AdminClient.topics() and then pile on more of them later.
On Tue, Feb 7, 2017 at 8:57 AM, Grant Henke <ghe...@cloudera.com> wrote: > +1 I think its important to focus this KIP discussion on the "patterns" we > would like to see in the client and a few key methods in order to make > progress and then iterate from there. > > I think we should let Colin drive the APIs he thinks are important since he > is volunteering to do the work. And then others can propose and add APIs > from there. > > On Tue, Feb 7, 2017 at 10:37 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > 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 > > > > > > -- > Grant Henke > Software Engineer | Cloudera > gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke >
