openstack/trove-specs
Code Issues Proposed changes
master
trove-specs/specs/kilo/associate-flavors-datastores.rst
Nikhil Manchanda 4a72d213aa Add unit tests for Trove specs 
Add simple unit tests to the Trove specs repo which ensure that
specifications submitted follow the template correctly and address
all the needed sections.

Update tox to run these unit tests automatically.

At the beginning of each release, test_titles.py will need to be updated
and 'current_release' modified to reflect the new release directory.  At
the same time, the new release directory will be created, the index.rst
file in doc/source ammended to include this directory, and any unmerged
specs moved there.  In this way, changes to the template will only
affect specs going forward and avoids having to modify any specs that
have merged in previous releases.

(It will also have the side effect of signalling the 'opening' of the
release to new specs.)

Change-Id: I8f1175bceed63d36d96b6c6c6b4188ef27d3102e
2015-06-16 21:53:16 +00:00

3.4 KiB
Raw Permalink Blame History

Associate instance flavors with datastores

Launchpad blueprint:

https://blueprints.launchpad.net/trove/+spec/associate-flavors-datastores

Motivation: Each datastore type has its own hardware requirements (minimum and maximum). Currently, trove lacks the ability to enforce this requirement. This change enables trove with the ability to associate the virtual hardware templates (flavors) with datastore types.

Problem Description

Trove supports multiple datastore types. However, each datastore type has its own hardware requirements, which presently, cannot be enforced in trove.

For example: MySQL - Minimum System Requirements: - 2 or more CPU cores - 2 or more GB of RAM - Disk I/O subsystem applicable for a write-intensive database

Find more information about other datastore specific hardware requirements in the References section.

Trove uses virtual hardware templates called 'flavors' in OpenStack. In order for trove to be able to enforce the datastore specific hardware requirements, there needs to be a way in which datastore types can be associated with their minimum flavor (hardware) requirements. This way, the user/administrator can at least be notified while provisioning the datastore with the inappropriate flavor, that does not meet the minimum hardware requirements.

Proposed Change

  • The trove-manage utility will provide the ability to add and delete the datastore version-flavor associations.
  • There will be an additional API call in order to get a list of flavors for the specified datastore version id.

Configuration

None

Database

No impact on existing tables.

One new entity will be created in the trove database: datastore_version_metadata. This will store any additional metadata related to a datastore version including its relation with flavors: key=flavor and the value=flavor_id.

The blueprint specifies the table attributes in detail.

Public API

Does not impact any other API which the user has access to.

Public API Security

None

Internal API

None

Guest Agent

None

Alternatives

None

Implementation

Assignee(s)

Milestones

Kilo-1

Work Items

  • Add the new database schema for datastore version metadata.
  • trove-manage util extension to associate a flavor list with a datastore version id
  • trove-manage util extension to delete a flavor associated with a datastore version id.
  • REST API call to list flavors for a datastore version id (/{tenant_id}/flavors/{datastore_version_id})
  • Unit and integration tests

Dependencies

None

Testing

  • Unit tests for individual components.
  • Integration tests for end-to-end testing.

Documentation Impact

  • New API call to list flavors given a datastore version id.
  • trove-manage util extensions to add/delete datastore version -flavor associations.

References