You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Colin McCabe <cm...@apache.org> on 2018/10/01 19:35:10 UTC
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
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
> > > <cm...@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
> > > >
> >
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Rajini Sivaram <ra...@gmail.com>.
Sounds good. Thanks Colin!
Regards,
Rajini
On Wed, Apr 10, 2019 at 8:22 PM Colin McCabe <cm...@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 <cm...@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
> > > > > > <cm...@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
> > > > > > >
> > > > >
> > >
> >
>
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Colin McCabe <cm...@apache.org>.
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 <cm...@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
> > > > > <cm...@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
> > > > > >
> > > >
> >
>
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Rajini Sivaram <ra...@gmail.com>.
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 <cm...@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
> > > > <cm...@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
> > > > >
> > >
>