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 >
