kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gwen Shapira <g...@confluent.io>
Subject Re: [VOTE] KIP-339: Create a new IncrementalAlterConfigs API
Date Mon, 24 Sep 2018 18:11:02 GMT
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 <cmccabe@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message