-
Notifications
You must be signed in to change notification settings - Fork 601
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
c/migrations: list mountable topics #23601
Conversation
be9dc1b
to
8d24a46
Compare
8e38ad1
to
fe3561c
Compare
@bashtanov @andrwng this is ready for review. |
fe3561c
to
b288d47
Compare
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.
looks good from docs
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.
b288d47, which appears to be the substantive commit of this PR, needs a commit message description.
and split this last commit perhaps, as it is 19 files and 500+ lines |
12f9924
to
61420e9
Compare
ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/56169#019272fe-f7e4-44d4-97f1-c034ee5f4adb |
.label = cloud_storage::remote_label( | ||
path_parse_result->cluster_uuid()), |
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.
@nvartolomei Willem is adding revision to the mount manifest path in #23730. Once it is merged, can we return {uuid}/{rev}
here? The plan is to support a hint from user when mounting, and the hint is a prefix for this path component of the topic manifest. If there are multiple unmounted topics with the same name and cluster UUID having a revision would be beneficial.
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 we keep them separate and ask user 3 fields (label (cluster uuid), topic, revision)? Because that's how things are represented in most parts. I'm afraid that putting together the label/cluster uuid with revision id will cause confusion long term... It is an accident for the most part that label and rev id are next to each other here (topic manifest). I.e. partition manifest, the path is <label>/meta/<ns>/<topic>/<partition>_<revision>
and who knows what we'll come up with down the road.
64e6791
to
c30743f
Compare
c1c3bf1
to
0ea313d
Compare
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.
LGTM, a few silly questions from me.
Also we may need to rename unmounted->mountable as discussed on slack.
0ea313d
to
e225143
Compare
e225143
to
5c9a2a0
Compare
non flaky failures in https://buildkite.com/redpanda/redpanda/builds/57053#0192b9fa-d87c-4777-90e8-c916b6719851:
|
Retry command for Build#57053please wait until all jobs are finished before running the slash command
|
5c9a2a0
to
a702401
Compare
We want to use parsing functionality for listing unmounted topics.
This will allow the same fixture to be used for multiple test suites
a702401
to
64e436b
Compare
We will expose this method through the admin api. A topic for which a mount manifest exists in cloud storage is consider mountable. We list mountable topics by listing the prefix where these manifests are stored and parsing label, namespace, and topic from the object name.
I plan to reuse the same topic mount handler in the migration frontend as well to implement listing of unmounted topics. Lift it up in this commit. In subsequent commit it will be injected and used in the frontend.
All addressed. Happy to follow up.
Backports Required
Release Notes