+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

Reply via email to