Add API to update cluster-level compaction configs#16803
Add API to update cluster-level compaction configs#16803kfaraz merged 5 commits intoapache:masterfrom
Conversation
| final DataSourceCompactionConfig config = DataSourceCompactionConfig | ||
| .builder() | ||
| .forDataSource("dataSource") | ||
| .withInputSegmentSizeBytes(500L) | ||
| .withMaxRowsPerSegment(30) |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| final DataSourceCompactionConfig config = DataSourceCompactionConfig | ||
| .builder() | ||
| .forDataSource("dataSource") | ||
| .withInputSegmentSizeBytes(500L) | ||
| .withMaxRowsPerSegment(10000) |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
|
|
||
| final List<DataSourceCompactionConfig> datasourceConfigs = newConfig.getCompactionConfigs(); | ||
| if (CollectionUtils.isNullOrEmpty(datasourceConfigs) | ||
| || current.getEngine() == newConfig.getEngine()) { |
There was a problem hiding this comment.
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.
No, the update payload is only to update the cluster level configs. It does not contain any datasource level configs right now.
gargvishesh
left a comment
There was a problem hiding this comment.
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.
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.
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.
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.
Would ClusterCompactionConfigUpdateRequest be a better name here?
There was a problem hiding this comment.
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.
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.
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.
Should we mark the above API as deprecated, now that there is also the /global endpoint?
There was a problem hiding this comment.
Else engine should be supported here as well.
There was a problem hiding this comment.
Hmm, fair point. Let me mark this API as deprecated.
gargvishesh
left a comment
There was a problem hiding this comment.
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.
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.
Yes, particularly since it would no longer reside with the coordinator. Among the 2, I would prefer ClusterCompactionConfig
AmatyaAvadhanula
left a comment
There was a problem hiding this comment.
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/clusterto update cluster level compaction configCompactionConfigUpdateRequestCoordinatorCompactionConfigwhich caused compaction engine to not be persisted.Use json field name
engineinstead ofcompactionEnginebecause JSON field names must alignwith the getter name.
CoordinatorCompactionConfigResourceTestto remove unnecessary mockingand add more meaningful tests.
TuningConfigBuilderto easily build tuning configs for tests.DatasourceCompactionConfigBuilderRelease 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/clusterMethod: POST
Sample Payload:
This API deprecates the older API
/druid/coordinator/v1/config/compaction/taskslots.This PR has: