-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Add TableConfigValidator and InstanceConfigValidator SPI for batch restart enforcement #18167
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -78,6 +78,7 @@ | |
| import org.apache.pinot.segment.local.utils.TableConfigUtils; | ||
| import org.apache.pinot.spi.config.TableConfigs; | ||
| import org.apache.pinot.spi.config.table.TableConfig; | ||
| import org.apache.pinot.spi.config.table.TableConfigValidatorRegistry; | ||
| import org.apache.pinot.spi.data.LogicalTableConfig; | ||
| import org.apache.pinot.spi.data.Schema; | ||
| import org.apache.pinot.spi.utils.JsonUtils; | ||
|
|
@@ -535,6 +536,7 @@ private void validateConfig(TableConfigs tableConfigs, String database, @Nullabl | |
| } | ||
| } | ||
| TaskConfigUtils.validateTaskConfigs(tableConfigs.getOffline(), schema, _pinotTaskManager, typesToSkip); | ||
| TableConfigValidatorRegistry.validate(offlineTableConfig, schema); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This validator still runs inside validateConfig(), but addConfig()/updateConfig() call tuneConfig() only afterwards. That means the SPI is evaluating a different TableConfig than the one that is actually persisted, unlike the /tables endpoints where tuning happens before validation. A validator can therefore reject or allow the same mutation depending on which API the caller uses. If this SPI is meant to protect the stored config, it needs to run after tuning or in PinotHelixResourceManager.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch on the ordering. I investigated what
None of these touch instance assignment, replica groups, pools, or server tags — the fields that config validators (like batch restart enforcement) inspect. So the pre-tuned and post-tuned configs are identical for validation purposes. I considered moving the SPI call out of If a future tuner modifies fields that validators care about, the right fix at that point would be to move tuning before |
||
| } | ||
| if (realtimeTableConfig != null) { | ||
| String realtimeRawTableName = DatabaseUtils.translateTableName( | ||
|
|
@@ -555,6 +557,7 @@ private void validateConfig(TableConfigs tableConfigs, String database, @Nullabl | |
| } | ||
| } | ||
| TaskConfigUtils.validateTaskConfigs(tableConfigs.getRealtime(), schema, _pinotTaskManager, typesToSkip); | ||
| TableConfigValidatorRegistry.validate(realtimeTableConfig, schema); | ||
| } | ||
| if (offlineTableConfig != null && realtimeTableConfig != null) { | ||
| TableConfigUtils.verifyHybridTableConfigs(rawTableName, offlineTableConfig, realtimeTableConfig); | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.