KAFKA-16094 has been fixed and backported to 3.7. Colin
On Mon, Jan 8, 2024, at 14:52, Colin McCabe wrote: > On an unrelated note, I found a blocker bug related to upgrades from > 3.6 (and earlier) to 3.7. > > The JIRA is here: > https://issues.apache.org/jira/browse/KAFKA-16094 > > Fix here: > https://github.com/apache/kafka/pull/15153 > > best, > Colin > > > On Mon, Jan 8, 2024, at 14:47, Colin McCabe wrote: >> Hi Ismael, >> >> I wasn't aware of that. If we are required to publish all modules, then >> this is working as intended. >> >> I am a bit curious if we've discussed why we need to publish the server >> modules to Sonatype. Is there a discussion about the pros and cons of >> this somewhere? >> >> regards, >> Colin >> >> On Mon, Jan 8, 2024, at 14:09, Ismael Juma wrote: >>> All modules are published to Sonatype - that's a requirement. You may be >>> missing the fact that `core` is published as `kafka_2.13` and `kafka_2.12`. >>> >>> Ismael >>> >>> On Tue, Jan 9, 2024 at 12:00 AM Colin McCabe <cmcc...@apache.org> wrote: >>> >>>> Hi Ismael, >>>> >>>> It seems like both the metadata gradle module and the server-common module >>>> are getting published to Sonatype as separate artifacts, unless I'm >>>> misunderstanding something. Example: >>>> >>>> https://central.sonatype.com/search?q=kafka-server-common >>>> >>>> I don't see kafka-core getting published, but maybe other private >>>> server-side gradle modules are getting published. >>>> >>>> This seems bad. Is there a reason to publish modules that are only used by >>>> the server on Sonatype? >>>> >>>> best, >>>> Colin >>>> >>>> >>>> On Mon, Jan 8, 2024, at 12:50, Ismael Juma wrote: >>>> > Hi Colin, >>>> > >>>> > I think you may have misunderstood what they mean by gradle metadata - >>>> it's >>>> > not the Kafka metadata module. >>>> > >>>> > Ismael >>>> > >>>> > On Mon, Jan 8, 2024 at 9:45 PM Colin McCabe <cmcc...@apache.org> wrote: >>>> > >>>> >> Oops, hit send too soon. I see that #15127 was already merged. So we >>>> >> should no longer be publishing :metadata as part of the clients >>>> artifacts, >>>> >> right? >>>> >> >>>> >> thanks, >>>> >> Colin >>>> >> >>>> >> >>>> >> On Mon, Jan 8, 2024, at 11:42, Colin McCabe wrote: >>>> >> > Hi Apporv, >>>> >> > >>>> >> > Please remove the metadata module from any artifacts published for >>>> >> > clients. It is only used by the server. >>>> >> > >>>> >> > best, >>>> >> > Colin >>>> >> > >>>> >> > >>>> >> > On Sun, Jan 7, 2024, at 03:04, Apoorv Mittal wrote: >>>> >> >> Hi Colin, >>>> >> >> Thanks for the response. The only reason for asking the question of >>>> >> >> publishing the metadata is because that's present in previous client >>>> >> >> releases. For more context, the description of PR >>>> >> >> <https://github.com/apache/kafka/pull/15127> holds the details and >>>> >> waiting >>>> >> >> for the confirmation there prior to the merge. >>>> >> >> >>>> >> >> Regards, >>>> >> >> Apoorv Mittal >>>> >> >> +44 7721681581 >>>> >> >> >>>> >> >> >>>> >> >> On Fri, Jan 5, 2024 at 10:22 PM Colin McCabe <cmcc...@apache.org> >>>> >> wrote: >>>> >> >> >>>> >> >>> metadata is an internal gradle module. It is not used by clients. >>>> So I >>>> >> >>> don't see why you would want to publish it (unless I'm >>>> misunderstanding >>>> >> >>> something). >>>> >> >>> >>>> >> >>> best, >>>> >> >>> Colin >>>> >> >>> >>>> >> >>> >>>> >> >>> On Fri, Jan 5, 2024, at 10:05, Stanislav Kozlovski wrote: >>>> >> >>> > Thanks for reporting the blockers, folks. Good job finding. >>>> >> >>> > >>>> >> >>> > I have one ask - can anybody with Gradle expertise help review >>>> this >>>> >> small >>>> >> >>> > PR? https://github.com/apache/kafka/pull/15127 (+1, -1) >>>> >> >>> > In particular, we are wondering whether we need to publish module >>>> >> >>> metadata >>>> >> >>> > as part of the gradle publishing process. >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > On Fri, Jan 5, 2024 at 3:56 PM Proven Provenzano >>>> >> >>> > <pprovenz...@confluent.io.invalid> wrote: >>>> >> >>> > >>>> >> >>> >> We have potentially one more blocker >>>> >> >>> >> https://issues.apache.org/jira/browse/KAFKA-16082 which might >>>> >> cause a >>>> >> >>> data >>>> >> >>> >> loss scenario with JBOD in KRaft. >>>> >> >>> >> Initial analysis thought this is a problem and further review >>>> looks >>>> >> >>> like it >>>> >> >>> >> isn't but we are continuing to dig into the issue to ensure that >>>> it >>>> >> >>> isn't. >>>> >> >>> >> We would request feedback on the bug from anyone who is familiar >>>> >> with >>>> >> >>> this >>>> >> >>> >> code. >>>> >> >>> >> >>>> >> >>> >> --Proven >>>> >> >>> >> >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > -- >>>> >> >>> > Best, >>>> >> >>> > Stanislav >>>> >> >>> >>>> >> >>>>
