Re: [ANNOUNCE] New Kafka PMC member: Lucas Brutschy

Congratulations Lucas! On Tue, Jul 15, 2025 at 10:08 AM Lianet M. wrote: > > Congrats Lucas! > > On Tue, Jul 15, 2025, 2:27 p.m. Andrew Schofield < > andrew_schofield_j...@outlook.com> wrote: > > > Congratulations Lucas. > > > > > > From: Apoorv Mittal >

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Kevin, I recently ran into.a case where the controllers and brokers were reporting a metadata version value in the metrics which was the minimum value even though the cluster had been previously finalized with a different value for the metadata version. After some investigation, this is because

Re: [VOTE] KIP-1186: Update AddRaftVoterRequest RPC to support auto-join

Thanks for the KIP. +1 binding. On Tue, Jun 17, 2025 at 6:31 PM Alyssa Huang wrote: > > Thanks for the KIP Kevin! > > +1 (non-binding) > > On Tue, Jun 17, 2025 at 7:57 AM Kevin Wu wrote: > > > Hello all, > > > > I would like to call a vote for KIP-1186: Update AddRaftVoterRequest RPC to > > supp

Re: [ANNOUNCE] New Kafka PMC Member: José Armando García Sancio

Thanks everyone! Looking forward to helping out with the PMC responsibilities. On Mon, Jun 16, 2025 at 9:59 PM Kuan-Po Tseng wrote: > > Congrats José!!! > > On Tue, Jun 17, 2025 at 9:38 AM Matthias J. Sax wrote: > > > Congrats! > > > > On 6/16/25 3:54 PM, ziming deng wrote: > > > Congratulations

Re: [DISCUSS] KIP-1186: Update AddRaftVoterRequest RPC to support auto-join

Thanks for the KIP Kevin. The motivation is clear to me and beneficial for implementing the auto-join feature designed in KIP-853. In the "Compatibility ..." section you state the following: "To make this change backwards compatible, we can make this field ignorable. This ensures compatibility bet

Re: [DISCUSS] Apache Kafka 4.1.0 release

t; > > For KIP-1142, it's almost finished. One remaining PR is about > > > compatibility > > > > > > of missing metric. > > > > > > * https://github.com/apache/kafka/pull/19877 > > > > > > > > > > >

Re: KRaft Observer node unable to recover after (re-)bootstrapping to Follower node

t; On Fri, May 30, 2025 at 11:47 AM José Armando García Sancio > wrote: > > > Thanks for the bug report Justin. Looks like a bug to me. Please file > > a Jira with these details and share it in this thread. > > > > -- > > -José > > > > > -- > Regards, > Justin Chen -- -José

Re: KRaft Observer node unable to recover after (re-)bootstrapping to Follower node

Thanks for the bug report Justin. Looks like a bug to me. Please file a Jira with these details and share it in this thread. -- -José

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

Hi Colin, On Tue, May 27, 2025 at 8:57 PM Colin McCabe wrote: > My argument was that it would be unlikely that all three of these things > would be true. One reason why I think this is that 3.7-IV3 is a pretty old MV > at this point anyway. Then why not enforce that in the KIP and code? You ar

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

Hi Colin, On Fri, May 2, 2025 at 6:52 PM Colin McCabe wrote: > > On Fri, May 2, 2025, at 09:54, José Armando García Sancio wrote: > That seems pretty clear? It's also already implemented (although not used > since we don't have any inter-dependent features yet). I see. Th

Re: [VOTE] KIP-1180: Add generic feature level metrics

LGTM. +1 (binding) On Thu, May 22, 2025 at 2:06 PM Chia-Ping Tsai wrote: > > +1 (binding) > > Kevin Wu 於 2025年5月23日 週五 上午1:42寫道： > > > Hello all, > > > > I would like to call a vote for KIP-1180: Add generic feature level > > metrics. > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Kevin, On Thu, May 15, 2025 at 10:52 AM Kevin Wu wrote: > Thanks for all the comments about the metric type field for the minimum and > maximum supported feature levels. I agree they are software version > specific. Also, since they are shared across the broker and controller like > the Finali

Re: [DISCUSS] Apache Kafka 4.1.0 release

HI Mickael, I have added "KIP-1166: Improve high-watermark replication" to the 4.1.0 release wiki page. Thanks, -- -José

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Kevin, The metrics that you added for supported versions, " kafka.controller:type=KafkaController,name=MaximumSupportedLevel,featureName=X" and "kafka.server:type=broker-metadata-metrics,name=maximum-supported-feature-level,featureName=X", the metric group name doesn't seem accurate. Those met

Re: [DISCUSS] Apache Kafka 3.9.1 release

HI TengYao and Luke, I would like to cherry-pick the commit for this issue (https://issues.apache.org/jira/browse/KAFKA-18345) to the 3.9 branch. I see that we are still in the process of releasing 3.9.1. My cherry pick doesn't need to be in 3.9.1 and it can wait until 3.9.2. Can I cherry pick the

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Jun, On Mon, May 12, 2025 at 7:21 PM Jun Rao wrote: > 5. Some of the metric names are camel case and some others use dash. It > would be useful to be consistent. They are consistent within their metrics group or type in JMX. I would be in favor of a KIP that standardizes how metrics are named

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

HI Kevin, On Tue, May 13, 2025 at 9:56 AM Kevin Wu wrote: > 4. Maybe I'm missing something, but I think the MetadataLoader is used by > both the broker and controller, so having the one metric works for both > node types. The CurrentMetadataVersion metric is currently reported on both > the broke

Re: [VOTE] KIP-1166: Improve high-watermark replication

Hi all, The KIP is accepted with 4 binding voters (José, Jun, David Arthur and Colin) and one non-binding vote (Alyssa). Thanks everyone that voted and participated in the discussion, -- -José

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Kevin, Thanks for the changes. For the "Rejected Alternatives" section you can state why using "kafka-feature describe" is not sufficient. Thanks, -- -José

Re: [DISCUSS] KIP-1180: Add a generic feature level metric

Hi Kevin, Thanks for the improvement and discussion. The "Monitoring" section says "Add a metric for each production feature (i.e. kraft.version , transaction.version , group.version , eligible.leader.replicas.version , and share.version )." You mentioned that the metadata version is already expo

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Mon, May 5, 2025 at 12:22 PM Jun Rao wrote: > Since MV is part of the public interface, it would be useful to call it out > explicitly. In the current KIP, it's not clear what indicates the support > of version 18 of the fetch request. Done. Added a "Metadata Version" section to the K

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Fri, May 2, 2025 at 6:57 PM Jun Rao wrote: > Thanks for the reply. You mentioned that we still need an MV, but it's no > longer in the KIP. Thanks. I mentioned the new MV in the "Sending" section of the KIP. -- -José

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Fri, May 2, 2025 at 1:47 PM Jun Rao wrote: > Since we are only doing the fast HWM propagation for the KRaft partition, > should we remove the changes in Replica manager where the leader will > unpark the follower fetch request if its HWM is larger than the follower? > Also, followers f

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

Hi Colin, On Fri, Apr 25, 2025 at 5:42 PM Colin McCabe wrote: > > The "initiating the downgrade" section states "It will also check that > > the requested metadata version is compatible with all the other > > KIP-584 features that are enabled." What do you mean by this? > > So, in Kafka version 4

[VOTE] KIP-1166: Improve high-watermark replication

Hi all, Thanks for the discussion. I would like to start the voting thread for KIP-1166: Improve high-watermark replication. If you have additional comments or questions please use the discussion thread. KIP: https://cwiki.apache.org/confluence/x/uIkEFQ Discussion thread: https://lists.apache.org

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi David, On Fri, May 2, 2025 at 11:07 AM David Arthur wrote: > DA5: Do we have a way to quantify the metadata propagation latency? In the > past, I think we have eye-balled the metadata LEO between brokers and the > active controller to approximate the lag, but maybe you've found a better > way?

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Thu, May 1, 2025 at 12:38 PM Jun Rao wrote: > We could probably just keep the new HighWatermark field as described in the > KIP, but limit it only for KRaft. Also, since HighWatermark is a tagged > field, it probably doesn't need to be gated by an MV. Yes. Because the HighWatermark fi

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Wed, Apr 30, 2025 at 6:28 PM Jun Rao wrote: > Also, KIP-392 > implemented HWM propagation without adding the HWM field in the fetch > request. Instead, the leader remembers the last propagated HWM to a > follower. I thought about this when designing the feature, mainly to avoid having

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Ismael, On Wed, Apr 30, 2025 at 5:19 PM Ismael Juma wrote: > We did indeed run into a perf regression related to increased fetch request > rate due to hw propagation to followers: > > https://issues.apache.org/jira/browse/KAFKA-9731 Thanks for the information. This is helpful. -- -José

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Wed, Apr 30, 2025 at 1:09 PM Jun Rao wrote: > JR5. The motivation section still sounds like this is a KRaft only problem. > It would be useful to cover the issue with fetch from followers too. Okay. I updated the motivation section to also talk about fetch-from-followers. I was hesita

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Alyssa, On Wed, Apr 30, 2025 at 12:52 PM Alyssa Huang wrote: > Is the intent to say that in addition to all the current conditions, > the HWM check is an additional condition that *must *be met in order for > the fetch request to be parked? Just confirming since I'm not sure if I > should inte

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Alyssa, On Tue, Apr 29, 2025 at 1:51 PM Alyssa Huang wrote: > Wondering if there is perhaps a typo - under *KRaft Handling *the wording > mentions parking the request if the HWM in the request is >= to the leader's You are correct and a good catch. There were some inconsistencies in the predi

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Colin, On Mon, Apr 28, 2025 at 8:43 PM Colin McCabe wrote: > Maybe I missed something, but even after reading the discussion below, I > still don't understand the rationale for separating the "RPC version too old" > and "high watermark not known" cases. Is the idea that separating these case

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi David, Thanks for the feedback. On Mon, Apr 28, 2025 at 2:51 PM David Arthur wrote: > DA1. It might be more clear if we call the field something like > "LastFetchedHighWaterMark" (similar to "LastFetchedEpoch"). "HighWaterMark" > is already very prevalent in ReplicaManager, so it might be nic

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

Hi Colin, Thanks for the KIP. I have a few questions and comments. The "initiating the downgrade" section states "It will also check that the requested metadata version is compatible with all the other KIP-584 features that are enabled." What do you mean by this? In the same section, you have "I

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, > On Thu, Apr 24, 2025 at 1:34 PM Jun Rao wrote: > > Also, in FetchResponse, we use -1 as the default for various offsets. > > Should we follow that convention for the new field? In KRaft, a value of -1 for the HighWatermark field in the FETCH response specifically indicates an unknown h

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, I updated the KIP to document the points you have raised. On Thu, Apr 24, 2025 at 1:34 PM Jun Rao wrote: > The follower of regular topic could have fetched to the end of the log from > the leader, but need to wait 500ms for the true HWM to be propagated. This > will delay the consumption

Re: read cluster metadata topic

Hi Peter, On Fri, Apr 25, 2025 at 10:14 AM Péter Sinóros-Szabó wrote: > I'm actually interested in all the advertised listener configs, we use a > few of them. As I see the metadata response will contain only one > listener's data, the listener I accessed Kafka through, am I right? That's correc

Re: [VOTE] KIP-1131: Improved controller-side monitoring of broker states

LGTM. +1 (binding) Thanks, -- -José

Re: [DISCUSS] KIP-1131: Controller-side monitoring for broker shutdown and startup

Hi Kevin, The KIP says the following: "However, if we want to add another value to BrokerRegistrationState that maps to starting up brokers (i.e. never unfenced), this would require adding a boolean to the broker's registration record. Additionally, if we want to track is a broker has been unclean

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, > The issue described in the KIP applies to regular topics too. If the HWM is > delayed in the follower, it could delay the consumption for a client > fetching from a follower. It would be useful to document that too. Let me look at the code again, but I think that regular topics are not

[DISCUSS] KIP-1166: Improve high-watermark replication

Hi all, I created a KIP to improve the latency for high-watermark replication. A few users have observed that their admin operations can take up 500ms before they are reflected in other parts of the system. This KIP is my attempt to resolve that issue: https://cwiki.apache.org/confluence/x/uIkEFQ

Re: read cluster metadata topic

Hi Peter, On Thu, Apr 17, 2025 at 2:44 PM Péter Sinóros-Szabó wrote: > So we need to see as brokers are stopped and restarted, so that we > get it's new IP and can update it on our service mesh configuration. Very interesting use case. First, the data stored in the __cluster_metadata-0 partition

Re: [DISCUSS] KIP-1131: Controller-side monitoring for broker shutdown and startup

Hi Colin and Kevin, On Mon, Apr 14, 2025 at 5:25 PM Colin McCabe wrote: > How about something like this? > 10 = fenced > 20 = controlled shutdown > 30 = active Very few users are going to know what these values mean. For example, I see myself having to look up the code and KIP to remember

Re: [DISCUSS] Apache Kafka 3.9.1 release

Thanks Luke. I cherry picked a few issues that we resolved in 4.0 and were tagged to be included in 3.9.1. -- -José

Re: [DISCUSS] KIP-1131: Controller-side monitoring for broker shutdown and startup

Thanks for the improvement Kevin. I got a chance to look at the KIP. 1. kafka.controller:type=KafkaController,name=BrokerRegistrationState.kafka-X Can we use tags or attributes instead of different names? For example, how about kafka.controller:type=KafkaController,name=BrokerRegistrationState,

Re: KRaft controller disaster recovery

Hi Luke and Colin, On Mon, Apr 7, 2025 at 10:29 PM Luke Chen wrote: > That's why we were discussing if there's any way to "force" recover the > scenario, even if it's possible to have data loss. Yes. There is a way. They need to configure a controller cluster that matches the voter set in the cl

Re: KRaft controller disaster recovery

Thanks Luke. On Thu, Apr 3, 2025 at 7:14 AM Luke Chen wrote: > In addition to the approaches you provided, maybe we can have a way to > "force" KRaft to honor "controller.quorum.voters" config, instead of > "controller.quorum.bootstrap.servers", even it's in kraft.version 1. Small clarification.

Re: KRaft controller disaster recovery

HI Juha, That's for the discussion. On Thu, Apr 3, 2025 at 4:08 AM Juha Mynttinen wrote: >Consider the following Kafka controller setup. There are three controllers > c1, c2 and c3, each on its own hardware. All controllers are voters and > let’s assume c1 is the leader. Assume new servers can b

Re: [DISCUSS] Git commits and metadata

Thanks David. On Thu, Mar 27, 2025 at 9:50 AM David Arthur wrote: > Commented-by: left any comment on the PR (any contributor) > Reviewed-by: did a full review on the PR (any contributor) > Approved-by: committer(s) who approved the PR This matches my understanding and captures contributors' int

Re: KIP-1141: Simplifying MetadataQuorumCommand by Leveraging Admin API for Controller Management

Hi Chia, On Thu, Apr 3, 2025 at 10:24 AM Chia-Ping Tsai wrote: > We propose to use `Admin#describeConfigs` to get the configs for specific > controller if the bootstrap.controllers is configured. This approach is > similar to what `MetadataQuorumCommand` does, and the difference is > `Metadata

Re: KIP-1141: Simplifying MetadataQuorumCommand by Leveraging Admin API for Controller Management

Hi Kuan, I took a look at your KIP and thought about the problem and possible solutions. For the add-controller command, the active controller needs to know the new controller's id, directory id and endpoints for the default listener. As you mentioned in your KIP the user can provide the id using

Re: KIP-1141: Simplifying MetadataQuorumCommand by Leveraging Admin API for Controller Management

Hi Kuan, Thanks for your suggestion to improve the UX for adding and removing controllers. I skimmed the KIP and I have some feedback. I'll spend some time tomorrow to provide you with detailed feedback. Thanks! -- -José

Re: [DISCUSS] Git commits and metadata

Hi David, I like the motivation for this change but I have some suggestions. 1. To me the only required fields should be "reviewed-by" and "approved-by". I don't fully understand the rest of the fields. I would like to limit the burden on the committer to merge a change. 2. How about extending "a

Re: [DISCUSS] Apache Kafka 4.1.0 release

Thanks Mickael. On Wed, Mar 19, 2025 at 9:20 AM Ismael Juma wrote: > > Thanks Mickael! > > Ismael > > On Wed, Mar 19, 2025, 5:54 AM David Arthur wrote: > > > +1 thanks Mickael! > > > > David Arthur > > > > > > On Wed, Mar 19, 2025 at 07:59 Mickael Maison > > wrote: > > > > > Hi, > > > > > > I'd

Re: [ANNOUNCE] Apache Kafka 4.0.0

Awesome. Congratulations everyone for the important milestone and release!

Re: [VOTE] 4.0.0 RC3

Hi Luke and David, I merged my fix to the trunk and cherry-picked it to the 4.0 branch. It is not a full fix but it improves the UX so that kafka doesn't report the wrong kraft.version. The full fix is coming in 4.1 when I implement kraft upgrades in https://issues.apache.org/jira/browse/KAFKA-16

Re: [VOTE] 4.0.0 RC3

Hi Luke and David, On Thu, Mar 13, 2025 at 8:27 AM Luke Chen wrote: > > Hi David and all, > > Sorry, I found a bug KAFKA-18979, and in my opinion, it should be a blocker. > But I'd like to get @José Armando García Sancio 's confirmation. This is an unfortunate bug th

Re: [VOTE] 4.0.0 RC0

Hi Ismael, On Wed, Feb 26, 2025 at 7:51 AM Ismael Juma wrote: > > Hi Jose, > > Is it a low risk change? If not, I would suggest giving it a bit of > stabilization time before cherry-picking to older branches including 4.0 > and 3.9. I don't think it's necessary to backport to other older branches

Re: [VOTE] 4.0.0 RC0

Hi David and all, I am about to merge https://github.com/apache/kafka/pull/18852 to trunk: https://issues.apache.org/jira/browse/KAFKA-18723. I would like to cherry-pick it to 4.0.0. What do you think? I will also be cherry picking the change back to 3.7.x, 3.8.x and 3.9.x. If it is not included

Re: [DISCUSS] Apache Kafka 4.0.0 release

Hi David, Thanks again for being the release manager for 4.0.0. I have this bug that I would like to include in 4.0.0: https://issues.apache.org/jira/browse/KAFKA-18723. I explained in a comment that it is not a regression but it would be good to include the fix if it makes the RC. What do you t

[DISCUSS] What to do with jiras related to ZooKeeper code

Hi all, I am not sure if this was discussed before but what is our plan for jira (bugs) that are specific to the implementation of Kafka that is specific to the ZooKeeper implementation? It would be nice to easily identify all such jiras. Should we tag all such jiras with the zookeeper label? Sh

Re: [DISCUSS] Changing which commit we build in PRs

Thanks David. On Fri, Jan 17, 2025 at 11:55 AM David Arthur wrote: > > I have a simple patch which changes our PRs to build the HEAD of the PR > rather than the merge ref. > > https://github.com/apache/kafka/pull/18449 We shouldn't sacrifice correctness for performance. The tests need to run aga

Re: [DISCUSS] Apache Kafka 4.0.0 release

Hi David, Happy feature freeze day! See my comments below. On Wed, Dec 11, 2024 at 3:46 AM David Jacot wrote: > Thanks for reaching out to me about KIP-966. It seems to me that > https://github.com/ahuang98/kafka/pull/2 is a pretty large change for after > the feature freeze. How do you quantify

Re: New release branch 3.9

> the report here: https://issues.apache.org/jira/browse/KAFKA-17751 > Its current severity is "high", but IMO it might even be a blocker. What do > you think? > > Best, > > On Fri, Oct 4, 2024 at 5:18 PM José Armando García Sancio > wrote: > > > Thanks

Re: New release branch 3.9

Thanks Colin. KAFKA-16927 has been merged to trunk and the 3.9 branch. -- -José

Re: New release branch 3.9

Hi all, We found a bug that should be fixed for 3.9.0: https://issues.apache.org/jira/browse/KAFKA-16927 I have created a PR to fix this issue: https://github.com/apache/kafka/pull/17363 Colin, can we include this in 3.9.0? Thanks, -- -José

Re: New release branch 3.9

Hi Colin, We found a bug that we should fix for 3.9.0 (https://issues.apache.org/jira/browse/KAFKA-17608). Alyssa is going to work on the fix and we expect a PR soon. Thanks, -José

Re: [DISCUSS] Apache Kafka 4.0.0 release

+1, thanks for volunteering David! On Mon, Sep 23, 2024 at 11:56 AM David Arthur wrote: > > +1, thanks David! > > On Mon, Sep 23, 2024 at 11:48 AM Satish Duggana > wrote: > > > +1 > > Thanks David for volunteering! > > > > On Mon, 23 Sept 2024 at 19:27, Lianet M. wrote: > > > > > > +1 > > > > >

Re: [DISCUSS] - Kafka topic deletion improvement

Hi Muralidhar, > Proposal: > Prevent Topic Deletion if ACLs Exist: If there are read or write ACLs > associated with the topic, the deletion should be prohibited by default. > This helps prevent accidental deletion of topics that are still in use. For security it is recommended that ACLs are crea

Re: [DISCUSS] KIP-1090 Flaky Tests 👻

Thanks for the proposal David. Can modules opt out of this feature? For example, the raft module doesn't have any integration tests and all of the tests are meant to be deterministic. It would be dangerous to the protocol's correctness and the consistency of the cluster metadata to allow contribut

Re: [DISCUSS] KIP-1073 Return inactive observer nodes in DescribeQuorum response

thing like "fenced > > brokers will not be shown" in the case where it's talking to an old server. > > Or the tool could have a flag like --show-fenced which fails if it can't be > > done? > > > > best, > > Colin > > > > > > On

Re: New release branch 3.9

Hi Colin, I have a minor improvement to the rendering of our documentation that we should include in 3.9: https://github.com/apache/kafka/pull/17235 Thanks -Jose

Re: [DISCUSS] KIP-1073 Return inactive observer nodes in DescribeQuorum response

Thanks Gantigmaa. See comments below. The KIP LGTM after this. On Thu, Sep 12, 2024 at 4:50 AM Gantigmaa Selenge wrote: > Will this make it more confusing for combined nodes? Users might expect to > see both controller and broker under ROLES if it is a combined node. Since > we would be able to o

Re: [DISCUSS] KIP-1073 Return inactive observer nodes in DescribeQuorum response

Gantigmaa, thanks for the changes, they look good to me in general, I have some UX questions. The KIP mentions the following: > Also if there is no rack information for any of the nodes, the RACK column > will be omitted from the output. What will the tool output for nodes that don't have a rack

Re: [DISCUSS] KIP-1073 Return inactive observer nodes in DescribeQuorum response

Thanks for the KIP Gantigmaa, > { "name": "IncludeFencedBrokers", "type": "bool", "versions": "2+", "about": > "Whether to include fenced brokers." } Did you consider making "includeFencedBroker" field value implicitly based on the DescribeClusterRequest version and the EndpointType? For example

Re: [DISCUSS] KIP-1073 Return inactive observer nodes in DescribeQuorum response

Thanks for the KIP Gantigmaa! I agree with the motivation but it is not clear to me that this should be solved in the KRaft layer. The KRaft leader only keeps track, in-memory, of observers that have fetched. It is possible, after a kraft leader change, for this state to get lost. If the shutdown

Re: New release branch 3.9

On Wed, Jul 31, 2024 at 12:28 AM Ismael Juma wrote: > I would recommend against large refactorings in trunk until the first RC > for 3.9 - that will reduce cherry-pick friction. Once we have the first RC, > subsequent changes to 3.9 should be limited in scope. > I agree. We should specially dela

Re: New release branch 3.9

; > > > > > >> > > > -Matthias > > >> > > > > > >> > > > On 7/30/24 3:51 PM, Colin McCabe wrote: > > >> > > >> Hi Chia-Ping Tsai, > > >> > > >> > > >> > > &g

Re: New release branch 3.9

>> > > > > >>> > >> > > We have a lot of contributors waiting to pick-up 4.0 > tickets, > > and > > >>> I'll > > >>> > >> > > go ahead a tell them that we are ready and they can start to > > pick > > >>> them > > >>&

Re: New release branch 3.9

Thanks Colin. For KIP-853 (KRaft Controller Membership Changes), we still have the following features that are in progress. 1. UpdateVoter RPC and request handling 2. Storage tool changes for KIP-853

Re: [DISCUSS] KIP-1060: Expose advertised.listeners for KRaft controllers

being implemented! > > I raised a small PR <https://github.com/apache/kafka/pull/16473> to make > users aware that they can configure advertised.listeners for controllers. I > will also move the KIP to the discarded section. > > Regards, > Gantigmaa Selenge > On Mon, Jun 24,

Re: [DISCUSS] KIP-1060: Expose advertised.listeners for KRaft controllers

Hi Gantigmaa, I am implementing this as part of the KIP-853 implementation. I have a PR for this here: https://github.com/apache/kafka/pull/16235 Take a look at my KafkaConfig changes and related code. Thanks On Mon, Jun 24, 2024 at 8:04 AM Gantigmaa Selenge wrote: > > Hello > > I would like t

Re: [VOTE] KIP-1022 Formatting and Updating Features

; - There will be a new v4 for ApiVersionsRequest > > >> > > >> - Clients that sent v4 will promise to correctly handle ranges that > > start > > >> with 0, such as [0, 1] > > >> > > >> - The server will simply leave out the feature

Re: [DISCUSS] Apache Kafka 3.9.0 release

Would it be better to start a DISCUSS thread for 4.0 and keep this thread for 3.9 discussions? We seem to have agreement on 3.9. On Mon, Jun 17, 2024 at 4:29 PM José Armando García Sancio wrote: > > +1 for me. Thanks Colin for volunteering to be the release manager. > > On Mon, Jun 1

Re: [DISCUSS] Apache Kafka 3.9.0 release

+1 for me. Thanks Colin for volunteering to be the release manager. On Mon, Jun 17, 2024 at 4:15 PM Ismael Juma wrote: > > Hi all, > > I think we should actually look at the target dates vs just looking at the > release length. 3.9 is an August release. I suggest we aim for a November > release f

Re: [DISCUSS] Apache Kafka 3.8.0 release

n > > > >> > > the 3.9 > > > >> > > > > > > release. > > > >> > > > > > > > > > >> > > > > > > What are your thoughts? > > > >> > > > > &

Re: [DISCUSS] Apache Kafka 3.8.0 release

Hi Josep, See my comment below. On Wed, Jun 12, 2024 at 1:17 PM Josep Prat wrote: > How long do you think it will take to bring KIP-853 to completion? We are still missing a few issues/jiras that need to get implemented for the feature to be usable. I would say a few more weeks. May be early Ju

Re: [DISCUSS] Apache Kafka 3.8.0 release

Hi Josep, See my comments below. On Wed, May 29, 2024 at 10:52 AM Josep Prat wrote: > So I would propose to leave the deadlines as they are and manually cherry > pick the commits related to KIP-853 and KIP-966. Your proposal sounds good to me. I suspect that will be doing feature development fo

Re: [VOTE] KIP-909: DNS Resolution Fallures Should Not Fail the Client

25, 2023 at 8:52 PM Philip Nee wrote: > > > > > > > Thanks for the vote. We've decided to make a minor change to the > > default > > > > timeout from 5min to 2min. > > > > > > > > On Tue, Apr 25, 2023 at 11:42 AM David Jacot >

Re: [VOTE] KIP-853: KRaft Controller Membership Changes

Hi all, I am closing the voting. The KIP passed with: Jun Rao +1 binding Jason Gustafson +1 binding José Armando García Sancio +1 binding Thank you all, On Mon, Apr 22, 2024 at 11:57 AM José Armando García Sancio wrote: > > I am going to close the vote tomorrow morning (PST). > >

Re: [VOTE] KIP-853: KRaft Controller Membership Changes

I am going to close the vote tomorrow morning (PST). On Mon, Apr 22, 2024 at 10:06 AM José Armando García Sancio wrote: > > +1 binding. > > On Mon, Apr 22, 2024 at 9:28 AM Jason Gustafson > wrote: > > > > Thanks Jose. +1. Great KIP! > > > > On Fri,

Re: [VOTE] KIP-853: KRaft Controller Membership Changes

+1 binding. On Mon, Apr 22, 2024 at 9:28 AM Jason Gustafson wrote: > > Thanks Jose. +1. Great KIP! > > On Fri, Mar 29, 2024 at 11:16 AM Jun Rao wrote: > > > Hi, Jose, > > > > Thanks for the KIP. +1 > > > > Jun > > > > On Fri, Mar

Re: [VOTE] KIP-1022 Formatting and Updating Features

Hi Justine, +1 (binding) Thanks for the improvement. -- -José

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

Hi Justine, On Tue, Apr 9, 2024 at 4:19 PM Justine Olshan wrote: > As for the validation criteria. It seems like one bit of code that > validates whether a version is allowed is in the method > `reasonNotSupported` which checks the range of features available for the > given feature. > For metada

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

Hi Justine, Thanks for the KIP. I see that the KIP doesn't make any updates to the UpdateFeatures RPC. I was trying to understand how errors will be communicated to the client. Are you planning to use the INVALID_UPDATE_VERSION error and overwrite the ErrorMessage field for all of the validations

Re: [DISCUSS] KIP-1022 Formatting and Updating Features

Hi Justine, See my comments below. On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan wrote: > 20. I can update the KIP. I took a look at the latest KIP. * Should the output of this command "bin/kafka-features.sh version-mapping --release-version 3.6-IV1" be something like this: metadata.version=13

[VOTE] KIP-853: KRaft Controller Membership Changes

Hi all, I would like to call a vote to adopt KIP-853. KIP: https://cwiki.apache.org/confluence/x/nyH1D Discussion thread: https://lists.apache.org/thread/6o3sjvcb8dx1ozqfpltb7p0w76b4nd46 Thanks, -- -José

Re: [DISCUSS] KIP-853: KRaft Controller Membership Changes

Jun, thanks a lot for your help. I feel that the KIP is much better after your detailed input. If there is no more feedback, I'll start a voting thread tomorrow morning. I'll monitor KIP-1022's discussion thread and update this KIP with anything that affects the KIP's specification. Thanks, -- -

Re: [DISCUSS] KIP-853: KRaft Controller Membership Changes

Hi Jun, See my comments below. On Thu, Mar 28, 2024 at 11:09 AM Jun Rao wrote: > If I am adding a new voter and it takes a long time (because the new voter > is catching up), I'd want to know if the request is indeed being processed. > I thought that's the usage of uncommitted-voter-change. The

  1   2   3   >