Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-18465: Remove MetadataVersions older than 3.0-IV1 #18468

Open
wants to merge 5 commits into
base: trunk
Choose a base branch
from

Conversation

ijuma
Copy link
Member

@ijuma ijuma commented Jan 10, 2025

Apache Kafka 4.0 will only support KRaft and 3.0-IV1 is the minimum version supported by KRaft. So, we can assume that Apache Kafka 4.0 will only communicate with brokers that are 3.0-IV1 or newer.

Note that KRaft was only marked as production-ready in 3.3, so we could go further and set the baseline to 3.3. I think we should have that discussion, but it made sense to start with the non controversial parts.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@ijuma ijuma requested a review from junrao January 10, 2025 01:11
@ijuma ijuma force-pushed the kafka-18465-remove-metadata-version-methods-for-versions-older-than-3.0 branch from 1097696 to c557e0b Compare January 10, 2025 01:22
Copy link
Member

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ijuma nice cleanup!

if (version < 3)
assertEquals(OffsetsForLeaderEpochRequest.DEBUGGING_REPLICA_ID, parsed.replicaId());
else
assertEquals(replicaId, parsed.replicaId());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we keep the test for version=4 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The value of this test is a bit low, but I added it back.

@@ -731,7 +731,6 @@ private void cancelClassicGroupSizeCounter() {
public void onLoaded(MetadataImage newImage) {
MetadataDelta emptyDelta = new MetadataDelta(newImage);
groupMetadataManager.onNewMetadataImage(newImage, emptyDelta);
offsetMetadataManager.onNewMetadataImage(newImage, emptyDelta);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we don't need to clean up GroupMetadataManager.scala, as 4.0 uses a new coordinator by default?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated that class too where it made sense. Did you spot additional areas of clean-up?

@@ -238,7 +238,7 @@ public static CoordinatorRecord newGroupMetadataRecord(
),
new ApiMessageAndVersion(
value,
metadataVersion.groupMetadataValueVersion()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please remove variable MetadataVersion metadataVersion as it is unused now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

) {
short version = metadataVersion.offsetCommitValueVersion(offsetAndMetadata.expireTimestampMs.isPresent());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems we need to use version=1 in order to keep "expireTimestamp". otherwise, in v3 expireTimestamp will be ignored in serialization.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this change is wrong - a few things will be reverted as a result.

Copy link
Member Author

@ijuma ijuma Jan 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed this one - still working through a few other things.

@ijuma
Copy link
Member Author

ijuma commented Jan 10, 2025

Thanks for the quick review @chia7712. I should have left a note, but I'm still working on this PR. I'll take a look at your comments soon.

Apache Kafka 4.0 will only support KRaft and 3.0 was the first release where KRaft was in a reasonable state (even if not production ready yet). So, we can assume that Apache Kafka 4.0 will only communicate with brokers that are 3.0 or newer.

A couple of notes:

1. KRaft was only marked as production-ready in 3.3, so we could go further and set the baseline to 3.3. I think we should have that discussion, but it made sense to start with the non controversial parts.
2. I have not removed the actual IBP definitions - leaving that for a separate PR.
@ijuma ijuma force-pushed the kafka-18465-remove-metadata-version-methods-for-versions-older-than-3.0 branch from c557e0b to 7449859 Compare January 10, 2025 05:24
@ijuma ijuma changed the title KAFKA-18465: Remove MetadataVersion methods for versions older than 3.0 KAFKA-18465: Remove MetadataVersions older than 3.0-IV1 Jan 10, 2025
@github-actions github-actions bot added tools performance storage Pull requests that target the storage module labels Jan 10, 2025
@ijuma
Copy link
Member Author

ijuma commented Jan 10, 2025

I removed the relevant IBP constants too and fixed the known test failures. I'll check the full test results tomorrow and will do a file by file pass then too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clients core Kafka Broker kraft performance storage Pull requests that target the storage module tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants