Skip to content

Comments

KAFKA-10764: Add support for returning topic IDs on create, supplying topic IDs for delete#9684

Merged
rajinisivaram merged 12 commits intoapache:trunkfrom
jolshan:KAFKA-10764
Jan 29, 2021
Merged

KAFKA-10764: Add support for returning topic IDs on create, supplying topic IDs for delete#9684
rajinisivaram merged 12 commits intoapache:trunkfrom
jolshan:KAFKA-10764

Conversation

@jolshan
Copy link
Member

@jolshan jolshan commented Dec 4, 2020

Updated CreateTopicResponse, DeleteTopicsRequest/Response and added some new AdminClient methods and classes. Now the newly created topic ID will be returned in CreateTopicsResult and found in TopicAndMetadataConfig, and topics can be deleted by supplying topic IDs through deleteTopicsWithIds which will return DeleteTopicsWithIdsResult.

Committer Checklist (excluded from commit message)

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

}

/**
* Returns a future that provides number of partitions in the topic when the request completes.
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 noticed all these comments say "If broker version doesn't support replication factor in the response..." should each actually say whatever the method is returning (numPartitions, topicId, etc.)

Copy link
Contributor

Choose a reason for hiding this comment

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

In the create result, we wouldn't see UnsupportedVersionException for topicId() just because topic ids are not enabled, would we?

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 think we could either do that or just return Uuid.ZERO_UUID

Copy link
Contributor

Choose a reason for hiding this comment

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

Returning Uuid.ZERO_UUID should be fine. The comment just seems odd, I am not sure why we have it that way in the other methods.

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 thought it was odd too.

{ "name": "TopicNames", "type": "[]string", "versions": "0+", "entityType": "topicName",
{ "name": "Topics", "type": "[]DeleteTopicState", "versions": "6+", "about": "The name or topic ID of the topic",
"fields": [
{"name": "Name", "type": "string", "versions": "6+", "nullableVersions": "6+", "about": "The topic name"},
Copy link
Member

Choose a reason for hiding this comment

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

Why is topic name nullable but topicId not? do you mean we will fill all delete requests with a topicId before sending a request?

Copy link
Member Author

Choose a reason for hiding this comment

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

We will use the zero UUID to represent null as described in the KIP.

@jolshan
Copy link
Member Author

jolshan commented Jan 5, 2021

I'm planning on adding one more test, but that test is blocked on #9814

Copy link
Contributor

@rajinisivaram rajinisivaram left a comment

Choose a reason for hiding this comment

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

@jolshan Thanks for the PR, looks good. Left some minor comments. I didn't see an authorization test for delete topics where topic id is specified, but we are authorizing topic name. Can we add a test in AuthorizerIntegrationTest?

}

/**
* Returns a future that provides number of partitions in the topic when the request completes.
Copy link
Contributor

Choose a reason for hiding this comment

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

In the create result, we wouldn't see UnsupportedVersionException for topicId() just because topic ids are not enabled, would we?

Copy link
Contributor

@rajinisivaram rajinisivaram left a comment

Choose a reason for hiding this comment

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

@jolshan Thanks for the PR, LGTM. Left just one minor comment.

@rajinisivaram
Copy link
Contributor

The failing test FetcherTest.testEarlierOffsetResetArrivesLate is a known flaky test (https://issues.apache.org/jira/browse/KAFKA-12245). Merging to trunk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants