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

[v23.3.x] Fix configs returned in CreateTopicsResponse #17239

Conversation

pgellert
Copy link
Contributor

@pgellert pgellert commented Mar 21, 2024

Backport of PR #16922
Closes #17237

This extracts the topic config specific code in describe_configs and
moves it into a separate file so that it can later be reused in the
CreateTopic handler.

(cherry picked from commit 47cf65f)
This adds unit tests for the config response creating methods. These
methods grew quite complex with various overloads of the method
exhibiting different behaviour, so I've added some tests partly to
demonstrate their behaviour and partly to enable a future cleanup of the
methods.

(cherry picked from commit 773f836)
This is the main change of the PR. It changes the CreateTopics handler
to use the shared code of DescribeConfigs to generate the configs
returned to the client.

We can share this code because the DescribeConfigs object is a more
general version of the configs returned in the CreateTopics endpoint, so
we can just derive the latter from the former.

The reason for changing the CreateTopics handler this way is that
currently the CreateTopics handler has a bug where it only ever returns
the topic-specific override configs of the topic in the response,
whereas it should return all the configs of the topic (incl both the
topic-specific override configs and the global broker-level-set topic
config defaults). This is the behavour that Apache Kafka exhibits and
the behaviour that KIP 525 prescribes.

Ref:
 * https://cwiki.apache.org/confluence/display/KAFKA/KIP-525+-+Return+topic+metadata+and+configs+in+CreateTopics+response
(cherry picked from commit 41f9d66)
This removes somee methods in the kafka config handling code that have
either now become unused or have already been unused even before the
changes in this PR.

(cherry picked from commit 1002b63)
This adds a regression test to ensure that the configs returned by
describe configs and the configs returned by create topics match.

This updates/removes an earlier test which only checked that a single
specific config was present.

NOTE: the old test I am updating would fail with the current code. That
is because the new code returns a different source for the
cleanup.policy config, namely DYNAMIC_TOPIC_CONFIG (source=1) instead of
DEFAULT_CONFIG (source=5). Apache Kafka (and our DescribeConfigs
endpoint) both return source=5 in this case, so I believe this is a
bugfix rather than a regression.

(cherry picked from commit 5edfb74)
This refactors the config response utility code to use types that are
not specific to neither the describe configs nor the create topics
handlers.

(cherry picked from commit 4f5d6b6)
@pgellert pgellert added this to the v23.3.x-next milestone Mar 21, 2024
@pgellert pgellert added the kind/backport PRs targeting a stable branch label Mar 21, 2024
@pgellert pgellert marked this pull request as ready for review March 21, 2024 12:55
@pgellert pgellert self-assigned this Mar 21, 2024
@pgellert
Copy link
Contributor Author

This backport is almost identical to the original PR. The conflicts were due to new configurations that were present on the dev branch but not on v23.3.x. I decided to not add (aka. backport) those new configs and just keep the current configs present on v23.3.x.

Copy link
Member

@oleiman oleiman left a comment

Choose a reason for hiding this comment

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

That looks like it was painful. LGTM

config::shard_local_cfg().auto_create_topics_enabled.desc()),
&describe_as_string<bool>);
}

int64_t describe_retention_duration(
Copy link
Member

Choose a reason for hiding this comment

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

so i'm clear, this stuff has been deleted on dev but not on v23.3? describe_retention_duration, describe_retention_bytes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's correct

@pgellert pgellert merged commit d4747c1 into redpanda-data:v23.3.x Mar 22, 2024
19 checks passed
@piyushredpanda piyushredpanda modified the milestones: v23.3.x-next, v23.3.10 Mar 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/redpanda kind/backport PRs targeting a stable branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants