Hi Colin, Thanks for the update. Sounds good to me!
Luke On Wed, Sep 25, 2024 at 1:47 AM Colin McCabe <cmcc...@apache.org> wrote: > Thanks for posting this here, Luke. Thinking about this more, I'll just go > back to the old behavior where the synonyms are ignored if you set them as > dynamic configurations. I will fix the problem where static synonyms are > ignored sometimes, though, since that seems more "surprising" and bad. > > Maybe we should have removed those synonyms in 4.0, but I guess that ship > has sailed. Perhaps 5.0 :) > > best, > Colin > > > On Tue, Sep 24, 2024, at 02:52, Luke Chen wrote: > > Hi all, > > > > KAFKA-17584 <https://issues.apache.org/jira/browse/KAFKA-17584> is > about a > > bug related to the incorrect synonym handling for dynamic log > > configurations. While there is already a PR > > <https://github.com/apache/kafka/pull/17258> to fix the issue, we found > > there are some log configs that should be "cluster-wide" configs, but due > > to the bug in KAFKA-17584 > > <https://issues.apache.org/jira/browse/KAFKA-17584>, we incorrectly > treat > > them as "read-only" configs, since v3.0.0 (or even earlier). This issue > is > > that we only treat 1 config as "cluster-wide" in the same synonym group. > > The list is as follows: > > > > Configs is now "read-only" but should be "cluster-wide" (i.e. dynamically > > changeable): > > - log.retention.hours > > log.retention.minutes > > (log.retention.ms is already a "cluster-wide" config) > > - log.roll.hours > > (log.roll.ms is already a "cluster-wide" config) > > - log.roll.jitter.hours > > (log.roll.jitter.ms is already a "cluster-wide" config) > > - log.flush.scheduler.interval.ms > > (log.flush.interval.ms is already a "cluster-wide" config) > > > > Note that, in all the groups, there is 1 config being treated as a > > "cluster-wide" config. So, it should not block any operation. > > After this fix, all the configs above will become "cluster-wide" configs. > > Although these are public interface changes, I think it is more like a > bug > > fix. But if people think we should go through the KIP process to have > > proper discussion, I can open one for it. But for v3.9.0, I think we > should > > include this fix to avoid any possible unexpected data loss as described > in > > KAFKA-17584 <https://issues.apache.org/jira/browse/KAFKA-17584>, even if > > KIP is required and not accepted. > > > > Please let me know what you think. > > > > Thank you. > > Luke >
