-
Notifications
You must be signed in to change notification settings - Fork 445
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
Compaction property redesign #4273
Comments
For naming, could have the following property names.
And the following SPI with interface CompactionPlannerFactory {
void init(PluginEnvironment env);
CompactionPlanner forService(String serviceName);
}
interface CompactionPlanner {
Set<GroupConfig> getGroups();
List<Job> plan(tabletPlanningInformation);
} |
Thinking about property validation, something that I just added to the Upgrader in 2.1.3, having properties defined in the SPI classes and not in Property.java makes validation incomplete. It might be good for the service provider interfaces to extend a common base interface that has a method which returns a property validator object. That would let the SPI implementer use whatever properties they like, but we still have a way to validate that the configuration is correct. |
I removed the |
Had a discussion with @keith-turner and @ddanielr about some of the compaction configuration and SPI design, and we came up with some of these ideas that could be implemented:
One major unknown is what to call it. We went back and forth a bit on whether it should be
CompactionService*
orCompactionPlanner*
a.
compaction.service.factory
holds the class name (singleton ref in ServerContext?)b.
compaction.service.factory.config
holds a single string of all the factory's configinit
can validate the config, or re-validate periodically (implementation dependent)Our default configuration for the
compaction.service.factory.config
could be (not pretty-printed, but can be copied/pasted into the property description in an HTML-friendly pretty-printed way):One of the main benefits of this is having simplified configuration for user's configuration file. Also, we'll be able to set a default value in the DefaultConfiguration that actually lives in one place, and is easy for users to view for reference that represents the actual default behavior and override if they want to.
Re: #3981, #4034 , #4061
The text was updated successfully, but these errors were encountered: