-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Add API to update cluster-level compaction configs #16803
Conversation
final DataSourceCompactionConfig config = DataSourceCompactionConfig | ||
.builder() | ||
.forDataSource("dataSource") | ||
.withInputSegmentSizeBytes(500L) | ||
.withMaxRowsPerSegment(30) |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note test
Builder.withMaxRowsPerSegment
final DataSourceCompactionConfig config = DataSourceCompactionConfig | ||
.builder() | ||
.forDataSource("dataSource") | ||
.withInputSegmentSizeBytes(500L) | ||
.withMaxRowsPerSegment(10000) |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note test
Builder.withMaxRowsPerSegment
|
||
final List<DataSourceCompactionConfig> datasourceConfigs = newConfig.getCompactionConfigs(); | ||
if (CollectionUtils.isNullOrEmpty(datasourceConfigs) | ||
|| current.getEngine() == newConfig.getEngine()) { |
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 it possible for the payload to contain the current engine but incompatible configs?
For example the current engine is MSQ, and the update payload is also MSQ but with Native-only configs.
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.
No, the update payload is only to update the cluster level configs. It does not contain any datasource level configs right now.
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.
Thanks for the PR @kfaraz. Overall changes LGTM. A few minor comments.
|
||
import java.util.Map; | ||
|
||
public class DataSourceCompactionConfigBuilder |
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: Any particular reason to separate out the builder in a file of its own instead of adding to the DataSourceCompactionConfig
file itself?
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.
Not particularly, just didn't want to bloat up the DataSourceCompactionConfig
class as it is currently a neat bean.
Since the builder is only 100 lines of code, I can put it in the same file too.
Let me know what you think.
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 think changes to both would typically be in tandem, so would prefer to keep in the same file.
private final CompactionEngine compactionEngine; | ||
|
||
@JsonCreator | ||
public CompactionConfigUpdateRequest( |
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.
Would ClusterCompactionConfigUpdateRequest
be a better name here?
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.
It would be. I think we should also rename CoordinatorCompactionConfig
to ClusterCompactionConfig
or GlobalCompactionConfig
. What do you think?
Also, would it be okay to do the rename changes and the API deprecation in a follow up PR?
(I have some more follow-up changes lined up).
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.
Yes, particularly since it would no longer reside with the coordinator. Among the 2, I would prefer ClusterCompactionConfig
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.
Cool, I guess we should rename the API to /cluster
as well then.
UnaryOperator<CoordinatorCompactionConfig> operator = | ||
current -> CoordinatorCompactionConfig.from( | ||
current, | ||
return updateClusterCompactionConfig( |
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 mark the above API as deprecated, now that there is also the /global
endpoint?
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.
Else engine
should be supported here as well.
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.
Hmm, fair point. Let me mark this API as deprecated.
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.
Approving as I'm okay with the discussed modifications being taken up in the follow-up PR as well.
|
||
import java.util.Map; | ||
|
||
public class DataSourceCompactionConfigBuilder |
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 think changes to both would typically be in tandem, so would prefer to keep in the same file.
private final CompactionEngine compactionEngine; | ||
|
||
@JsonCreator | ||
public CompactionConfigUpdateRequest( |
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.
Yes, particularly since it would no longer reside with the coordinator. Among the 2, I would prefer ClusterCompactionConfig
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.
Thanks for the clarification, @kfaraz. LGTM
Thanks for the reviews, @gargvishesh , @AmatyaAvadhanula ! |
Changes: - Add API `/druid/coordinator/v1/config/compaction/global` to update cluster level compaction config - Add class `CompactionConfigUpdateRequest` - Fix bug in `CoordinatorCompactionConfig` which caused compaction engine to not be persisted. Use json field name `engine` instead of `compactionEngine` because JSON field names must align with the getter name. - Update MSQ validation error messages - Complete overhaul of `CoordinatorCompactionConfigResourceTest` to remove unnecessary mocking and add more meaningful tests. - Add `TuningConfigBuilder` to easily build tuning configs for tests. - Add `DatasourceCompactionConfigBuilder`
Changes
/druid/coordinator/v1/config/compaction/cluster
to update cluster level compaction configCompactionConfigUpdateRequest
CoordinatorCompactionConfig
which caused compaction engine to not be persisted.Use json field name
engine
instead ofcompactionEngine
because JSON field names must alignwith the getter name.
CoordinatorCompactionConfigResourceTest
to remove unnecessary mockingand add more meaningful tests.
TuningConfigBuilder
to easily build tuning configs for tests.DatasourceCompactionConfigBuilder
Release notes
(Some of the details mentioned below are in a follow up PR #16810)
Add API to update cluster-level compaction dynamic config
Path:
/druid/coordinator/v1/config/compaction/cluster
Method: POST
Sample Payload:
This API deprecates the older API
/druid/coordinator/v1/config/compaction/taskslots
.This PR has: