Sounds good. Thanks Colin! Regards,
Rajini On Wed, Apr 10, 2019 at 8:22 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi Rajini, > > That is a good point. We want to keep the "transactionality" of updating > several configs for the same ConfigResource at once. SSL configs are a > good example of this-- it often wouldn't make sense to change just one at > once. How about an input like Map<ConfigResource, List<ConfigOps>> and a > result like: Map<ConfigResource, ApiError>? > > best, > Colin > > On Mon, Apr 8, 2019, at 04:48, Rajini Sivaram wrote: > > Hi Colin, > > > > I am not sure the API proposed in the KIP fits with the type of updates > we > > support. The old API with Map<ConfigResource, Config> fits better and we > > need to find a way to do something similar while still retaining the old > > one. > > > > Each request should specify a collection of updates for each > > ConfigResource with > > results returned per-ConfigResource since that is our unit of atomicity. > We > > guarantee that we never do a partial update of a collection of configs > for > > a ConfigResource from a single request and hence we should only have one > > input with a collection of updates and one result for each > ConfigResource, > > making the model obvious in the API and docs. We need something similar > to > > the existing method with Map<ConfigResource, xxx>, but need to change the > > method signature so that it can co-exist with the old method, > > > > On Mon, Oct 1, 2018 at 8:35 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > Hi all, > > > > > > With 3 binding +1s from myself, Ismael, and Gwen, the vote passes. > > > > > > Thanks, all. > > > Colin > > > > > > > > > On Fri, Sep 28, 2018, at 09:43, Colin McCabe wrote: > > > > Hi all, > > > > > > > > Thanks for the discussion. I'm going to close the vote later today > if > > > > there are no more comments. > > > > > > > > cheers, > > > > Colin > > > > > > > > > > > > On Mon, Sep 24, 2018, at 22:33, Colin McCabe wrote: > > > > > +1 (binding) > > > > > > > > > > Colin > > > > > > > > > > > > > > > On Mon, Sep 24, 2018, at 17:49, Ismael Juma wrote: > > > > > > Thanks Colin. I think this is much needed and I'm +1 (binding) > > > > > > on fixing> this issue. However, I have a few minor suggestions: > > > > > > > > > > > > 1. Overload alterConfigs instead of creating a new method name. > This > > > > > > gives> us both the short name and a path for removal of the > > > deprecated > > > > > > overload.> 2. Did we consider Add/Remove instead of > Append/Subtract? > > > > > > > > > > > > Ismael > > > > > > > > > > > > On Mon, Sep 24, 2018 at 10:29 AM Colin McCabe > > > > > > <cmcc...@apache.org> wrote:> > > > > > > > Hi all, > > > > > > > > > > > > > > I would like to start voting on KIP-339, which creates a new > > > > > > > IncrementalAlterConfigs API. > > > > > > > > > > > > > > The KIP is described here: > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-339%3A+Create+a+new+ModifyConfigs+API > > > > > > > > > > > > > Previous discussion: > > > > > > > https://sematext.com/opensee/m/Kafka/uyzND1OYRKh2RrGba1 > > > > > > > > > > > > > > best, > > > > > > > Colin > > > > > > > > > > > > > > > > > >
