kafka icon indicating copy to clipboard operation
kafka copied to clipboard

KAFKA-15599: Move KafkaMetadataLog to the raft module

Open mimaison opened this issue 6 months ago • 6 comments

  • Rename KafkaMetadataLog to KafkaRaftLog
  • Make raft depend on storage
  • Remove storage dependency on metadata as this otherwise create a cyclic dependency

mimaison avatar May 19 '25 18:05 mimaison

There are some concerns regarding this change, though we haven't made kraft a public API, we are trying to keep it dependency-free to be used as a raft-sdk anywhere. For example, if you are implementing a system with metadata changing frequently, you can directly copy kraft code into your project. This assumption also has some benefits to the whole Kafka architecture, this change reduced dependency complexity but breaked this assumption, we should evaluate which goal is more important.

dengziming avatar May 21 '25 02:05 dengziming

we are trying to keep it dependency-free to be used as a raft-sdk anywhere

Where has this been discussed? The way Kafka implements Raft is via a topic so our implementation of ReplicatedLog needs to depend on storage. Since metadata depends on raft, the other option is to put KafkaMetadataLog into the metadata module and have that depend on storage instead of raft.

mimaison avatar May 21 '25 16:05 mimaison

Where has this been discussed?

In KIP-595 we wrote:

We are also trying to pave the way for normal partition replication through Raft as well as eventually supporting metadata sharding with multiple partitions.

We are only trying to pave the way for Kafka normal partition replication instead of making it SDK exportable, I may have thought too much about it, but the idea behind it still deserves consideration, for example, etcd-raft(https://github.com/etcd-io/raft) also follows a similar principle to not include a concrete log implementation. Moving it to metadata module is better compared putting it in raft module, and we should not rename it to KafkaRaftLog since we can use raft to replicate normal partition.

dengziming avatar May 22 '25 06:05 dengziming

I'm not sure I interpret that statement from KIP-595 as an intent to keep the raft module dependency free. As you said the raft module is not public API, and I've not seen any discussions in that direction.

The metadata module mostly consists of the data structures written to the metadata log. To me it seems the logic of maintaining the metadata log as a topic fits better in the raft module, as described in https://issues.apache.org/jira/browse/KAFKA-15599.

mimaison avatar May 22 '25 09:05 mimaison

@mimaison That makes sense to me, 👍 if we should make the tradeoff, the modularity outweighs the pluggability of the raft module, @jsancio @ijuma, where do you think is better to put KafkaMetadataLog.

dengziming avatar May 23 '25 06:05 dengziming

The description I wrote in the ticket was the conclusion after a discussion with a few people including @jsancio and @cmccabe. @jsancio does that approach still make sense to you?

ijuma avatar May 23 '25 16:05 ijuma

@jsancio Can you take another look? Thanks

mimaison avatar Aug 06 '25 16:08 mimaison

Rebased on trunk, @jsancio @junrao can you take another look? Thanks

mimaison avatar Sep 02 '25 16:09 mimaison

Rebased on trunk to resolve conflicts

mimaison avatar Sep 09 '25 09:09 mimaison

Rebased once more. @jsancio @junrao can you take another look? Thanks

mimaison avatar Sep 16 '25 19:09 mimaison

@jsancio @junrao I keep rebasing this each week. Quick reminder, can you take another look? Thanks

mimaison avatar Sep 29 '25 14:09 mimaison