+1
> On Feb 7, 2017, at 9:17 AM, radai <radai.rosenbl...@gmail.com> wrote: > > +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 >>
