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
KREST-3009 Add ability to update partition count on a topic #1084
KREST-3009 Add ability to update partition count on a topic #1084
Conversation
This does make sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nits.
kafka-rest/src/main/java/io/confluent/kafkarest/resources/v3/TopicsResource.java
Outdated
Show resolved
Hide resolved
kafka-rest/src/test/java/io/confluent/kafkarest/controllers/TopicManagerImplTest.java
Outdated
Show resolved
Hide resolved
@@ -451,6 +454,8 @@ public class TopicManagerImplTest { | |||
|
|||
@Mock private DeleteTopicsResult deleteTopicsResult; | |||
|
|||
@Mock CreatePartitionsResult createPartitionsResult; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1.
I think we should add a couple of integration tests and we'll be golden.
summary: 'Update partition count' | ||
operationId: updatePartitionCountKafkaV3Topic | ||
description: |- | ||
[![Generally Available](https://img.shields.io/badge/Lifecycle%20Stage-Generally%20Available-%2345c6e8)](#section/Versioning/API-Lifecycle-Policy) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest starting with a non-GA status initially, unless there are clear reasons why this should be immediately considered GA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@axisc Thoughts? I think this is simple enough to go straight to GA, but it's safer to EA first. Do Terraform's requirements have an impact on this decision?
api/v3/openapi.yaml
Outdated
@@ -1112,6 +1135,7 @@ paths: | |||
$ref: '#/components/responses/TooManyRequestsErrorResponse' | |||
'5XX': | |||
$ref: '#/components/responses/ServerErrorResponse' | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Redundant blank line.
api/v3/openapi.yaml
Outdated
properties: | ||
partition_count: | ||
type: integer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Specify that this should be a 32-bit int with format: int32
.
topicManager | ||
.get() | ||
.getTopic(clusterId, topicName) | ||
.thenApply(topic -> topic.orElseThrow(NotFoundException::new)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this practically guaranteed not to throw if the update operation succeeded? It should still stay there to address edge cases like racing delete and update, I just want to understand the failure path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I did go through that thought process, it's borrowed straight from the get topic code but I thought to leave it matching. But you're right, there's only a really tiny timing window where the topic could be deleted. Overkill though, so happy to take it off.
kafka-rest/src/main/java/io/confluent/kafkarest/resources/v3/TopicsResource.java
Show resolved
Hide resolved
Yup, totally agree. Half written but fighting back atm. We may still need this PR in in a hurry, so will do it as a follow up. |
6c4eb63
to
8f94202
Compare
Squashed commit so I can cherry pick more easily to the cloud release branch
8f94202
to
eba75b9
Compare
Call looks like
Error messages are shown as returned by kafka
I don't think we have a PATCH call anywhere else in the code. I think it's right here - we are modifying but not fully replacing an existing topic object's information.
The flip of that could be that it should be a PUT as we are fully and idempotently replacing the whole of the topic's partition_count object, but patch felt more future safe, in case we add other things to the request body in future?