Hi Colin, The release notes (and the KAFKA-17543 JIRA) say this: [KAFKA-17543] - Enforce that broker.id.generation.enable is disabled when migrating to KRaft
When I read that, it meant to me that the option "broker.id.generation.enable" needs to be disabled (i.e. set to false). Given this option seems to default to enabled/true, it would mean that everyone would need to go and update this in their cluster before migration even if they never used the generated broker IDs. So it would be quite an important change. But the related PR seems to only check that the "broker.id" is not set to -1. That seems reasonable and it means that when I don't use the generated broker IDs I do not need to do anything even if "broker.id.generation.enable" is enabled / set to true as it is by default. Maybe it is just me who finds this wrong/confusing. But I think calling it something like "Enforce that broker.id generation is not used when migrating to KRaft" would make it much clearer to users reading the release notes and help them understand what it really means for them. Thanks & Regards Jakub On Wed, Sep 18, 2024 at 4:03 PM Colin McCabe <cmcc...@apache.org> wrote: > Hi Jakub, > > Can you say more about what you would like to see in the release notes? > > best, > Colin > > > On Wed, Sep 18, 2024, at 02:13, Jakub Scholz wrote: > > Maybe you could have at least fixed the release notes which is what I was > > suggesting :-(. > > > > On Wed, Sep 18, 2024 at 12:22 AM Colin McCabe <cmcc...@apache.org> > wrote: > > > >> Hi Chia-Ping Tsai, > >> > >> I've already pushed the RC0 to maven central, so we cannot include this > >> now. (I am waiting on some other release phases to complete before I > can > >> announce the RC!) > >> > >> However, I suspect that there will be another RC, so don't abandon the > PR > >> just yet :) > >> > >> best, > >> Colin > >> > >> > >> On Tue, Sep 17, 2024, at 11:57, Chia-Ping Tsai wrote: > >> > hi Colin > >> > > >> > https://github.com/apache/kafka/pull/17210 tries to revise the error > >> > message of KAFKA-17543. I guess the 3.9 RC is in progress, so could > you > >> > please take a look at the PR? If it is too trivial to be included, I > >> > think it can be excluded from trunk too since 4.0 will abandon the zk. > >> > > >> > Thanks, > >> > Chia-Ping > >> > > >> > On 2024/09/14 20:14:41 Colin McCabe wrote: > >> >> Thanks, everyone. It looks like the blockers list is empty now. I am > >> running some ducktape tests and if they look good, will create a release > >> candidate for 3.9.0 soon. > >> >> > >> >> regards, > >> >> Colin > >> >> > >> >> > >> >> On Wed, Sep 11, 2024, at 10:01, Matthias J. Sax wrote: > >> >> > Hi Colin, > >> >> > > >> >> > we found another blocker bug: > >> >> > https://issues.apache.org/jira/browse/KAFKA-17527 > >> >> > > >> >> > Working on a fix. > >> >> > > >> >> > > >> >> > -Matthias > >> >> > > >> >> > On 9/9/24 6:51 PM, David Arthur wrote: > >> >> >> Colin, > >> >> >> > >> >> >> I found a race condition in the migration while investigating a > >> flaky test. > >> >> >> If encountered, the migration driver will get stuck initializing. > >> >> >> > >> >> >> JIRA: https://issues.apache.org/jira/browse/KAFKA-17506 > >> >> >> PR: https://github.com/apache/kafka/pull/17147 > >> >> >> > >> >> >> I wouldn't normally consider this a blocker, since it's quite rare > >> and easy > >> >> >> to work around, but I wanted to raise it here since this is our > last > >> chance > >> >> >> for migration fixes in 3.x > >> >> >> > >> >> >> -David > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Mon, Sep 9, 2024 at 3:50 AM Lucas Brutschy > >> >> >> <lbruts...@confluent.io.invalid> wrote: > >> >> >> > >> >> >>> Hi Colin, > >> >> >>> > >> >> >>> about KAFKA-17489, the bug Bruno mentioned. This needs to be > fixed > >> in > >> >> >>> 3.8 as well. The fix is probably small but tricky to get right - > >> Bruno > >> >> >>> has attempted to fix it, but soaking revealed that the fix is not > >> >> >>> complete. Bruno is now out with Covid, so I will look into it. > I'll > >> >> >>> update this thread once I know more. > >> >> >>> > >> >> >>> Cheers, > >> >> >>> Lucas > >> >> >>> > >> >> >>> On Mon, Sep 9, 2024 at 4:47 AM Colin McCabe <cmcc...@apache.org> > >> wrote: > >> >> >>>> > >> >> >>>> Hi Chia-Ping Tsai, > >> >> >>>> > >> >> >>>> Thanks for the bug report. Let’s follow up on this this week. > >> >> >>>> > >> >> >>>> Best, > >> >> >>>> Colin > >> >> >>>> > >> >> >>>> On Fri, Sep 6, 2024, at 06:19, Chia-Ping Tsai wrote: > >> >> >>>>> hi Colin > >> >> >>>>> > >> >> >>>>> I raise a issue ( > >> https://issues.apache.org/jira/browse/KAFKA-17492) as > >> >> >>>>> 3.9 blocker, since the bug obstructs us from registering 3.9 > >> broker to > >> >> >>>>> 3.8 controller > >> >> >>>>> > >> >> >>>>> Best, > >> >> >>>>> Chia-Ping > >> >> >>>>> > >> >> >>>>> On 2024/08/09 01:46:35 Colin McCabe wrote: > >> >> >>>>>> Hi all, > >> >> >>>>>> > >> >> >>>>>> I think it's time to transition the 3.9 branch to feature > freeze. > >> >> >>> Please note that this is 2 weeks past the original planned date. > I > >> >> >>> apologize for this; our planning wasn't perfect. > >> >> >>>>>> > >> >> >>>>>> A few updates on features that are in or out of Apache Kafka > 3.9: > >> >> >>>>>> > >> >> >>>>>> - We have completed all the feature work for KIP-853: KRaft > >> >> >>> controller membership changes. (Please note that there are still > a > >> few bug > >> >> >>> fixes remaining, and the docs JIRA, KAFKA-17048, but those are > all > >> >> >>> post-feature-freeze tasks.) > >> >> >>>>>> > >> >> >>>>>> - After speaking with Calvin, I moved KIP-966 out of 3.9 and > into > >> >> >>> 4.0. I do feel bad about this but I just don't think we'll be > able > >> to get > >> >> >>> it into this short release. > >> >> >>>>>> > >> >> >>>>>> There are a few other KIPs that probably need to be moved to > 4.0, > >> >> >>> such as KIP-1023 and KIP-1025. I will do a more thorough review > >> tomorrow > >> >> >>> and reach out to people if there are gray areas. If you have a > >> feature that > >> >> >>> you have questions about, please reach out. > >> >> >>>>>> > >> >> >>>>>> I would like to extend code freeze for Kafka 3.9 to August > 29th. > >> My > >> >> >>> reasoning is that code freeze was 2 weeks later than expected, > and > >> also, I > >> >> >>> will be out of the office most of next week. > >> >> >>>>>> > >> >> >>>>>> I have also created a PR to mark 3.9-IV0 as stable, so look > for > >> that > >> >> >>> shortly in trunk and 3.9. > >> >> >>>>>> > >> >> >>>>>> As previously mentioned, please refrain from changing the Java > >> >> >>> version in trunk (kafka 4.0) until we get an RC out. (However, > >> please do > >> >> >>> continue working on your 4.0 features and other refactors in > trunk, > >> even if > >> >> >>> they don't apply to 3.9!) > >> >> >>>>>> > >> >> >>>>>> Thanks to everyone who has worked on this release, and thanks > for > >> >> >>> your patience. I do believe we will deliver on the promise of a > >> >> >>> much-shorter-than-usual release cycle, even with the 2 week > delay. > >> >> >>>>>> > >> >> >>>>>> best, > >> >> >>>>>> Colin > >> >> >>>>>> > >> >> >>> > >> >> >> > >> >> >> > >> >> > >> >
