Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #2597

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-1011: Use incrementalAlterConfigs when updating broker configs by kafka-configs.sh

[Divij Vaidya]

+1 (binding)

I have participated in the discussion for this and looked at the most
recent version of this KIP. It looks good to me.

--
Divij Vaidya



On Tue, Jan 23, 2024 at 8:17 AM David Jacot 
wrote:

> Hi Chris, Ziming,
>
> Thanks for the clarification. I am glad that it does not impact the tool.
> It may be worth adding a note about it in the KIP to avoid the same
> question in the future.
>
> Otherwise, I am +1 (binding). Thanks for driving this!
>
> Best,
> David
>
> On Tue, Jan 23, 2024 at 6:07 AM ziming deng 
> wrote:
>
> > Hello David,
> >
> > Thanks for reminding this, as Chirs explained, the tools I’m trying to
> > update only support set/delete configs, and I’m just make a way for
> > append/subtract configs in the future, so this would not be affected by
> > KAFKA-10140, and it would be a little overkill to support append/subtract
> > configs or solve KAFKA-10140 here, so let’s leave it right now, I'm happy
> > to pick it after finishing this KIP.
> >
> > --,
> > Ziming
> >
> > > On Jan 22, 2024, at 18:23, David Jacot 
> > wrote:
> > >
> > > Hi Ziming,
> > >
> > > Thanks for driving this. I wanted to bring KAFKA-10140
> > >  to your attention.
> > It
> > > looks like the incremental API does not work for configuring plugins. I
> > > think that we need to cover this in the KIP.
> > >
> > > Best,
> > > David
> > >
> > > On Mon, Jan 22, 2024 at 10:13 AM Andrew Schofield <
> > > andrew_schofield_j...@outlook.com> wrote:
> > >
> > >> +1 (non-binding)
> > >>
> > >> Thanks,
> > >> Andrew
> > >>
> > >>> On 22 Jan 2024, at 07:29, Federico Valeri 
> > wrote:
> > >>>
> > >>> +1 (non binding)
> > >>>
> > >>> Thanks.
> > >>>
> > >>> On Mon, Jan 22, 2024 at 7:03 AM Luke Chen  wrote:
> > 
> >  Hi Ziming,
> > 
> >  +1(binding) from me.
> > 
> >  Thanks.
> >  Luke
> > 
> >  On Mon, Jan 22, 2024 at 11:50 AM Kamal Chandraprakash <
> >  kamal.chandraprak...@gmail.com> wrote:
> > 
> > > +1 (non-binding)
> > >
> > > On Mon, Jan 22, 2024 at 8:34 AM ziming deng <
> > dengziming1...@gmail.com>
> > > wrote:
> > >
> > >> Hello everyone,
> > >> I'd like to initiate a vote for KIP-1011.
> > >> This KIP is about replacing alterConfigs with
> > incrementalAlterConfigs
> > >> when updating broker configs using kafka-configs.sh, this is
> similar
> > >> to
> > >> what we have done in KIP-894.
> > >>
> > >> KIP link:
> > >> KIP-1011: Use incrementalAlterConfigs when updating broker configs
> > by
> > >> kafka-configs.sh - Apache Kafka - Apache Software Foundation
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> > >>>
> > >> cwiki.apache.org
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> > >>>
> > >> [image: favicon.ico]
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> > >>>
> > >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> > >>>
> > >>
> > >> Discussion thread:
> > >>
> > >>
> > >> lists.apache.org
> > >>  >
> > >>  >
> > >>  >
> > >>
> > >>
> > >> --,
> > >> Best,
> > >> Ziming
> > >>
> > >>
> > >>
> >
> >
>

Re: [VOTE] KIP-1011: Use incrementalAlterConfigs when updating broker configs by kafka-configs.sh

[Ismael Juma]

Hi Ziming,

Have you verified that the issue only impacts append/subtract? The way I
read the JIRA is that the issue currently affects all operations for
plugins, but it can be fixed to only affect append/subtract (where it would
be harder to fix). It would be good to verify the current state.

Ismael

On Mon, Jan 22, 2024 at 9:07 PM ziming deng 
wrote:

> Hello David,
>
> Thanks for reminding this, as Chirs explained, the tools I’m trying to
> update only support set/delete configs, and I’m just make a way for
> append/subtract configs in the future, so this would not be affected by
> KAFKA-10140, and it would be a little overkill to support append/subtract
> configs or solve KAFKA-10140 here, so let’s leave it right now, I'm happy
> to pick it after finishing this KIP.
>
> --,
> Ziming
>
> > On Jan 22, 2024, at 18:23, David Jacot 
> wrote:
> >
> > Hi Ziming,
> >
> > Thanks for driving this. I wanted to bring KAFKA-10140
> >  to your attention.
> It
> > looks like the incremental API does not work for configuring plugins. I
> > think that we need to cover this in the KIP.
> >
> > Best,
> > David
> >
> > On Mon, Jan 22, 2024 at 10:13 AM Andrew Schofield <
> > andrew_schofield_j...@outlook.com> wrote:
> >
> >> +1 (non-binding)
> >>
> >> Thanks,
> >> Andrew
> >>
> >>> On 22 Jan 2024, at 07:29, Federico Valeri 
> wrote:
> >>>
> >>> +1 (non binding)
> >>>
> >>> Thanks.
> >>>
> >>> On Mon, Jan 22, 2024 at 7:03 AM Luke Chen  wrote:
> 
>  Hi Ziming,
> 
>  +1(binding) from me.
> 
>  Thanks.
>  Luke
> 
>  On Mon, Jan 22, 2024 at 11:50 AM Kamal Chandraprakash <
>  kamal.chandraprak...@gmail.com> wrote:
> 
> > +1 (non-binding)
> >
> > On Mon, Jan 22, 2024 at 8:34 AM ziming deng <
> dengziming1...@gmail.com>
> > wrote:
> >
> >> Hello everyone,
> >> I'd like to initiate a vote for KIP-1011.
> >> This KIP is about replacing alterConfigs with
> incrementalAlterConfigs
> >> when updating broker configs using kafka-configs.sh, this is similar
> >> to
> >> what we have done in KIP-894.
> >>
> >> KIP link:
> >> KIP-1011: Use incrementalAlterConfigs when updating broker configs
> by
> >> kafka-configs.sh - Apache Kafka - Apache Software Foundation
> >> <
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> >>>
> >> cwiki.apache.org
> >> <
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> >>>
> >> [image: favicon.ico]
> >> <
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> >>>
> >> <
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> >>>
> >>
> >> Discussion thread:
> >>
> >>
> >> lists.apache.org
> >> 
> >> 
> >> 
> >>
> >>
> >> --,
> >> Best,
> >> Ziming
> >>
> >>
> >>
>
>

[jira] [Created] (KAFKA-16186) Implement broker metrics for client telemetry usage

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-16186:
-

 Summary: Implement broker metrics for client telemetry usage
 Key: KAFKA-16186
 URL: https://issues.apache.org/jira/browse/KAFKA-16186
 Project: Kafka
  Issue Type: Sub-task
Reporter: Apoorv Mittal
Assignee: Apoorv Mittal


The KIP-714 lists new metrics for broker which records the usage of client 
telemetry instances and plugin. Implement broker metrics as defined in the 
KIP-714.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

dsmmcken commented on PR #567:
URL: https://github.com/apache/kafka-site/pull/567#issuecomment-1906769939

   Anyone available to review this?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] KIP-1014: Managing Unstable Metadata Versions in Apache Kafka

[Jun Rao]

Hi, Proven,

Thanks for the KIP.

I am not sure about the reordering approach proposed in the KIP. Let's say
in a release we have features X and Y, depending on MV IV1 and IV2,
respectively. At the release time, feature Y is ready, but X is not. I
guess the proposal is to move IV1 to a new MV IV3? The issue is that IV2
could have made changes on top of IV1. For example, IV2 could have evolved
the schema of the same inter broker request as IV1. In that case, what does
IV3 represent? We can't simply take the changes associated with IV1 since
it could have conflicts with IV2.

Even when there are no conflicts, I am not sure if the approach supports
the trunk deployment model. Let's say we move two unstable MV IV3 and IV4
to IV7 and IV8. If someone deployed code corresponding to IV4 and later
upgraded the code to IV7, he/she (1) wouldn't be able to set IV4 in the
upgrade code since it no longer exists and (2) would be surprised that the
request protocol that worked under IV4 doesn't work now.

Thanks,

Jun

On Fri, Jan 19, 2024 at 2:13 PM Artem Livshits
 wrote:

> Hi Colin,
>
> >  I think feature flags are somewhat orthogonal to the stable / unstable
> discussion
>
> I think feature flags can be used as an alternative to achieve similar
> results as stable / unstable functionality.  As well as long-lived feature
> branches.  In my experience, I've seen feature flags to be more successful
> than feature branches for changes of existing functionality.  I also think
> that stable / unstable MV would work better than feature branches. I just
> wanted to mention it for completeness, not sure if we should start a full
> fledged discussion on these topics.
>
> > I'm struggling a bit with your phrasing. Are you suggesting that unstable
> MVs would not be able to be in trunk?
>
> Unstable MV should be in trunk.  The wording is related to when we can
> promote "unstable" to "stable".
>
> -Artem
>
>
> On Mon, Jan 15, 2024 at 10:03 PM Colin McCabe  wrote:
>
> > On Fri, Jan 12, 2024, at 11:32, Artem Livshits wrote:
> > > I think using feature flags (whether we support a framework and tooling
> > for
> > > feature flags or just an ad-hoc XyzEnabled flag) can be an alternative
> to
> > > this KIP.  I think the value of this KIP is that it's trying to
> propose a
> > > systemic approach for gating functionality that may take multiple
> > releases
> > > to develop.  A problem with ad-hoc feature flags is that it's useful
> > during
> > > feature development, so that people who are working on this feature (or
> > are
> > > interested in beta-testing the feature) can get early access (without
> any
> > > guarantees on compatibility or even correctness); but then the feature
> > > flags often stick forever after the feature development is done (and as
> > > time moves one, the new code is written in such a way that it's not
> > > possible to turn the feature off any more cleanly).
> > >
> >
> > Hi Artem,
> >
> > I think feature flags are somewhat orthogonal to the stable / unstable
> > discussion. Even if every new feature was a feature flag, you probably
> > still wouldn't want to stabilize the features immediately, to avoid
> > maintaining a lot of alpha stuff forever.
> >
> > (I also think that feature flags should be used sparingly, if at all,
> > because of the way that they exponentially increase the test matrix. But
> > that's a tangent, I think, given the first point...)
> >
> > >
> > > I'd also clarify how I think about "stable".  Ismael made a comment "
> > > something is stable in the "this is battle-tested" sense.".  I don't
> > think
> > > it has to be "battle-tested", it just has to meet the bar of being in
> the
> > > trunk.  Again, thinking of a small single-commit feature -- to commit
> to
> > > trunk, the feature doesn't have to be "battle-tested", but it should be
> > > complete (and not just a bunch of TODOs), with tests written and some
> > level
> > > of dev-testing done, so that once the release is cut, we can find and
> fix
> > > bugs and make it release-quality (as opposed to reverting the whole
> > > thing).  We can apply the same "stability" bar for features to be in
> the
> > > stable MV -- fully complete, tests written and some level of dev
> testing
> > > done.
> > >
> >
> > I'm struggling a bit with your phrasing. Are you suggesting that unstable
> > MVs would not be able to be in trunk? I think we do want them to be able
> to
> > go into trunk. If they have to go into a branch, then there is actually
> no
> > need for any of this.
> >
> > Doing big features in long-lived branches is one genuine alternative to
> > unstable MVs, I think. But it's not an alternative that works well with
> our
> > current tooling for continuous integration, deployment, building, etc. I
> > think it would also impact developer productivity somewhat negatively.
> >
> > best,
> > Colin
> >
> >
> > >
> > > -Artem
> > >
> > > On Fri, Jan 12, 2024 at 10:12 AM Justine Olshan
> > >  wrote:
> > >
> > >> Hi Ismael,
> > >>
> > >>

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan commented on PR #567:
URL: https://github.com/apache/kafka-site/pull/567#issuecomment-1906795135

   The Cisco and Allegrograph images seem really tiny, but maybe they look ok 
on the page? Can you share a screenshot of the example? I can also pull this 
and run the pr code.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan commented on PR #567:
URL: https://github.com/apache/kafka-site/pull/567#issuecomment-1906803674

   ![Screen Shot 2024-01-23 at 11 41 51 
AM](https://github.com/apache/kafka-site/assets/25566826/5034a41d-066b-42a8-9261-98ea8c7d884d)
   ![Screen Shot 2024-01-23 at 11 41 40 
AM](https://github.com/apache/kafka-site/assets/25566826/112e52cd-d480-41b0-bd0b-5da1bb087e74)
   
   OK -- seems fine


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

dsmmcken commented on PR #567:
URL: https://github.com/apache/kafka-site/pull/567#issuecomment-1906805845

   Yeah, for some reason GitHub shows the sizes relative to the other one. So 
since the original was 7826px (!!), the new one at 320px looks tiny in the PR 
review.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan commented on code in PR #567:
URL: https://github.com/apache/kafka-site/pull/567#discussion_r1463915381


##
powered-by.html:
##
@@ -808,6 +813,22 @@ Want to appear on this page?
 
 

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan commented on code in PR #567:
URL: https://github.com/apache/kafka-site/pull/567#discussion_r1463915381


##
powered-by.html:
##
@@ -808,6 +813,22 @@ Want to appear on this page?
 
 

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

dsmmcken commented on code in PR #567:
URL: https://github.com/apache/kafka-site/pull/567#discussion_r1463920841


##
powered-by.html:
##
@@ -808,6 +813,22 @@ Want to appear on this page?
 
 

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan commented on code in PR #567:
URL: https://github.com/apache/kafka-site/pull/567#discussion_r1463926267


##
powered-by.html:
##
@@ -808,6 +813,22 @@ Want to appear on this page?
 
 

Re: [VOTE] 3.7.0 RC2

[Stanislav Kozlovski]

Hey all, I figured I'd give an update about what known blockers we have
right now:

- KAFKA-16101: KRaft migration rollback documentation is incorrect -
https://github.com/apache/kafka/pull/15193; This need not block RC
creation, but we need the docs updated so that people can test properly
- KAFKA-14616: Topic recreation with offline broker causes permanent URPs -
https://github.com/apache/kafka/pull/15230 ; I am of the understanding that
this is blocking JBOD for 3.7
- KAFKA-16162: New created topics are unavailable after upgrading to 3.7 -
a strict blocker with an open PR https://github.com/apache/kafka/pull/15232
- although I understand Proveen is out of office
- KAFKA-16082: JBOD: Possible dataloss when moving leader partition - I am
hearing mixed opinions on whether this is a blocker (
https://github.com/apache/kafka/pull/15136)

Given that there are 3 JBOD blocker bugs, and I am not confident they will
all be merged this week - I am on the edge of voting to revert JBOD from
this release, or mark it early access.

By all accounts, it seems that if we keep with JBOD the release will have
to spill into February, which is a month extra from the time-based release
plan we had of start of January.

Can I ask others for an opinion?

Best,
Stan

On Thu, Jan 18, 2024 at 1:21 PM Luke Chen  wrote:

> Hi all,
>
> I think I've found another blocker issue: KAFKA-16162
>  .
> The impact is after upgrading to 3.7.0, any new created topics/partitions
> will be unavailable.
> I've put my findings in the JIRA.
>
> Thanks.
> Luke
>
> On Thu, Jan 18, 2024 at 9:50 AM Matthias J. Sax  wrote:
>
> > Stan, thanks for driving this all forward! Excellent job.
> >
> > About
> >
> > > StreamsStandbyTask - https://issues.apache.org/jira/browse/KAFKA-16141
> > > StreamsUpgradeTest - https://issues.apache.org/jira/browse/KAFKA-16139
> >
> > For `StreamsUpgradeTest` it was a test setup issue and should be fixed
> > now in trunk and 3.7 (and actually also in 3.6...)
> >
> > For `StreamsStandbyTask` the failing test exposes a regression bug, so
> > it's a blocker. I updated the ticket accordingly. We already have an
> > open PR that reverts the code introducing the regression.
> >
> >
> > -Matthias
> >
> > On 1/17/24 9:44 AM, Proven Provenzano wrote:
> > > We have another blocking issue for the RC :
> > > https://issues.apache.org/jira/browse/KAFKA-16157. This bug is similar
> > to
> > > https://issues.apache.org/jira/browse/KAFKA-14616. The new issue
> however
> > > can lead to the new topic having partitions that a producer cannot
> write
> > to.
> > >
> > > --Proven
> > >
> > > On Tue, Jan 16, 2024 at 12:04 PM Proven Provenzano <
> > pprovenz...@confluent.io>
> > > wrote:
> > >
> > >>
> > >> I have a PR https://github.com/apache/kafka/pull/15197 for
> > >> https://issues.apache.org/jira/browse/KAFKA-16131 that is building
> now.
> > >> --Proven
> > >>
> > >> On Mon, Jan 15, 2024 at 5:03 AM Jakub Scholz  wrote:
> > >>
> > >>> *> Hi Jakub,> > Thanks for trying the RC. I think what you found is a
> > >>> blocker bug because it *
> > >>> *> will generate huge amount of logspam. I guess we didn't find it in
> > >>> junit
> > >>> tests *
> > >>> *> since logspam doesn't fail the automated tests. But certainly it's
> > not
> > >>> suitable *
> > >>> *> for production. Did you file a JIRA yet?*
> > >>>
> > >>> Hi Colin,
> > >>>
> > >>> I opened https://issues.apache.org/jira/browse/KAFKA-16131.
> > >>>
> > >>> Thanks & Regards
> > >>> Jakub
> > >>>
> > >>> On Mon, Jan 15, 2024 at 8:57 AM Colin McCabe 
> > wrote:
> > >>>
> >  Hi Stanislav,
> > 
> >  Thanks for making the first RC. The fact that it's titled RC2 is
> > messing
> >  with my mind a bit. I hope this doesn't make people think that we're
> >  farther along than we are, heh.
> > 
> >  On Sun, Jan 14, 2024, at 13:54, Jakub Scholz wrote:
> > > *> Nice catch! It does seem like we should have gated this behind
> the
> > > metadata> version as KIP-858 implies. Is the cluster configured
> with
> > > multiple log> dirs? What is the impact of the error messages?*
> > >
> > > I did not observe any obvious impact. I was able to send and
> receive
> > > messages as normally. But to be honest, I have no idea what else
> > > this might impact, so I did not try anything special.
> > >
> > > I think everyone upgrading an existing KRaft cluster will go
> through
> > >>> this
> > > stage (running Kafka 3.7 with an older metadata version for at
> least
> > a
> > > while). So even if it is just a logged exception without any other
> >  impact I
> > > wonder if it might scare users from upgrading. But I leave it to
> > >>> others
> >  to
> > > decide if this is a blocker or not.
> > >
> > 
> >  Hi Jakub,
> > 
> >  Thanks for trying the RC. I think what you found is a blocker bug
> > >>> because
> >  it will generate huge amount of logspam. I

[jira] [Created] (KAFKA-16187) Flaky test: testTopicPatternArg - org.apache.kafka.tools.GetOffsetShellTest

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-16187:
-

 Summary: Flaky test: testTopicPatternArg - 
org.apache.kafka.tools.GetOffsetShellTest
 Key: KAFKA-16187
 URL: https://issues.apache.org/jira/browse/KAFKA-16187
 Project: Kafka
  Issue Type: Bug
Reporter: Apoorv Mittal


[https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka-pr/detail/PR-15234/8/tests/]

 
{code:java}
Errororg.opentest4j.AssertionFailedError: expected: 
<[org.apache.kafka.tools.GetOffsetShellTest$Row@c6f09cc2, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a084, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a0a3, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a446, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a465, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a484, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a808, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a827, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a846, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a865]> but was: 
<[org.apache.kafka.tools.GetOffsetShellTest$Row@c6f09cc2, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a084, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a446, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a808]>Stacktraceorg.opentest4j.AssertionFailedError:
 expected: <[org.apache.kafka.tools.GetOffsetShellTest$Row@c6f09cc2, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a084, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a0a3, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a446, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a465, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a484, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a808, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a827, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a846, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a865]> but was: 
<[org.apache.kafka.tools.GetOffsetShellTest$Row@c6f09cc2, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a084, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a446, 
org.apache.kafka.tools.GetOffsetShellTest$Row@c6f0a808]>   at 
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
   at 
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
   at 
app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)  at 
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)  at 
app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)  at 
app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141) at 
app//org.apache.kafka.tools.GetOffsetShellTest.testTopicPatternArg(GetOffsetShellTest.java:154)
  at 
java.base@21.0.1/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
 at java.base@21.0.1/java.lang.reflect.Method.invoke(Method.java:580)at 
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
  at 
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
   at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
 at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
  at 
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestTemplateMethod(TimeoutExtension.java:94)
   at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
 at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
   at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at 
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
  at 
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
  at 
app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:218)
   at 
app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.

[jira] [Resolved] (KAFKA-15683) Delete subscription from metadata when all configs are deleted

[Apoorv Mittal (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Apoorv Mittal resolved KAFKA-15683.
---
Resolution: Not A Problem

Closing ticket as this is not required, it works as per the default behaviour 
of kafka-configs.sh. Moreover ClientMetricsManager deletes the in-memory 
subscription/client resources once all properties for respective resource are 
removed. This is not needed.

> Delete subscription from metadata when all configs are deleted
> --
>
> Key: KAFKA-15683
> URL: https://issues.apache.org/jira/browse/KAFKA-15683
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Apoorv Mittal
>Assignee: Apoorv Mittal
>Priority: Major
>
> As of now the kafka-configs.sh do not differentiate on non-existent and blank 
> metrics subscription. Add support to differentiate in 2 scenarios and also 
> delete the subscription if all configs are delete for respective 
> subscription. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.6 #140

[Apache Jenkins Server]

See 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.7 #73

[Apache Jenkins Server]

See 

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

dsmmcken commented on PR #567:
URL: https://github.com/apache/kafka-site/pull/567#issuecomment-1906929519

   Thanks! FYI I don't have write access, so please merge if you are able.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] MINOR: Sort powered by page output alphabetically [kafka-site]

[via GitHub]

jolshan merged PR #567:
URL: https://github.com/apache/kafka-site/pull/567


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2598

[Apache Jenkins Server]

See 

Re: [VOTE] 3.7.0 RC2

[Justine Olshan]

Hey Stan,

Just wanted to clarify -- KAFKA-14616 is not particularly related to JBOD
but to ZK -> KRaft migration.

There were some other related migration bugs like
https://issues.apache.org/jira/browse/KAFKA-16180.

This may or may not influence decisions, but wanted to paint the full
picture of the blocker bugs and their causes.

Justine


On Tue, Jan 23, 2024 at 12:17 PM Stanislav Kozlovski
 wrote:

> Hey all, I figured I'd give an update about what known blockers we have
> right now:
>
> - KAFKA-16101: KRaft migration rollback documentation is incorrect -
> https://github.com/apache/kafka/pull/15193; This need not block RC
> creation, but we need the docs updated so that people can test properly
> - KAFKA-14616: Topic recreation with offline broker causes permanent URPs -
> https://github.com/apache/kafka/pull/15230 ; I am of the understanding
> that
> this is blocking JBOD for 3.7
> - KAFKA-16162: New created topics are unavailable after upgrading to 3.7 -
> a strict blocker with an open PR
> https://github.com/apache/kafka/pull/15232
> - although I understand Proveen is out of office
> - KAFKA-16082: JBOD: Possible dataloss when moving leader partition - I am
> hearing mixed opinions on whether this is a blocker (
> https://github.com/apache/kafka/pull/15136)
>
> Given that there are 3 JBOD blocker bugs, and I am not confident they will
> all be merged this week - I am on the edge of voting to revert JBOD from
> this release, or mark it early access.
>
> By all accounts, it seems that if we keep with JBOD the release will have
> to spill into February, which is a month extra from the time-based release
> plan we had of start of January.
>
> Can I ask others for an opinion?
>
> Best,
> Stan
>
> On Thu, Jan 18, 2024 at 1:21 PM Luke Chen  wrote:
>
> > Hi all,
> >
> > I think I've found another blocker issue: KAFKA-16162
> >  .
> > The impact is after upgrading to 3.7.0, any new created topics/partitions
> > will be unavailable.
> > I've put my findings in the JIRA.
> >
> > Thanks.
> > Luke
> >
> > On Thu, Jan 18, 2024 at 9:50 AM Matthias J. Sax 
> wrote:
> >
> > > Stan, thanks for driving this all forward! Excellent job.
> > >
> > > About
> > >
> > > > StreamsStandbyTask -
> https://issues.apache.org/jira/browse/KAFKA-16141
> > > > StreamsUpgradeTest -
> https://issues.apache.org/jira/browse/KAFKA-16139
> > >
> > > For `StreamsUpgradeTest` it was a test setup issue and should be fixed
> > > now in trunk and 3.7 (and actually also in 3.6...)
> > >
> > > For `StreamsStandbyTask` the failing test exposes a regression bug, so
> > > it's a blocker. I updated the ticket accordingly. We already have an
> > > open PR that reverts the code introducing the regression.
> > >
> > >
> > > -Matthias
> > >
> > > On 1/17/24 9:44 AM, Proven Provenzano wrote:
> > > > We have another blocking issue for the RC :
> > > > https://issues.apache.org/jira/browse/KAFKA-16157. This bug is
> similar
> > > to
> > > > https://issues.apache.org/jira/browse/KAFKA-14616. The new issue
> > however
> > > > can lead to the new topic having partitions that a producer cannot
> > write
> > > to.
> > > >
> > > > --Proven
> > > >
> > > > On Tue, Jan 16, 2024 at 12:04 PM Proven Provenzano <
> > > pprovenz...@confluent.io>
> > > > wrote:
> > > >
> > > >>
> > > >> I have a PR https://github.com/apache/kafka/pull/15197 for
> > > >> https://issues.apache.org/jira/browse/KAFKA-16131 that is building
> > now.
> > > >> --Proven
> > > >>
> > > >> On Mon, Jan 15, 2024 at 5:03 AM Jakub Scholz 
> wrote:
> > > >>
> > > >>> *> Hi Jakub,> > Thanks for trying the RC. I think what you found
> is a
> > > >>> blocker bug because it *
> > > >>> *> will generate huge amount of logspam. I guess we didn't find it
> in
> > > >>> junit
> > > >>> tests *
> > > >>> *> since logspam doesn't fail the automated tests. But certainly
> it's
> > > not
> > > >>> suitable *
> > > >>> *> for production. Did you file a JIRA yet?*
> > > >>>
> > > >>> Hi Colin,
> > > >>>
> > > >>> I opened https://issues.apache.org/jira/browse/KAFKA-16131.
> > > >>>
> > > >>> Thanks & Regards
> > > >>> Jakub
> > > >>>
> > > >>> On Mon, Jan 15, 2024 at 8:57 AM Colin McCabe 
> > > wrote:
> > > >>>
> > >  Hi Stanislav,
> > > 
> > >  Thanks for making the first RC. The fact that it's titled RC2 is
> > > messing
> > >  with my mind a bit. I hope this doesn't make people think that
> we're
> > >  farther along than we are, heh.
> > > 
> > >  On Sun, Jan 14, 2024, at 13:54, Jakub Scholz wrote:
> > > > *> Nice catch! It does seem like we should have gated this behind
> > the
> > > > metadata> version as KIP-858 implies. Is the cluster configured
> > with
> > > > multiple log> dirs? What is the impact of the error messages?*
> > > >
> > > > I did not observe any obvious impact. I was able to send and
> > receive
> > > > messages as normally. But to be honest, I have no idea what else
> > > > this migh

Re: [VOTE] 3.7.0 RC2

[Justine Olshan]

Oops sorry I got confused between
https://issues.apache.org/jira/browse/KAFKA-16120 (migration issue) and
https://issues.apache.org/jira/browse/KAFKA-14616 (not migration issue)

However, both do not seem related to JBOD based on the jira and PRs

Justine

On Tue, Jan 23, 2024 at 1:51 PM Justine Olshan  wrote:

> Hey Stan,
>
> Just wanted to clarify -- KAFKA-14616 is not particularly related to JBOD
> but to ZK -> KRaft migration.
>
> There were some other related migration bugs like
> https://issues.apache.org/jira/browse/KAFKA-16180.
>
> This may or may not influence decisions, but wanted to paint the full
> picture of the blocker bugs and their causes.
>
> Justine
>
>
> On Tue, Jan 23, 2024 at 12:17 PM Stanislav Kozlovski
>  wrote:
>
>> Hey all, I figured I'd give an update about what known blockers we have
>> right now:
>>
>> - KAFKA-16101: KRaft migration rollback documentation is incorrect -
>> https://github.com/apache/kafka/pull/15193; This need not block RC
>> creation, but we need the docs updated so that people can test properly
>> - KAFKA-14616: Topic recreation with offline broker causes permanent URPs
>> -
>> https://github.com/apache/kafka/pull/15230 ; I am of the understanding
>> that
>> this is blocking JBOD for 3.7
>> - KAFKA-16162: New created topics are unavailable after upgrading to 3.7 -
>> a strict blocker with an open PR
>> https://github.com/apache/kafka/pull/15232
>> - although I understand Proveen is out of office
>> - KAFKA-16082: JBOD: Possible dataloss when moving leader partition - I am
>> hearing mixed opinions on whether this is a blocker (
>> https://github.com/apache/kafka/pull/15136)
>>
>> Given that there are 3 JBOD blocker bugs, and I am not confident they will
>> all be merged this week - I am on the edge of voting to revert JBOD from
>> this release, or mark it early access.
>>
>> By all accounts, it seems that if we keep with JBOD the release will have
>> to spill into February, which is a month extra from the time-based release
>> plan we had of start of January.
>>
>> Can I ask others for an opinion?
>>
>> Best,
>> Stan
>>
>> On Thu, Jan 18, 2024 at 1:21 PM Luke Chen  wrote:
>>
>> > Hi all,
>> >
>> > I think I've found another blocker issue: KAFKA-16162
>> >  .
>> > The impact is after upgrading to 3.7.0, any new created
>> topics/partitions
>> > will be unavailable.
>> > I've put my findings in the JIRA.
>> >
>> > Thanks.
>> > Luke
>> >
>> > On Thu, Jan 18, 2024 at 9:50 AM Matthias J. Sax 
>> wrote:
>> >
>> > > Stan, thanks for driving this all forward! Excellent job.
>> > >
>> > > About
>> > >
>> > > > StreamsStandbyTask -
>> https://issues.apache.org/jira/browse/KAFKA-16141
>> > > > StreamsUpgradeTest -
>> https://issues.apache.org/jira/browse/KAFKA-16139
>> > >
>> > > For `StreamsUpgradeTest` it was a test setup issue and should be fixed
>> > > now in trunk and 3.7 (and actually also in 3.6...)
>> > >
>> > > For `StreamsStandbyTask` the failing test exposes a regression bug, so
>> > > it's a blocker. I updated the ticket accordingly. We already have an
>> > > open PR that reverts the code introducing the regression.
>> > >
>> > >
>> > > -Matthias
>> > >
>> > > On 1/17/24 9:44 AM, Proven Provenzano wrote:
>> > > > We have another blocking issue for the RC :
>> > > > https://issues.apache.org/jira/browse/KAFKA-16157. This bug is
>> similar
>> > > to
>> > > > https://issues.apache.org/jira/browse/KAFKA-14616. The new issue
>> > however
>> > > > can lead to the new topic having partitions that a producer cannot
>> > write
>> > > to.
>> > > >
>> > > > --Proven
>> > > >
>> > > > On Tue, Jan 16, 2024 at 12:04 PM Proven Provenzano <
>> > > pprovenz...@confluent.io>
>> > > > wrote:
>> > > >
>> > > >>
>> > > >> I have a PR https://github.com/apache/kafka/pull/15197 for
>> > > >> https://issues.apache.org/jira/browse/KAFKA-16131 that is building
>> > now.
>> > > >> --Proven
>> > > >>
>> > > >> On Mon, Jan 15, 2024 at 5:03 AM Jakub Scholz 
>> wrote:
>> > > >>
>> > > >>> *> Hi Jakub,> > Thanks for trying the RC. I think what you found
>> is a
>> > > >>> blocker bug because it *
>> > > >>> *> will generate huge amount of logspam. I guess we didn't find
>> it in
>> > > >>> junit
>> > > >>> tests *
>> > > >>> *> since logspam doesn't fail the automated tests. But certainly
>> it's
>> > > not
>> > > >>> suitable *
>> > > >>> *> for production. Did you file a JIRA yet?*
>> > > >>>
>> > > >>> Hi Colin,
>> > > >>>
>> > > >>> I opened https://issues.apache.org/jira/browse/KAFKA-16131.
>> > > >>>
>> > > >>> Thanks & Regards
>> > > >>> Jakub
>> > > >>>
>> > > >>> On Mon, Jan 15, 2024 at 8:57 AM Colin McCabe 
>> > > wrote:
>> > > >>>
>> > >  Hi Stanislav,
>> > > 
>> > >  Thanks for making the first RC. The fact that it's titled RC2 is
>> > > messing
>> > >  with my mind a bit. I hope this doesn't make people think that
>> we're
>> > >  farther along than we are, heh.
>> > > 
>> > >  On Sun, Jan 14, 2024, a

[jira] [Resolved] (KAFKA-15813) Improve implementation of client instance cache

[Jun Rao (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-15813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jun Rao resolved KAFKA-15813.
-
Fix Version/s: 3.8.0
   Resolution: Fixed

Merged to the PR to trunk.

> Improve implementation of client instance cache
> ---
>
> Key: KAFKA-15813
> URL: https://issues.apache.org/jira/browse/KAFKA-15813
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Apoorv Mittal
>Assignee: Apoorv Mittal
>Priority: Major
> Fix For: 3.8.0
>
>
> In the current implementation the ClientMetricsManager uses LRU cache but we 
> should alos support expiring stale clients i.e. client which haven't reported 
> metrics for a while.
>  
> The KIP mentions: This client instance specific state is maintained in broker 
> memory up to MAX(60*1000, PushIntervalMs * 3) milliseconds and is used to 
> enforce the push interval rate-limiting. There is no persistence of client 
> instance metrics state across broker restarts or between brokers 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #2599

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 461005 lines...]
Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testUpdateExistingPartitions() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testEmptyWrite() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testEmptyWrite() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testReadMigrateAndWriteProducerId() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testReadMigrateAndWriteProducerId() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testExistingKRaftControllerClaim() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testExistingKRaftControllerClaim() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testMigrateTopicConfigs() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testMigrateTopicConfigs() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testNonIncreasingKRaftEpoch() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testNonIncreasingKRaftEpoch() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testMigrateEmptyZk() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testMigrateEmptyZk() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testTopicAndBrokerConfigsMigrationWithSnapshots() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testTopicAndBrokerConfigsMigrationWithSnapshots() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testClaimAndReleaseExistingController() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testClaimAndReleaseExistingController() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testClaimAbsentController() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testClaimAbsentController() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testIdempotentCreateTopics() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testIdempotentCreateTopics() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testCreateNewTopic() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testCreateNewTopic() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testUpdateExistingTopicWithNewAndChangedPartitions() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZkMigrationClientTest > 
testUpdateExistingTopicWithNewAndChangedPartitions() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testGetChildrenExistingZNode() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testGetChildrenExistingZNode() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testConnection() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testConnection() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZNodeChangeHandlerForCreation() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testZNodeChangeHandlerForCreation() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testGetAclExistingZNode() STARTED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testGetAclExistingZNode() PASSED

Gradle Test Run :core:test > Gradle Test Executor 92 > ZooKeeperClientTest > 
testSessionExpiryDuringClose() STARTED

Gradle Test Run :core:test > Gr

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #2600

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 345761 lines...]

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkAclMigrationClientTest 
> testAclsChangesInSnapshot() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkAclMigrationClientTest 
> testAclsMigrateAndDualWrite() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkAclMigrationClientTest 
> testAclsMigrateAndDualWrite() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testUpdateExistingPartitions() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testUpdateExistingPartitions() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testEmptyWrite() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testEmptyWrite() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testReadMigrateAndWriteProducerId() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testReadMigrateAndWriteProducerId() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testExistingKRaftControllerClaim() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testExistingKRaftControllerClaim() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testMigrateTopicConfigs() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testMigrateTopicConfigs() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testNonIncreasingKRaftEpoch() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testNonIncreasingKRaftEpoch() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testMigrateEmptyZk() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testMigrateEmptyZk() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testTopicAndBrokerConfigsMigrationWithSnapshots() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testTopicAndBrokerConfigsMigrationWithSnapshots() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testClaimAndReleaseExistingController() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testClaimAndReleaseExistingController() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testClaimAbsentController() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testClaimAbsentController() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testIdempotentCreateTopics() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testIdempotentCreateTopics() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testCreateNewTopic() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testCreateNewTopic() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testUpdateExistingTopicWithNewAndChangedPartitions() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZkMigrationClientTest > 
testUpdateExistingTopicWithNewAndChangedPartitions() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testGetChildrenExistingZNode() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testGetChildrenExistingZNode() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testConnection() STARTED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testConnection() PASSED

Gradle Test Run :core:test > Gradle Test Executor 97 > ZooKeeperClientTest > 
testZNodeChangeHandlerForCreation() STARTED

Gradle Test R

Re: [VOTE] KIP-1011: Use incrementalAlterConfigs when updating broker configs by kafka-configs.sh

[ziming deng]

Hello Ismael,
I have tested it locally to verified again that this issue only affect 
append/subtract, I also commented in the JIRA ticket to clarify this.

Best,
Ziming


> On Jan 23, 2024, at 23:07, Ismael Juma  wrote:
> 
> Hi Ziming,
> 
> Have you verified that the issue only impacts append/subtract? The way I
> read the JIRA is that the issue currently affects all operations for
> plugins, but it can be fixed to only affect append/subtract (where it would
> be harder to fix). It would be good to verify the current state.
> 
> Ismael
> 
> On Mon, Jan 22, 2024 at 9:07 PM ziming deng 
> wrote:
> 
>> Hello David,
>> 
>> Thanks for reminding this, as Chirs explained, the tools I’m trying to
>> update only support set/delete configs, and I’m just make a way for
>> append/subtract configs in the future, so this would not be affected by
>> KAFKA-10140, and it would be a little overkill to support append/subtract
>> configs or solve KAFKA-10140 here, so let’s leave it right now, I'm happy
>> to pick it after finishing this KIP.
>> 
>> --,
>> Ziming
>> 
>>> On Jan 22, 2024, at 18:23, David Jacot 
>> wrote:
>>> 
>>> Hi Ziming,
>>> 
>>> Thanks for driving this. I wanted to bring KAFKA-10140
>>>  to your attention.
>> It
>>> looks like the incremental API does not work for configuring plugins. I
>>> think that we need to cover this in the KIP.
>>> 
>>> Best,
>>> David
>>> 
>>> On Mon, Jan 22, 2024 at 10:13 AM Andrew Schofield <
>>> andrew_schofield_j...@outlook.com> wrote:
>>> 
 +1 (non-binding)
 
 Thanks,
 Andrew
 
> On 22 Jan 2024, at 07:29, Federico Valeri 
>> wrote:
> 
> +1 (non binding)
> 
> Thanks.
> 
> On Mon, Jan 22, 2024 at 7:03 AM Luke Chen  wrote:
>> 
>> Hi Ziming,
>> 
>> +1(binding) from me.
>> 
>> Thanks.
>> Luke
>> 
>> On Mon, Jan 22, 2024 at 11:50 AM Kamal Chandraprakash <
>> kamal.chandraprak...@gmail.com> wrote:
>> 
>>> +1 (non-binding)
>>> 
>>> On Mon, Jan 22, 2024 at 8:34 AM ziming deng <
>> dengziming1...@gmail.com>
>>> wrote:
>>> 
 Hello everyone,
 I'd like to initiate a vote for KIP-1011.
 This KIP is about replacing alterConfigs with
>> incrementalAlterConfigs
 when updating broker configs using kafka-configs.sh, this is similar
 to
 what we have done in KIP-894.
 
 KIP link:
 KIP-1011: Use incrementalAlterConfigs when updating broker configs
>> by
 kafka-configs.sh - Apache Kafka - Apache Software Foundation
 <
 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> 
 cwiki.apache.org
 <
 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> 
 [image: favicon.ico]
 <
 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> 
 <
 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1011%3A+Use+incrementalAlterConfigs+when+updating+broker+configs+by+kafka-configs.sh
> 
 
 Discussion thread:
 
 
 lists.apache.org
 
 
 
 
 
 --,
 Best,
 Ziming
 
 
 
>> 
>>