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