Difference between revisions of "Trove/FlexibleDatastoreOpts"
(→Where Trove will look for required configurations?) |
(→How will datastore.options will look like?) |
||
| (13 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
trove/templates/{datastore}/datastore.options | trove/templates/{datastore}/datastore.options | ||
| + | or | ||
| + | trove/templates/datastore_options/{datastore}.options | ||
== How will ''datastore.options'' will look like? == | == How will ''datastore.options'' will look like? == | ||
| Line 11: | Line 13: | ||
The easiest way is to chose one of already existing DLS's such as JSON, YAML, XML, etc. | The easiest way is to chose one of already existing DLS's such as JSON, YAML, XML, etc. | ||
| − | + | Suggestion: | |
JSON | JSON | ||
=== Example === | === Example === | ||
| − | + | trove/templates/mysql/datastore.options | |
| + | |||
| + | or | ||
| + | |||
| + | trove/templates/datastore_options/{datastore}.options | ||
| + | |||
{ | { | ||
| Line 39: | Line 46: | ||
} | } | ||
} | } | ||
| + | |||
| + | == How Trove will look for ''datastore.options''?== | ||
| + | |||
| + | We will use already implemented mechanis that used for ''configuration.template'' and ''heat.template'' using JINJA2 framework | ||
| + | |||
| + | |||
| + | == How Trove will parse each ''datastore.options'' ? == | ||
| + | |||
| + | By using native python tools like: | ||
| + | python json library | ||
| + | |||
| + | First of all Trove will look at the template for specific sections, such as: | ||
| + | "list_options", "dict_options", "string_options", "boolean_options" | ||
| + | Then will load them and create specific options, join them into groups and register groups for ''datastore'' mentioned at: | ||
| + | |||
| + | trove/templates/{'''datastore'''}/datastore.options | ||
| + | |||
| + | or | ||
| + | |||
| + | trove/templates/datastore_options/{'''datastore'''}.options | ||
= Justification/Benefits = | = Justification/Benefits = | ||
| Line 53: | Line 80: | ||
= Impacts = | = Impacts = | ||
| − | + | Configuration entry point will be re-written to be more flexible than it is now. | |
From user perspective nothing would change. From deployer perspective - will be provided more flexible way to prepare configuration files for each datastores. | From user perspective nothing would change. From deployer perspective - will be provided more flexible way to prepare configuration files for each datastores. | ||
| Line 75: | Line 102: | ||
None | None | ||
| + | |||
| + | = PoC = | ||
| + | PoC is available [https://gist.github.com/denismakogon/1fe5ace10700de12283a here]. | ||
Latest revision as of 07:22, 26 May 2014
Description
At this time all datastore specific options are defined inside codebase, so there's no valid way to add new option to datastore without modifying codebase. We need to define flexible way to load and register datastore options (in future - all Trove options).
Where Trove will look for required configurations?
trove/templates/{datastore}/datastore.options
or
trove/templates/datastore_options/{datastore}.options
How will datastore.options will look like?
The easiest way is to chose one of already existing DLS's such as JSON, YAML, XML, etc.
Suggestion:
JSON
Example
trove/templates/mysql/datastore.options
or
trove/templates/datastore_options/{datastore}.options
{
"list_options":{
"tcp_ports":{
"default": [3306],
"help": "Some random string"
},
"upd_ports":{
"default": [],
"help": "Some random string"
}
},
"string_options":{
"backup_strategy":{
"default": "InnoBackupEx",
"help": "Some random string"
},
"mount_point":{
"default": "/var/lib/mysql",
"help": "Some random string"
}
}
How Trove will look for datastore.options?
We will use already implemented mechanis that used for configuration.template and heat.template using JINJA2 framework
How Trove will parse each datastore.options ?
By using native python tools like:
python json library
First of all Trove will look at the template for specific sections, such as:
"list_options", "dict_options", "string_options", "boolean_options"
Then will load them and create specific options, join them into groups and register groups for datastore mentioned at:
trove/templates/{datastore}/datastore.options
or
trove/templates/datastore_options/{datastore}.options
Justification/Benefits
Justification
Trove uses configuration file that describes what types of groups and options can be used. No valid way to add/modify options without changing actual Trove codebase. We need to define valid way to load configurations from external sources and render them into a oslo.config groups with specific options.
Benefits
The biggest benefit is adding support of commercial datastores into the Trove-API, Trove-Taskmanager, Trove-Conductor services. Proposed feature allows to load configuration files for each datastore from external sources.
Impacts
Configuration entry point will be re-written to be more flexible than it is now. From user perspective nothing would change. From deployer perspective - will be provided more flexible way to prepare configuration files for each datastores.
Configuration
None
Database
None
Public API
None
Internal API
None
Guestagent changes
None
PoC
PoC is available here.
