Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

Sounds good. Thanks Colin! Regards, Rajini On Wed, Apr 10, 2019 at 8:22 PM Colin McCabe 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

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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> and a result like: Map? be

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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

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

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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 mu

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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 pat

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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/

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

On Mon, Sep 24, 2018, at 12:18, Gwen Shapira wrote: > On Mon, Sep 24, 2018 at 12:04 PM Colin McCabe 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

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

On Mon, Sep 24, 2018 at 12:04 PM Colin McCabe 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 de

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

+1 On Mon, Sep 24, 2018 at 10:29 AM Colin McCabe 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 > > Previ

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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.

Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API

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

[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