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/09/24 17:29:11 UTC
[VOTE] KIP-339: Create a new IncrementalAlterConfigs API
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
> > > > >
> > >
>
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Colin McCabe <cm...@apache.org>.
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 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>.
+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>.
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.
Goid idea. +1
> 2. Did we consider Add/Remove instead of Append/Subtract?
Hmm. I guess I was worried that Add might be confused with set. Append
seems to better suggest adding to a multi-part entry, to me, at least.
Best,
Colin
>
> 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 Ismael Juma <is...@juma.me.uk>.
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>.
On Mon, Sep 24, 2018, at 12:18, Gwen Shapira wrote:
> On Mon, Sep 24, 2018 at 12:04 PM Colin McCabe <cm...@apache.org> wrote:
> >
> > On Mon, Sep 24, 2018, at 11:11, Gwen Shapira wrote:
> > > Can you explain more why we can't add "incremental" to the existing API and
> > > then deprecate the old behavior? The "rejected" section says: "We would
> > > also not have been able to deprecate the non-incremental mode." but I'm not
> > > sure why not.
> >
> > Hi Gwen,
> >
> > We talked about this previously. If we extend the existing API, then we
> can't change the behavior of existing programs, which means that
> non-incremental needs to continue to be the default. Changing the default
> to incremental would be a breaking change which would silently alter the
> behavior of existing programs. Also, the actions of append, subtract, etc.
> don't fit in the existing API.
> >
>
> Got it.
>
> > >
> > > Having two APIs "Alter" and "Modify" with slightly different behavior
> that
> > > is not obvious from their name (i.e. would anyone remember which one is
> > > incremental?) seems pretty bad.
> >
> > The KIP doesn't propose having two APIs named "alter" and "modify". The
> new API is named IncrementalAlterConfigs.
>
> You are right, of course. There are few spots that mention ModifyConfigs
> and that got me a bit confused.
Oh, good point. I found two typos where it still said "modifyConfigs" in the KIP text and changed it to be "incrementalAlterConfigs" as it should be.
best,
Colin
>
> >
> > best,
> > Colin
> >
> > > Add the fact that in databases, "alter" is
> > > incremental and things will get confusing pretty fast. Obviously if
> > > deprecating the old behavior is impossible, than we have no choice -
> but I
> > > don't see why it would be impossible.
> > >
> > > Gwen
> > >
> > > 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
> > >
> > >
> > >
> > > --
> > > Gwen Shapira
> > > Product Manager | Confluent
> > > 650.450.2760 | @gwenshap
> > > Follow us: Twitter | blog
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Gwen Shapira <gw...@confluent.io>.
On Mon, Sep 24, 2018 at 12:04 PM Colin McCabe <cm...@apache.org> wrote:
>
> On Mon, Sep 24, 2018, at 11:11, Gwen Shapira wrote:
> > Can you explain more why we can't add "incremental" to the existing API
and
> > then deprecate the old behavior? The "rejected" section says: "We would
> > also not have been able to deprecate the non-incremental mode." but I'm
not
> > sure why not.
>
> Hi Gwen,
>
> We talked about this previously. If we extend the existing API, then we
can't change the behavior of existing programs, which means that
non-incremental needs to continue to be the default. Changing the default
to incremental would be a breaking change which would silently alter the
behavior of existing programs. Also, the actions of append, subtract, etc.
don't fit in the existing API.
>
Got it.
> >
> > Having two APIs "Alter" and "Modify" with slightly different behavior
that
> > is not obvious from their name (i.e. would anyone remember which one is
> > incremental?) seems pretty bad.
>
> The KIP doesn't propose having two APIs named "alter" and "modify". The
new API is named IncrementalAlterConfigs.
You are right, of course. There are few spots that mention ModifyConfigs
and that got me a bit confused.
>
> best,
> Colin
>
> > Add the fact that in databases, "alter" is
> > incremental and things will get confusing pretty fast. Obviously if
> > deprecating the old behavior is impossible, than we have no choice -
but I
> > don't see why it would be impossible.
> >
> > Gwen
> >
> > 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
> >
> >
> >
> > --
> > Gwen Shapira
> > Product Manager | Confluent
> > 650.450.2760 | @gwenshap
> > Follow us: Twitter | blog
--
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Colin McCabe <cm...@apache.org>.
On Mon, Sep 24, 2018, at 11:11, Gwen Shapira wrote:
> Can you explain more why we can't add "incremental" to the existing API and
> then deprecate the old behavior? The "rejected" section says: "We would
> also not have been able to deprecate the non-incremental mode." but I'm not
> sure why not.
Hi Gwen,
We talked about this previously. If we extend the existing API, then we can't change the behavior of existing programs, which means that non-incremental needs to continue to be the default. Changing the default to incremental would be a breaking change which would silently alter the behavior of existing programs. Also, the actions of append, subtract, etc. don't fit in the existing API.
>
> Having two APIs "Alter" and "Modify" with slightly different behavior that
> is not obvious from their name (i.e. would anyone remember which one is
> incremental?) seems pretty bad.
The KIP doesn't propose having two APIs named "alter" and "modify". The new API is named IncrementalAlterConfigs.
best,
Colin
> Add the fact that in databases, "alter" is
> incremental and things will get confusing pretty fast. Obviously if
> deprecating the old behavior is impossible, than we have no choice - but I
> don't see why it would be impossible.
>
> Gwen
>
> 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
>
>
>
> --
> Gwen Shapira
> Product Manager | Confluent
> 650.450.2760 | @gwenshap
> Follow us: Twitter | blog
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Gwen Shapira <gw...@confluent.io>.
Can you explain more why we can't add "incremental" to the existing API and
then deprecate the old behavior? The "rejected" section says: "We would
also not have been able to deprecate the non-incremental mode." but I'm not
sure why not.
Having two APIs "Alter" and "Modify" with slightly different behavior that
is not obvious from their name (i.e. would anyone remember which one is
incremental?) seems pretty bad. Add the fact that in databases, "alter" is
incremental and things will get confusing pretty fast. Obviously if
deprecating the old behavior is impossible, than we have no choice - but I
don't see why it would be impossible.
Gwen
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
--
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog
Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Posted by Gwen Shapira <gw...@confluent.io>.
+1
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
>
--
*Gwen Shapira*
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
<http://www.confluent.io/blog>