Hi, Chia-Ping, Thanks for the reply. Do you agree that it's better to use the clamping approach for segment.bytes ?
Jun On Tue, Feb 3, 2026 at 11:15 AM Chia-Ping Tsai <[email protected]> wrote: > hi Jun > > I agree that we should apply reasonable strategies for different `breaking > changes`. This makes ensuring that the initialization process sees the > 'latest' configs even more critical. It is otherwise hard to guarantee that > the broker fails at the appropriate time when a `fail-fast` policy is > intended > > Best, > Chia-Ping > > On 2026/01/30 22:13:00 Jun Rao via dev wrote: > > 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 ) > > > > > > > > > >
