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 > > > > > > > > > > > > >
