Hi Konstantine. A potential 3.0 blocker was discovered today, https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-13219. The BrokerState metric is not working for KRaft clusters -- it always indicates that the broker is in the "not running" state. A PR is available at https://github.com/apache/kafka/pull/11239. The risk is low, and there is no workaround, but I also understand the bar for a blocker is pretty high at this point.
Ron On Thu, Aug 19, 2021 at 5:54 PM Israel Ekpo <israele...@gmail.com> wrote: > Konstantine, > > After a brief chat with Sophie, I just updated the name for KIP-633 to be > more descriptive of what is actually happening in the implementation > > It is changed on the KIP page and the JIRA task title is also updated to be > more descriptive > https://cwiki.apache.org/confluence/x/Ho2NCg > https://issues.apache.org/jira/browse/KAFKA-8613 > > However, I could not update the page for the 3.0 release plan. I do not > have the permissions for that update. > https://cwiki.apache.org/confluence/x/woONCg > > When you have a moment, please could you update the release plan for 3.0 to > reflect the update name for the KIP? > > Thank you very much > > Sincerely, > Israel > > > On Thu, Aug 19, 2021 at 5:50 PM Israel Ekpo <israele...@gmail.com> wrote: > > > Hi Matthias, it is possible to still deprecate JoinWindows.of(size) even > > though the new join semantics is disabled. > > > > I just pre-recorded a talk for Kafka Summit Americas where I am > > recommending a switch to the new APIs instead of the deprecated one > > starting from 3.0 > > > > I would love to be involved in the discussion for the fix so that we try > > to honor the expectations of the KIP as much as possible. > > > > So far, it looks like the PR will still honor the expectations of the KIP > > > > https://github.com/apache/kafka/pull/11235 > > > > Thanks for sharing this to create awareness. > > > > Sincerely, > > Israel > > > > > > > > > > > > On Wed, Aug 18, 2021 at 8:57 PM Matthias J. Sax <mj...@apache.org> > wrote: > > > >> Hi, > >> > >> we discovered a potential blocker for 3.0.0 today: > >> https://issues.apache.org/jira/browse/KAFKA-13216 > >> > >> We are still evaluating a potential fix. If we cannot fix it quickly, > >> the fall-back would be to partially roll-back KIP-633, to disable the > >> new join semantics such that people cannot hit this bug. > >> > >> Thoughts? > >> > >> > >> -Matthias > >> > >> > >> On 8/17/21 1:29 PM, Konstantine Karantasis wrote: > >> > Hi Rajini. > >> > > >> > Approved, given its low risk and the lack of convenient workarounds. > >> > > >> > Konstantine > >> > > >> > > >> > On Tue, Aug 17, 2021 at 11:00 AM Rajini Sivaram < > >> rajinisiva...@gmail.com> > >> > wrote: > >> > > >> >> Hi Konstantine, > >> >> > >> >> We found an issue with replication with IBP 2.7: > >> >> https://issues.apache.org/jira/browse/KAFKA-13207. The fix is small > >> and > >> >> low > >> >> risk and has been merged to trunk. Can we include this in 3.0 branch > >> since > >> >> it can result in IllegalStateException during replication? > >> >> > >> >> Thank you, > >> >> > >> >> Rajini > >> >> > >> >> > >> >> On Thu, Aug 5, 2021 at 6:21 PM Konstantine Karantasis < > >> >> kkaranta...@apache.org> wrote: > >> >> > >> >>> Jose, thanks for the heads up on the 3 new blocker candidates. > >> >>> > >> >>> I read the tickets and they have clear descriptions and > implementation > >> >>> details. > >> >>> However, at this stage to be able to make a call and approve new > >> blockers > >> >>> I'd appreciate it if we could get some insight regarding the risk > and > >> the > >> >>> necessity of a fix. A rough ETA would also be helpful. > >> >>> > >> >>> Having said that, based on the descriptions and the existence of a > few > >> >>> other blockers, I'm tentatively approving KAFKA-13161, KAFKA-13165, > >> and > >> >>> KAFKA-13168 and we might have to make a new assessment if these are > >> the > >> >>> only blockers in the next few days or if we notice a regression > during > >> >>> testing. > >> >>> > >> >>> Konstantine > >> >>> > >> >>> > >> >>> > >> >>> On Thu, Aug 5, 2021 at 10:04 AM Konstantine Karantasis < > >> >>> kkaranta...@apache.org> wrote: > >> >>> > >> >>>> > >> >>>> Thanks for reporting this new issue Ryan, > >> >>>> > >> >>>> It's important and this issue seems to have clearly regressed > dynamic > >> >>>> default configs in the 3.0 branch. > >> >>>> So, it's approved. > >> >>>> > >> >>>> Konstantine > >> >>>> > >> >>>> > >> >>>> On Wed, Aug 4, 2021 at 4:34 PM José Armando García Sancio > >> >>>> <jsan...@confluent.io.invalid> wrote: > >> >>>> > >> >>>>> Hey all, > >> >>>>> > >> >>>>> For the KIP-500 work for 3.0 we would like to propose the > following > >> >>>>> Jiras as blockers: > >> >>>>> > >> >>>>> 1. https://issues.apache.org/jira/browse/KAFKA-13168 > >> >>>>> 2. https://issues.apache.org/jira/browse/KAFKA-13165 > >> >>>>> 3. https://issues.apache.org/jira/browse/KAFKA-13161 > >> >>>>> > >> >>>>> The description for each Jira should have more details. > >> >>>>> > >> >>>>> Thanks, > >> >>>>> -Jose > >> >>>>> > >> >>>>> On Tue, Aug 3, 2021 at 12:14 PM Ryan Dielhenn > >> >>>>> <rdielh...@confluent.io.invalid> wrote: > >> >>>>>> > >> >>>>>> Hi Konstantine, > >> >>>>>> > >> >>>>>> I would like to report another bug in KRaft. > >> >>>>>> > >> >>>>>> The ConfigHandler that processes dynamic broker config deltas in > >> >> KRaft > >> >>>>>> expects that the default resource name for dynamic broker configs > >> is > >> >>> the > >> >>>>>> old default entity name used in ZK: "<default>". Since dynamic > >> >> default > >> >>>>>> broker configs are persisted as empty string in the quorum > instead > >> >> of > >> >>>>>> "<default>", the brokers are not updating the their default > >> >>>>> configuration > >> >>>>>> when they see empty string as a resource name in the config delta > >> >> and > >> >>>>> are > >> >>>>>> throwing a NumberFormatException when they try to parse the > >> resource > >> >>>>> name > >> >>>>>> to process it as a per-broker configuration. > >> >>>>>> > >> >>>>>> I filed a JIRA: > https://issues.apache.org/jira/browse/KAFKA-13160 > >> >>>>>> > >> >>>>>> I also have a PR to fix this: > >> >>>>> https://github.com/apache/kafka/pull/11168 > >> >>>>>> > >> >>>>>> I think that this should be a blocker for 3.0 because dynamic > >> >> default > >> >>>>>> broker configs will not be usable in KRaft otherwise. > >> >>>>>> > >> >>>>>> Best, > >> >>>>>> Ryan Dielhenn > >> >>>>>> > >> >>>>>> On Sat, Jul 31, 2021 at 10:42 AM Konstantine Karantasis < > >> >>>>>> kkaranta...@apache.org> wrote: > >> >>>>>> > >> >>>>>>> Thanks Ryan, > >> >>>>>>> > >> >>>>>>> Approved. Seems also like a low risk fix. > >> >>>>>>> With that opportunity, let's make sure there are no other > configs > >> >>> that > >> >>>>>>> would need a similar validation. > >> >>>>>>> > >> >>>>>>> Konstantine > >> >>>>>>> > >> >>>>>>> On Fri, Jul 30, 2021 at 8:33 AM Ryan Dielhenn > >> >>>>>>> <rdielh...@confluent.io.invalid> wrote: > >> >>>>>>> > >> >>>>>>>> Hey Konstantine, > >> >>>>>>>> > >> >>>>>>>> Thanks for the question. If these configs are not validated the > >> >>>>> user's > >> >>>>>>>> experience will be affected and upgrades from 3.0 will be > >> >> harder. > >> >>>>>>>> > >> >>>>>>>> Best, > >> >>>>>>>> Ryan Dielhenn > >> >>>>>>>> > >> >>>>>>>> On Thu, Jul 29, 2021 at 3:59 PM Konstantine Karantasis < > >> >>>>>>>> kkaranta...@apache.org> wrote: > >> >>>>>>>> > >> >>>>>>>>> Thanks for reporting this issue Ryan. > >> >>>>>>>>> > >> >>>>>>>>> I believe what you mention corresponds to the ticket you > >> >> created > >> >>>>> here: > >> >>>>>>>>> > >> >>> https://issues.apache.org/jira/projects/KAFKA/issues/KAFKA-13151 > >> >>>>>>>>> > >> >>>>>>>>> What happens if the configurations are present but the broker > >> >>>>> doesn't > >> >>>>>>>> fail > >> >>>>>>>>> at startup when configured to run in KRaft mode? > >> >>>>>>>>> Asking to see if we have any workarounds in our availability. > >> >>>>>>>>> > >> >>>>>>>>> Thanks, > >> >>>>>>>>> Konstantine > >> >>>>>>>>> > >> >>>>>>>>> On Thu, Jul 29, 2021 at 2:51 PM Ryan Dielhenn > >> >>>>>>>>> <rdielh...@confluent.io.invalid> wrote: > >> >>>>>>>>> > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> Disregard log.clean.policy being included in this blocker. > >> >>>>>>>>>> > >> >>>>>>>>>> Best, > >> >>>>>>>>>> Ryan Dielhenn > >> >>>>>>>>>> > >> >>>>>>>>>> On Thu, Jul 29, 2021 at 2:38 PM Ryan Dielhenn < > >> >>>>>>> rdielh...@confluent.io> > >> >>>>>>>>>> wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> Hey Konstantine, > >> >>>>>>>>>>> > >> >>>>>>>>>>> I'd like to report another bug in KRaft. > >> >>>>>>>>>>> > >> >>>>>>>>>>> log.cleanup.policy, alter.config.policy.class.name, and > >> >>>>>>>>>>> create.topic.policy.class.name are all unsupported by > >> >> KRaft > >> >>>>> but > >> >>>>>>>> KRaft > >> >>>>>>>>>>> servers allow them to be configured. I believe this should > >> >>> be > >> >>>>>>>>> considered > >> >>>>>>>>>> a > >> >>>>>>>>>>> blocker and that KRaft servers should fail startup if any > >> >> of > >> >>>>> these > >> >>>>>>>> are > >> >>>>>>>>>>> configured. I do not have a PR yet but will soon. > >> >>>>>>>>>>> > >> >>>>>>>>>>> On another note, I have a PR for the dynamic broker > >> >>>>> configuration > >> >>>>>>> fix > >> >>>>>>>>>>> here: https://github.com/apache/kafka/pull/11141 > >> >>>>>>>>>>> > >> >>>>>>>>>>> Best, > >> >>>>>>>>>>> Ryan Dielhenn > >> >>>>>>>>>>> > >> >>>>>>>>>>> On Wed, May 26, 2021 at 2:48 PM Konstantine Karantasis > >> >>>>>>>>>>> <konstant...@confluent.io.invalid> wrote: > >> >>>>>>>>>>> > >> >>>>>>>>>>>> Hi all, > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Please find below the updated release plan for the Apache > >> >>>>> Kafka > >> >>>>>>>> 3.0.0 > >> >>>>>>>>>>>> release. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>> > >> >>> > >> >> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=177046466 > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> New suggested dates for the release are as follows: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> KIP Freeze is 09 June 2021 (same date as in the initial > >> >>> plan) > >> >>>>>>>>>>>> Feature Freeze is 30 June 2021 (new date, extended by two > >> >>>>> weeks) > >> >>>>>>>>>>>> Code Freeze is 14 July 2021 (new date, extended by two > >> >>> weeks) > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> At least two weeks of stabilization will follow Code > >> >>> Freeze. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The release plan is up to date and currently includes all > >> >>> the > >> >>>>>>>> approved > >> >>>>>>>>>>>> KIPs > >> >>>>>>>>>>>> that are targeting 3.0.0. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Please let me know if you have any objections with the > >> >>> recent > >> >>>>>>>>> extension > >> >>>>>>>>>> of > >> >>>>>>>>>>>> Feature Freeze and Code Freeze or any other concerns. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Regards, > >> >>>>>>>>>>>> Konstantine > >> >>>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> -Jose > >> >>>>> > >> >>>> > >> >>> > >> >> > >> > > >> > > >
