Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

[Matthias J. Sax]

Thanks for the KIP! Great to see a first step towards using the new 
versioned stores!


I think the described tradeoffs make sense and I like make a pragmatic 
step into the right direction, and avoid boiling the ocean. Thus, I 
agree to the proposed solution.


One minor thing, that I believe just need clarification in the KIP (does 
not seem to be a change to the KIP itself):


For stream-table joins, I think we need to elaborate that a `get(k, ts)` 
call now might return `null` if the history retention of the store is 
too short. For inner-joins it would result in no output record (ie, 
stream input record is dropped). Would be good to have it mentioned in 
the KIP explicitly.


We should also discuss how left-joins should work for this case. I think 
it's ok (better) to include the stream record in the result if the 
lookup returns `null` -- either because no key exist in the exiting 
history for the provided timestamp, or (the actual case in question) 
because we query older than available history. If you agree, can we add 
this to the KIP?


For left-table-table joins, there seems to be no special impact, but it 
should be called out, too. The lookup itself does not go into the 
history of the table so no change here (as we don't have the "query 
older than history case") -- and for out-of-order records, we just 
"drop" them anyway, so no change for left-joins either I believe.



-Matthias



On 3/15/23 2:00 PM, Guozhang Wang wrote:

Sounds good to me. Thanks!

On Wed, Mar 15, 2023 at 12:07 PM Victoria Xia
 wrote:


Thanks for kicking off the discussion, John and Guozhang!


Just one thing that might be out of scope: if users want to enable the

versioned table feature across the topology, should we allow them to do it
via a single config rather than changing the materialized object at each
place?

Yes, I think this would be a great usability improvement and am in favor of
introducing such a config. As long as the config defaults to using
unversioned stores (which makes sense anyway), there will be no
compatibility concerns with introducing the config in a future release.
It's out of scope for this particular KIP as a result, but can hopefully be
introduced as part of the next release after 3.5.

Best,
Victoria

On Wed, Mar 15, 2023 at 10:49 AM Guozhang Wang 
wrote:


Thanks Victoria for the great writeup, with a thorough analysis and
trade-offs. I do not have any major questions about the proposal.

Just one thing that might be out of scope: if users want to enable the
versioned table feature across the topology, should we allow them to
do it via a single config rather than changing the materialized object
at each place? Maybe we can defer that for future discussions, but
just want to hear your thoughts.

Anyways, I think this proposal is great just as-is even if we agree to
do the configuration improvement later.


Guozhang

On Thu, Mar 9, 2023 at 7:52 PM John Roesler  wrote:


Thanks for the KIP, Victoria!

I had some questions/concerns, but you addressed them in the Rejected

Alternatives section. Thanks for the thorough proposal!


-John

On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote:

Hi everyone,

I have a proposal for updating Kafka Streams's stream-table join and
table-table join semantics for the new versioned key-value state stores
introduced in KIP-889
<

https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores

.

Would love to hear your thoughts and suggestions.



https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores


Thanks,
Victoria

Re: [DISCUSS] KIP-912: Support decreasing send's block time without worrying about metadata's fetch

[jian fu]

anyone give some comments? 😂 thanks

jian fu  于2023年3月9日周四 10:12写道：

> Hi All:
>
> If anyone can help to give some comments or suggestions for the proposal.
> Thanks in advance!
>
> Regards
> Jian
>
> jian fu  于2023年3月6日周一 15:55写道：
>
>> Hi Everyone:
>> Nice to meet you.
>>
>> I created one KIP to request your review.
>> KIP-912: Support decreasing send's block time without worrying about
>> metadata's fetch
>> 
>> The example PR:
>> https://github.com/apache/kafka/pull/13335/files
>>
>> Thanks.
>>
>> --
>> Regards
>> Jian
>>
>>
>>
>
> --
> Regards  Fu.Jian
> --
> Cisco Communications, Inc.
>
>

-- 
Regards  Fu.Jian
--
Cisco Communications, Inc.

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

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-13884) KRaft Obsever are not required to flush on every append

[Jira]

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

José Armando García Sancio resolved KAFKA-13884.

Fix Version/s: 3.5.0
   Resolution: Fixed

> KRaft Obsever are not required to flush on every append
> ---
>
> Key: KAFKA-13884
> URL: https://issues.apache.org/jira/browse/KAFKA-13884
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Jose Armando Garcia Sancio
>Assignee: José Armando García Sancio
>Priority: Major
> Fix For: 3.5.0
>
>
> The current implementation of the KRaft Client flushes to disk when observers 
> append to the log. This is not required since observer don't participate in 
> leader election and the advancement of the high-watermark.



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

[DISCUSS] KIP-915: Next Gen Group Coordinator Downgrade Path

[Jeff Kim]

Hi folks,

I would like to start a discussion thread for KIP-915: Next Gen Group
Coordinator Downgrade Path which proposes the downgrade design for the new
group coordinator introduced in KIP-848

.

KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-915%3A+Next+Gen+Group+Coordinator+Downgrade+Path

Thanks,
Jeff

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

[Guozhang Wang]

Sounds good to me. Thanks!

On Wed, Mar 15, 2023 at 12:07 PM Victoria Xia
 wrote:
>
> Thanks for kicking off the discussion, John and Guozhang!
>
> > Just one thing that might be out of scope: if users want to enable the
> versioned table feature across the topology, should we allow them to do it
> via a single config rather than changing the materialized object at each
> place?
>
> Yes, I think this would be a great usability improvement and am in favor of
> introducing such a config. As long as the config defaults to using
> unversioned stores (which makes sense anyway), there will be no
> compatibility concerns with introducing the config in a future release.
> It's out of scope for this particular KIP as a result, but can hopefully be
> introduced as part of the next release after 3.5.
>
> Best,
> Victoria
>
> On Wed, Mar 15, 2023 at 10:49 AM Guozhang Wang 
> wrote:
>
> > Thanks Victoria for the great writeup, with a thorough analysis and
> > trade-offs. I do not have any major questions about the proposal.
> >
> > Just one thing that might be out of scope: if users want to enable the
> > versioned table feature across the topology, should we allow them to
> > do it via a single config rather than changing the materialized object
> > at each place? Maybe we can defer that for future discussions, but
> > just want to hear your thoughts.
> >
> > Anyways, I think this proposal is great just as-is even if we agree to
> > do the configuration improvement later.
> >
> >
> > Guozhang
> >
> > On Thu, Mar 9, 2023 at 7:52 PM John Roesler  wrote:
> > >
> > > Thanks for the KIP, Victoria!
> > >
> > > I had some questions/concerns, but you addressed them in the Rejected
> > Alternatives section. Thanks for the thorough proposal!
> > >
> > > -John
> > >
> > > On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote:
> > > > Hi everyone,
> > > >
> > > > I have a proposal for updating Kafka Streams's stream-table join and
> > > > table-table join semantics for the new versioned key-value state stores
> > > > introduced in KIP-889
> > > > <
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores
> > >.
> > > > Would love to hear your thoughts and suggestions.
> > > >
> > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores
> > > >
> > > > Thanks,
> > > > Victoria
> >

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

[Victoria Xia]

Thanks for kicking off the discussion, John and Guozhang!

> Just one thing that might be out of scope: if users want to enable the
versioned table feature across the topology, should we allow them to do it
via a single config rather than changing the materialized object at each
place?

Yes, I think this would be a great usability improvement and am in favor of
introducing such a config. As long as the config defaults to using
unversioned stores (which makes sense anyway), there will be no
compatibility concerns with introducing the config in a future release.
It's out of scope for this particular KIP as a result, but can hopefully be
introduced as part of the next release after 3.5.

Best,
Victoria

On Wed, Mar 15, 2023 at 10:49 AM Guozhang Wang 
wrote:

> Thanks Victoria for the great writeup, with a thorough analysis and
> trade-offs. I do not have any major questions about the proposal.
>
> Just one thing that might be out of scope: if users want to enable the
> versioned table feature across the topology, should we allow them to
> do it via a single config rather than changing the materialized object
> at each place? Maybe we can defer that for future discussions, but
> just want to hear your thoughts.
>
> Anyways, I think this proposal is great just as-is even if we agree to
> do the configuration improvement later.
>
>
> Guozhang
>
> On Thu, Mar 9, 2023 at 7:52 PM John Roesler  wrote:
> >
> > Thanks for the KIP, Victoria!
> >
> > I had some questions/concerns, but you addressed them in the Rejected
> Alternatives section. Thanks for the thorough proposal!
> >
> > -John
> >
> > On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote:
> > > Hi everyone,
> > >
> > > I have a proposal for updating Kafka Streams's stream-table join and
> > > table-table join semantics for the new versioned key-value state stores
> > > introduced in KIP-889
> > > <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores
> >.
> > > Would love to hear your thoughts and suggestions.
> > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores
> > >
> > > Thanks,
> > > Victoria
>

Re: [DISCUSSION] MirrorMaker2 offset translation for compacted, filtered, and transactional source topics

[Greg Harris]

Luke,

Thanks for leaving your thoughts.

I agree that this does not directly change an API, and doesn't fall within
the typical KIP guidelines. These proposals would change the behavior of
translation within the bounds of the current API, and I wasn't sure whether
this fell under the KIP process.
I was also concerned that the potential solutions to KAFKA-14666 were
complex enough that we needed a formal discussion and approval process. I'm
happy to pursue this further in a non-KIP discussion thread until someone
suggests escalating.

Thanks!
Greg

On Wed, Mar 15, 2023 at 3:47 AM Luke Chen  wrote:

> Hi Greg,
>
> Thanks for your summary.
> I'm not very familiar with MM2, actually, but I'd like to give my answer to
> some of the questions below:
>
> Q1. Would an improvement to allow translation from earlier in the topic be
> reasonable to propose in a KIP?
> --> I checked the proposed 5 solutions in KAFKA-14666, I think all of them
> are trying to fix a bug, not changing any public API.
> So, IMO, no KIP is needed.
>
> Q2. Is anyone relying on the current poor correctness and high availability
> translation, such that making the availability worse is a
> backwards-incompatible regression?
> Q3. Should we prioritize correctness, even if it hurts availability?
> --> This is obviously hard to choose. But I hope we can have a way to have
> both of them.
>
> Q4. Should we address correctness and availability of this feature in a
> patch or only minor releases?
> --> If it's a bug fix, patch or a new release can be included.
>
> Q5. Is there some tactical improvement to availability we can make which
> does not count as backwards-incompatible, allowing us to land the
> correctness fix without a KIP?
> --> Again, if it's a bug fix or an improvement without affecting public
> API, I don't think a KIP is needed.
>
>
> Q6. Do you have any suggestions on how to improve availability of offset
> translation?
>
>
>
> Thank you.
> Luke
>
> On Wed, Mar 15, 2023 at 4:39 AM Greg Harris 
> wrote:
>
> > Hey all!
> >
> > I realized that the information above is a bit in-the-weeds, and I think
> a
> > re-framing of the situation might be necessary.
> >
> > Since the release of MM2, offsets translation has been limited to only
> > performing translation ahead of the most recent offset sync. This
> > limitation appears to have worked for existing use-cases where offset
> syncs
> > are infrequent.
> > For topics which emit offset syncs frequently, the window for offset
> > translation becomes shorter, and may become unusable. In those unusable
> > cases, offset translation may stop completely for an otherwise
> > fully-functional steady-state MM2 instance.
> > Recently, we have been interested in improving the correctness of offset
> > translation to address data loss, and those fixes end up causing more
> > offset syncs to be emitted, making the translation window smaller than
> > before, and often unusable.
> >
> > Q1. Would an improvement to allow translation from earlier in the topic
> be
> > reasonable to propose in a KIP?
> > Q2. Is anyone relying on the current poor correctness and high
> availability
> > translation, such that making the availability worse is a
> > backwards-incompatible regression?
> > Q3. Should we prioritize correctness, even if it hurts availability?
> > Q4. Should we address correctness and availability of this feature in a
> > patch or only minor releases?
> > Q5. Is there some tactical improvement to availability we can make which
> > does not count as backwards-incompatible, allowing us to land the
> > correctness fix without a KIP?
> > Q6. Do you have any suggestions on how to improve availability of offset
> > translation?
> >
> > I'm interested in finding a tactical solution that we can backport, and a
> > holistic solution for more future use-cases.
> > I hope that the above is more clear.
> >
> > Thanks!
> > Greg
> >
> > On Fri, Mar 10, 2023 at 12:16 PM Greg Harris 
> wrote:
> >
> > > Hi all,
> > >
> > > Recently, we've been experimenting with using MM2 to mirror topics that
> > > were populated by transactional producers. We've noticed that MM2
> > > replicates records but not transaction markers, causing certain offsets
> > to
> > > appear in the source topic but not destination topic. These behaviors
> can
> > > also be seen when using Filter SMTs, or when replicating topics which
> > have
> > > undergone compaction, which cause the same concentration of offsets in
> > the
> > > target topic.
> > >
> > > This has the following negative effects with offset translation:
> > > P1. When starting replication on an existing topic with existing
> consumer
> > > groups, offsets are translated beyond the end of the topic, leading to
> > > "negative lag" for the downstream consumer group
> > > P2. When in a "negative lag" situation, and a consumer fail-over from
> > > source to is triggered, downstream consumption will stall until the
> > > downstream offsets exceed the "negative lag" offsets.
> > > P

Re: [DISCUSS] KIP-914 Join Processor Semantics for Versioned Stores

[Guozhang Wang]

Thanks Victoria for the great writeup, with a thorough analysis and
trade-offs. I do not have any major questions about the proposal.

Just one thing that might be out of scope: if users want to enable the
versioned table feature across the topology, should we allow them to
do it via a single config rather than changing the materialized object
at each place? Maybe we can defer that for future discussions, but
just want to hear your thoughts.

Anyways, I think this proposal is great just as-is even if we agree to
do the configuration improvement later.


Guozhang

On Thu, Mar 9, 2023 at 7:52 PM John Roesler  wrote:
>
> Thanks for the KIP, Victoria!
>
> I had some questions/concerns, but you addressed them in the Rejected 
> Alternatives section. Thanks for the thorough proposal!
>
> -John
>
> On Thu, Mar 9, 2023, at 18:59, Victoria Xia wrote:
> > Hi everyone,
> >
> > I have a proposal for updating Kafka Streams's stream-table join and
> > table-table join semantics for the new versioned key-value state stores
> > introduced in KIP-889
> > .
> > Would love to hear your thoughts and suggestions.
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-914%3A+Join+Processor+Semantics+for+Versioned+Stores
> >
> > Thanks,
> > Victoria

[jira] [Created] (KAFKA-14811) The forwarding requests are discarded when network client is changed to/from zk/Kraft

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-14811:
--

 Summary: The forwarding requests are discarded when network client 
is changed to/from zk/Kraft
 Key: KAFKA-14811
 URL: https://issues.apache.org/jira/browse/KAFKA-14811
 Project: Kafka
  Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai


We don't check the in-flight requests when closing stale network client. If the 
in-flight requests are related to metadata request from client, the client will 
get timeout exception. If the in-flight requests are related to ISR/leader, the 
partition can't be written as it can't meet mini ISR.



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

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-866 ZooKeeper to KRaft Migration

[David Arthur]

Hey folks, I just wanted to update this thread with some minor changes I've
made to the KIP based on the implementation in 3.4.

* No new ApiVersionsResponse, we use the "metadata.version" feature flag
instead
* Pre-Migration instead of "Soft Start" for the phase of the controller
before it can accept metadata changes
* Add "kraftControllerEpoch" to /controller ZNode instead just the
"isKRaft" boolean
* Rename ZkMigrationRecord to ZkMigrationStateRecord
* In RegisterBrokerRecord, rename "IsZkBroker" to "IsMigratingZkBroker"
* In BrokerRegistrationRequest, rename "ZkMigrationReady" to
"IsMigratingZkBroker"
(no longer a tagged field)
* In the controller RPCs, use "isKraftController" boolean field instead of
"KRaftControllerId"


All of these changes were made prior to the release, so there's no
compatibility issues. I just wanted to update the KIP to make it reflect
reality.


Cheers,

David

On Tue, Nov 29, 2022 at 10:14 PM Luke Chen  wrote:

> Thanks for the reply.
> Yes, I think adding a section in Rejected Alternatives to explain the
> rationale why we don't support combined mode upgrade in this KIP is
> helpful.
>
> Thank you.
> Luke
>
> On Wed, Nov 30, 2022 at 8:47 AM Jun Rao  wrote:
>
> > Hi, David,
> >
> > Thanks for the reply. No other comments from me.
> >
> > Jun
> >
> > On Tue, Nov 29, 2022 at 2:57 PM David Arthur
> >  wrote:
> >
> > > Jun,
> > >
> > > 51. You're right, I missed that in the latest update. It's fixed now.
> > >
> > > 54. I was thinking we could update meta.properties to v1 as the brokers
> > > were being restarted in KRaft mode without the migration config set.
> > > However, as you mentioned, it is still possible to downgrade even then
> > (as
> > > long as the controller has not exited dual-write mode). Upgrading the
> > > meta.properties after seeing the final ZkMigrationRecord sounds like a
> > good
> > > idea to me. I've updated the KIP to include this detail under
> > > "Meta.Properties" section.
> > >
> > > 58. Yes, the metadata migration from ZK to KRaft will not migrate the
> > > contents of /brokers.
> > >
> > > Thanks,
> > > David
> > >
> > > On Tue, Nov 29, 2022 at 4:50 PM Jun Rao 
> > wrote:
> > >
> > > > Hi, David,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > 51. Is this reflected in the KIP? It seems that ZkMigrationState
> still
> > > has
> > > > the None value.
> > > >
> > > > 54. Supporting both v0 and v1 indefinitely in a KRaft broker could
> be a
> > > bit
> > > > confusing and may complicate future upgrades. Another approach is to
> > let
> > > > KRaft broker write the v1 meta.properties after the KRaft controller
> > > exits
> > > > the dual write mode. We could extend ZkMigrationRecord to 3 states
> like
> > > > migration, dualWrite and KRaftOnly. Once a broker sees KRaftOnly, it
> > will
> > > > write meta.properties in v1 format. At that point, downgrade could
> > cause
> > > > metadata loss and require manual work. Will that work?
> > > >
> > > > 58. When copying metadata from ZK to KRaft, I guess we will ignore
> > broker
> > > > registration since the KRaft controller has already generated a
> > > > BrokerRegistrationRecord based on BrokerRegistrationRequest?
> > > >
> > > > Thanks,
> > > >
> > > > Jun
> > > >
> > > > On Tue, Nov 29, 2022 at 7:14 AM David Arthur
> > > >  wrote:
> > > >
> > > > > Jun, Thanks for the comments. Igor, please see 54 below for some
> > > > additional
> > > > > discussion on the meta.properties
> > > > >
> > > > > 50.1 Yes, that field name sounds fine to me.
> > > > >
> > > > > 50.2 Ok, I'll add something to the KIP under the Controller
> section.
> > To
> > > > > your other question, NoOpRecords are used as part of our liveness
> > check
> > > > for
> > > > > the quorum. It doesn't produce any metadata really, so I don't
> think
> > it
> > > > > causes any harm to let it happen before the migration.  KIP-835 has
> > the
> > > > > details on the NoOpRecords
> > > > >
> > > > > 54. Colin and I discussed the meta.properties issue last night. How
> > > about
> > > > > we simply let the KRaft broker accept v0 or v1 meta.properties. At
> > this
> > > > > point, the two versions have the same contents, but different field
> > > > names.
> > > > > By leaving the meta.properties intact, we can simplify the
> downgrade
> > > > > process. If we care to, we could rewrite meta.properties once a
> > broker
> > > is
> > > > > restarted after the migration is finalized (migration config
> > disabled).
> > > > >
> > > > > 57. If a ZK broker can't send a BrokerRegistrationRequest because
> the
> > > > > quorum is unavailable, it should just continue operating normally.
> > > Once a
> > > > > leader is available, the broker will send the registration and
> start
> > > > > heart-beating. Unlike KRaft mode, we won't block startup on a
> > > successful
> > > > > BrokerRegistration response. Concretely, BrokerLifecycleManager
> will
> > > keep
> > > > > trying to contact the quorum in its own thread until the
> > > > > BrokerToChannelManag

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

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-902: Upgrade Zookeeper to 3.8.1

[Christo Lolov]

Hello Colin,

Thank you for taking the time to review the proposal!

I have attached a compatibility matrix to aid the explanation below - if
the mailing system rejects it I will find another way to share it.

For the avoidance of doubt, I am not proposing to drop support for rolling
upgrade from old Kafka versions to new ones. What I am saying is that
additional care will need to be taken when upgrading to the latest Kafka
versions depending on the version of the accompanying Zookeeper cluster.
This additional care means one might have to upgrade to a Kafka version
which falls in the intersection of the two sets in the accompanying diagram
before upgrading the accompanying Zookeeper cluster.

As a concrete example let's say you want to upgrade to Kafka 3.5 from Kafka
2.3 and Zookeeper 3.4. You will have to:
1. Carry out a rolling upgrade of your Kafka cluster to a version between
2.4 and 3.4.
2. Carry out a rolling upgrade of your Zookeeper cluster to 3.8.1 (with a
possible stop at 3.4.6 due to
https://zookeeper.apache.org/doc/r3.8.1/zookeeperReconfig.html#ch_reconfig_upgrade
).
3. Carry out a rolling upgrade of your Kafka cluster from 3.4 to 3.5.

It is true that Zookeeper is to be deprecated in Kafka 4.0, but as far as I
looked there is no concrete release date for that version yet. Until this
is the case and unless we carry out a Zookeeper version upgrade we leave
users to run on an end-of-life version with unpatched CVEs addressed in
later versions. Some users have compliance requirements to only run on
stable versions of a software and its dependencies and not keeping the
dependencies up to date renders them unable to use Kafka.

Please, let me know your thoughts on the matter!

Best,
Christo

On Thu, 9 Mar 2023 at 21:56, Colin McCabe  wrote:

> Hi,
>
> I'm struggling a bit with this KIP, because dropping support for rolling
> upgrades from old Kafka versions doesn't seem like something we should do
> in a minor release. But on the other hand, the next Kafka release won't
> have ZK at all. Maybe we should punt on this until and unless there is a
> security issue that requires some action from us.
>
> I would also add, that a major ZK version bump is pretty risky. Last time
> we did this we hit several bugs. I remember we hit one where there was an
> incompatible change with regard to formatting (sorry, I can't seem to find
> the JIRA right now).
>
> Sorry, but for now I have to vote -1 until I can understand this better
>
> best,
> Colin
>
>
> On Thu, Feb 23, 2023, at 06:48, Divij Vaidya wrote:
> > Thanks for the KIP Christo.
> >
> > Having Zk 3.6 reach EOL in Dec 2022 is a good enough reason to upgrade,
> > hence I completely agree with the motivation. Your experiments have
> > demonstrated that the new version of Zk is stable at scale and the
> backward
> > compatibility risks are acceptable since Apache Kafka 2.4.x is an EOL
> > version.
> >
> > Vote +1 (non binding)
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Thu, Feb 23, 2023 at 3:32 PM Christo Lolov 
> > wrote:
> >
> >> Hello!
> >>
> >> I would like to start the vote for KIP-902, which upgrades Zookeeper to
> >> version 3.8.1.
> >>
> >> The KIP can be found at
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=240882784
> >>
> >> The discussion thread is
> >> https://lists.apache.org/thread/5jbn2x0rtmqz5scyoygbdbj4vo0mpbw1
> >>
> >> Thanks
> >> Christo
>

[VOTE] KIP-911: Add source tag to MirrorSourceConnector metrics

[Mickael Maison]

Hi,

I'd like to start the vote on KIP-911 to add the source cluster alias
as a tag on the MirrorSourceConnector metrics:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-911%3A+Add+source+tag+to+MirrorSourceConnector+metrics

Thanks,
Mickael

Re: [DISCUSSION] MirrorMaker2 offset translation for compacted, filtered, and transactional source topics

[Luke Chen]

Hi Greg,

Thanks for your summary.
I'm not very familiar with MM2, actually, but I'd like to give my answer to
some of the questions below:

Q1. Would an improvement to allow translation from earlier in the topic be
reasonable to propose in a KIP?
--> I checked the proposed 5 solutions in KAFKA-14666, I think all of them
are trying to fix a bug, not changing any public API.
So, IMO, no KIP is needed.

Q2. Is anyone relying on the current poor correctness and high availability
translation, such that making the availability worse is a
backwards-incompatible regression?
Q3. Should we prioritize correctness, even if it hurts availability?
--> This is obviously hard to choose. But I hope we can have a way to have
both of them.

Q4. Should we address correctness and availability of this feature in a
patch or only minor releases?
--> If it's a bug fix, patch or a new release can be included.

Q5. Is there some tactical improvement to availability we can make which
does not count as backwards-incompatible, allowing us to land the
correctness fix without a KIP?
--> Again, if it's a bug fix or an improvement without affecting public
API, I don't think a KIP is needed.


Q6. Do you have any suggestions on how to improve availability of offset
translation?



Thank you.
Luke

On Wed, Mar 15, 2023 at 4:39 AM Greg Harris 
wrote:

> Hey all!
>
> I realized that the information above is a bit in-the-weeds, and I think a
> re-framing of the situation might be necessary.
>
> Since the release of MM2, offsets translation has been limited to only
> performing translation ahead of the most recent offset sync. This
> limitation appears to have worked for existing use-cases where offset syncs
> are infrequent.
> For topics which emit offset syncs frequently, the window for offset
> translation becomes shorter, and may become unusable. In those unusable
> cases, offset translation may stop completely for an otherwise
> fully-functional steady-state MM2 instance.
> Recently, we have been interested in improving the correctness of offset
> translation to address data loss, and those fixes end up causing more
> offset syncs to be emitted, making the translation window smaller than
> before, and often unusable.
>
> Q1. Would an improvement to allow translation from earlier in the topic be
> reasonable to propose in a KIP?
> Q2. Is anyone relying on the current poor correctness and high availability
> translation, such that making the availability worse is a
> backwards-incompatible regression?
> Q3. Should we prioritize correctness, even if it hurts availability?
> Q4. Should we address correctness and availability of this feature in a
> patch or only minor releases?
> Q5. Is there some tactical improvement to availability we can make which
> does not count as backwards-incompatible, allowing us to land the
> correctness fix without a KIP?
> Q6. Do you have any suggestions on how to improve availability of offset
> translation?
>
> I'm interested in finding a tactical solution that we can backport, and a
> holistic solution for more future use-cases.
> I hope that the above is more clear.
>
> Thanks!
> Greg
>
> On Fri, Mar 10, 2023 at 12:16 PM Greg Harris  wrote:
>
> > Hi all,
> >
> > Recently, we've been experimenting with using MM2 to mirror topics that
> > were populated by transactional producers. We've noticed that MM2
> > replicates records but not transaction markers, causing certain offsets
> to
> > appear in the source topic but not destination topic. These behaviors can
> > also be seen when using Filter SMTs, or when replicating topics which
> have
> > undergone compaction, which cause the same concentration of offsets in
> the
> > target topic.
> >
> > This has the following negative effects with offset translation:
> > P1. When starting replication on an existing topic with existing consumer
> > groups, offsets are translated beyond the end of the topic, leading to
> > "negative lag" for the downstream consumer group
> > P2. When in a "negative lag" situation, and a consumer fail-over from
> > source to is triggered, downstream consumption will stall until the
> > downstream offsets exceed the "negative lag" offsets.
> > P3. When failing over from source to target, certain records may have
> been
> > ahead of the upstream consumer group and behind the downstream consumer
> > group, leading to records not being delivered at least once.
> >
> > We merged a solution the above by making a change to the translation
> logic
> > in https://issues.apache.org/jira/browse/KAFKA-12468 , and settled on a
> > strategy to make offset translation more conservative, effectively making
> > it such that the MirrorCheckpointTask only emits offsets at or
> immediately
> > after the latest offset sync. This has the effect that offsets are more
> > correct than previously, but that did not come without costs:
> >
> > P4. More offset syncs must be emitted to the offset syncs topic to
> enforce
> > the `offset.lag.max` config property, once per

Re: [VOTE] KIP-906 Tools migration guidelines

[Alexandre Dupriez]

Hi, Frederico,

Thanks for the KIP.

Non-binding +1.

Thanks,
Alexandre

Le mer. 15 mars 2023 à 08:28, Luke Chen  a écrit :
>
> +1 from me.
>
> Luke
>
> On Wed, Mar 15, 2023 at 4:11 PM Federico Valeri 
> wrote:
>
> > Hi everyone,
> >
> > I'd like to start the vote on KIP-906 Tools migration guidelines.
> >
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
> >
> > Discussion thread:
> > https://lists.apache.org/thread/o2ytmjj2tyc2xcy6xh5tco31yyjzvz8p
> >
> > Thanks
> > Fede
> >

Re: [VOTE] KIP-906 Tools migration guidelines

[Luke Chen]

+1 from me.

Luke

On Wed, Mar 15, 2023 at 4:11 PM Federico Valeri 
wrote:

> Hi everyone,
>
> I'd like to start the vote on KIP-906 Tools migration guidelines.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines
>
> Discussion thread:
> https://lists.apache.org/thread/o2ytmjj2tyc2xcy6xh5tco31yyjzvz8p
>
> Thanks
> Fede
>

Re: [DISCUSS] KIP-641 An new java interface to replace 'kafka.common.MessageReader'

[Chia-Ping Tsai]

Hi  lsmael

I will update the KIP to replace “ org.apache.kafka.clients.tool” by “ 
org.apache.kafka.tools” due to following reasons.

1) it is more consistent with existent server/clients pluggable interface 
package

2) kafka tool jar is not expected to be imported to write code for pluggable 
interfaces.

3) no new module is introduced. The client module already has pluggable 
interface of tool, and thus putting them together can make users write other 
plugins with single (client) jar

—
Chia-Ping


> Ismael Juma  於 2023年3月15日 上午3:06 寫道：
> 
> Hi Chia,
> 
> Regarding `org.apache.kafka.clients.tool`, a few comments:
> 
> 1. Why is it in `clients`? We don't generally consider tools to be a client.
> 2. Why is it `tool`? We have a package `org.apache.kafka.tools`, so it's a
> bit odd that this one uses singular instead of plural.
> 3. Also, should we follow the `storage-api` example and have a module for
> all extensible interfaces used by tools?
> 
> Ismael
> 
>> On Tue, Mar 14, 2023 at 9:23 AM Chia-Ping Tsai  wrote:
>> 
>> 
>> 
 Chris Egerton  於 2023年3月15日 上午12:04 寫道：
>>> 
>>> Hi Chia-Ping,
>>> 
>>> Thanks for the KIP. I find the interface definition really polished and
>>> intuitive! One small question--I noticed the change of the package to
>>> "org.apache.kafka.clients.tool". It doesn't look like there's any
>> precedent
>>> for using that package. We also use the "org.apache.kafka.common" package
>>> for the "MessageFormatter" interface, which is in some ways the
>> equivalent
>>> pluggable interface for the console consumer.
>> 
>> It seems to me those pluggable interfaces (MessageFormatter and
>> RecordReader) should not be a part of “common” package. They are used by
>> specify tools only. `Configurable`, by contrast, is good to be located at
>> `common` package since it is used widely in our code base.
>> 
>> 
>>> 
>>> Do we know if it's necessary to preserve the Checkstyle import
>> limitations
>>> (which I'm assuming are what motivated the shift in package name)? It
>> seems
>>> like it might be better to just relax that constraint in order to
>> colocate
>>> the pluggable interfaces for our console producer/consumer.
>> 
>> I love checkstyle import, and that is one of reason the KIP isolates the
>> new interface to a separate package. We have to add `allowed rule` one by
>> one if those dedicated interfaces are using the `common` package. The
>> constraint of new package can be relax to colocate the pluggable interfaces
>> (used by tools), and the `relax` won’t impact other existent packages.
>> 
>> 
>>> 
>>> Cheers,
>>> 
>>> Chris
>>> 
>>> On Tue, Mar 7, 2023 at 6:30 AM Chia-Ping Tsai 
>> wrote:
>>> 
 hi Mickael
 
> ?> configs) in the Compatibility, Deprecation, and Migration Plan, I
> guess these can be removed now.
 
 Done! thanks for feedback
 
> Mickael Maison  於 2023年3月7日 下午7:13 寫道：
> 
> Hi Chia-Ping,
> 
> The new API looks good.
> I still see mentions to configure(InputStream inputStream, Map ?> configs) in the Compatibility, Deprecation, and Migration Plan, I
> guess these can be removed now.
> 
> Thanks,
> Mickael
> 
> On Fri, Mar 3, 2023 at 2:37 PM Chia-Ping Tsai 
 wrote:
>> 
>> Dear all,
>> 
>> there are some changes for KIP-614
>> 
>> 
 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866569
>> 
>> 1) the interface RecordReader extends Configurable.
>> 2) the input stream is removed from RecordReader#configure method
>> 3) RecordReader#readRecords accept InputStream as argument, and the
 returned type is changed from single ProducerRecord to
 Iterator
>> 
>> Please take a look and then start to vote if you have free time.
>> thanks.
>> 
>> vote:
>> https://lists.apache.org/thread/kjdtyfg5xytn60q0qvxhfopzmfp9tsxr
 
 
>> 
>> 

[VOTE] KIP-906 Tools migration guidelines

[Federico Valeri]

Hi everyone,

I'd like to start the vote on KIP-906 Tools migration guidelines.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines

Discussion thread:
https://lists.apache.org/thread/o2ytmjj2tyc2xcy6xh5tco31yyjzvz8p

Thanks
Fede