Difference between revisions of "Trove/trove-per-datastore-volume-support"
Iccha-sethi (talk | contribs) (→Capabilities) |
Iccha-sethi (talk | contribs) (→Config Values) |
||
| Line 10: | Line 10: | ||
Every data store config will have a support_volume config. If this is not present, it will default to the trove_support_volume config. | Every data store config will have a support_volume config. If this is not present, it will default to the trove_support_volume config. | ||
The config values can be loaded based on data store manager. | The config values can be loaded based on data store manager. | ||
| + | |||
| + | If a request is made to create an instance with volume, and for given datastore volumes are not supported HTTP 403 Forbidden is raised. | ||
Example: | Example: | ||
Revision as of 20:42, 30 June 2014
Contents
Overview
Currently trove allows deployers to turn on and off volume support for all datastores using trove_volume_support config value. This blueprint extends this functionality to a per datastore version basis, i.e. turning on/off volume support for a given datastore version.
Implementation Methodologies
Before a capability is added, I think we as a community should question if this feature is indeed a capability or are config values sufficient for it. Below both the implementation methodologies are discussed.
Config Values
Every data store config will have a support_volume config. If this is not present, it will default to the trove_support_volume config. The config values can be loaded based on data store manager.
If a request is made to create an instance with volume, and for given datastore volumes are not supported HTTP 403 Forbidden is raised.
Example:
[mysql] volume_support = True [redis] volume_support = False
Capabilities
Capability names need to be consistent across deployments because the checks in the code will expect a certain capability name. Hence introducing a new capability requires:
- Migration to add a row to the capabilities table with the name and description of a capability.
- Management calls can be made by operators/deployers to add datastore version ids to the capability overrides table.
Capabilities (capabilities)
This table will contain the id, name and description of the capabilities
| FieldName | Value |
|---|---|
| id | Generated UUID |
| name | volume_support |
| description | True, if datastore version supports volumes services. |
| enabled | Migration gets the value from trove_support_value |
API Resources
There are no additions to the API calls, but below are few changes I would like to propose.
- We currently modify api schema[1] and flavor view[2] based on the config value trove_volume_support. But this blueprint introduces volume support based on datastores. The api schema and flavor views are not aware of data store information. We could display both volume and local storage, irrespective of volume support and default volume size to zero ( in order to keep it as an integer)
[1] https://github.com/openstack/trove/blob/master/trove/common/apischema.py#L192 [2] https://github.com/openstack/trove/blob/master/trove/flavor/views.py#L38
