Hi, Chia-Ping,

Thanks for following up on this.

To me, there are two categories of changes. The first type involves changes
that always benefit the user. An example is segment.bytes since there is no
good reason for a user to ever set it to less than 1MB. In this case, one
option is to automatically clamp the value to the new lower bound without
failing. This is probably best for users because they get better
configuration and compatibility. This is essentially the approach that we
followed in KIP-1161 for handling duplicates in the List config. The second
category includes changes where disallowed values may impact a user's
intention. An example is segment.ms (change not implemented yet, but
targeted for 5.0). A user may intentionally set it to a really small value
to control the retention time. In this case, it's probably better to fail
the broker with an invalid config error so that the users know about it.

Jun


On Wed, Nov 19, 2025 at 11:18 AM Chia-Ping Tsai <[email protected]> wrote:

> hi all
>
> There was a long discussion about compatibility after increasing the lower
> bound (https://github.com/apache/kafka/pull/20334#discussion_r2538011530).
>
> In summary, increasing the lower bound results in the following issues:
>
> 1) Static configurations created before KIP-1030 cause the broker to fail.
> For example, setting log.segment.bytes=1000 will now encounter a validation
> error due to the new lower bound when starting the updated broker.
>
> 2) Dynamic configurations created before KIP-1030 cannot be applied due to
> validation errors.
>
> Personally, I believe users should be explicitly aware of breaking
> changes. Therefore, I suggest forcing the broker to fail when initializing
> the metadata publisher if the dynamic configuration cannot be applied.
>
> A softer approach is to use warnings instead of fatal errors. The broker
> would proceed smoothly, but users might be unaware of the breaking changes,
> and the broker would run with unexpected configurations.
>
> Any feedback is welcome.
>
> Best,
> Chia-Ping
>
> On 2024/11/18 10:13:41 Divij Vaidya wrote:
> > Hey folks
> >
> > With 4.0, we have an opportunity to reset the default values and add
> > constraints in the configurations based on our learnings since 3.0.
> >
> > Here's a KIP which modifies defaults for some properties and modifies the
> > constraints for a few others.
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1030%3A+Change+constraints+and+default+values+for+various+configurations
> >
> >
> > Looking forward for your feedback.
> >
> > (Previous discussion thread on this topic -
> > https://lists.apache.org/thread/3dx9mdmsqf8pko9xdmhks80k96g650zp )
> >
>

Reply via email to