Re-propose: Add Flavor tables to API Database
The flavor tables were added to the API schema in Mitaka but the online flavor migration did not, so we need to re-propose this for that work to complete in Newton. Previously-approved: Mitaka Spec for blueprint flavor-cell-api Change-Id: Ia7accc14f238e1fcbd04afa9419c18a7eab1345d
This commit is contained in:
Matt Riedemann
243
specs/newton/approved/flavor-cell-api.rst
Normal file
243
specs/newton/approved/flavor-cell-api.rst
Normal file
@@ -0,0 +1,243 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=====================================
|
||||
Add Flavor tables to API Database
|
||||
=====================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/flavor-cell-api
|
||||
|
||||
CellsV2 need to store flavor information for booting instances. Since this
|
||||
information will live at the cell API, tables related to flavors need to be
|
||||
created in API DB.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Flavors are virtual hardware templates, which are used by nova, for example,
|
||||
when creating a new instance.
|
||||
In CellsV1, flavors are stored in parent and child cells. Considerable manual
|
||||
effort is required to keep this information consistent across all the cells.
|
||||
|
||||
Flavors are a global concept that should be stored only in one database.
|
||||
Therefore, flavor related tables for CellsV2 would be created only in the API
|
||||
database.
|
||||
|
||||
Use Cases
|
||||
----------
|
||||
|
||||
* Operators want to partition their deployments into cells for scaling,
|
||||
failure domain, and buildout reasons. When partitioned, flavor
|
||||
information needs to be stored at API level.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
With this spec we propose to create all flavor related tables in the API DB.
|
||||
They are::
|
||||
|
||||
* instance_types
|
||||
* instance_type_extra_specs
|
||||
* instance_type_projects
|
||||
|
||||
The name of the tables will be changed to flavors, flavor_extra_specs and
|
||||
flavor_projects respectively but the table schema will remain unchanged.
|
||||
|
||||
The flavor object will be modified to interact with the tables in the API
|
||||
database. The create() and save() method will be updated to use the API DB
|
||||
tables.
|
||||
|
||||
The get_by_*() methods will be modified to query the API DB and if a flavor
|
||||
is not found, query the nova DB as well. The get_all() method will be modified
|
||||
so that it displays all the flavors, which will be a union of what exists in
|
||||
API DB and nova DB. It will query the API DB and then query the nova DB to
|
||||
get the flavors not yet present in API DB.
|
||||
|
||||
The destroy() method will remove flavors from both the databases. This will
|
||||
ensure that all flavor related operations are done on the new table and older
|
||||
flavors are also actively migrated to the new table as they are used. The
|
||||
existing flavor tables in nova will continue to remain but no longer accessed
|
||||
and can be removed in subsequent releases.
|
||||
|
||||
During the transition phase, databases corresponding to both cellV1 and V2
|
||||
will co-exist and tests will be written to make sure that the flavor tables
|
||||
in CellsV2 have the same model as in CellV1. Any change in the tables should
|
||||
be applied in both databases.
|
||||
|
||||
To migrate existing flavor data to the proposed cellsV2 tables a new
|
||||
"nova-manage" command will be added.
|
||||
|
||||
This command will copy flavor entries from top-level cell DB to the new API DB.
|
||||
It will take no parameters and on execution read the data from flavor tables
|
||||
(instance_types, instance_type_extra_specs and instance_type_projects) and put
|
||||
it into the corresponsing tables in API DB if it doesn't already exist.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could continue storing flavor at both api and cell level or store flavors
|
||||
only at compute cell level. Both these approaches introduce addtional
|
||||
complexity in flavor management.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
Three new tables will be created in 'nova_api' database as follows. The
|
||||
corresponding schemas are detailed below,
|
||||
|
||||
* 'flavors':::
|
||||
CREATE TABLE `flavors` (
|
||||
`created_at` datetime DEFAULT NULL,
|
||||
`updated_at` datetime DEFAULT NULL,
|
||||
`deleted_at` datetime DEFAULT NULL,
|
||||
`name` varchar(255) DEFAULT NULL,
|
||||
`id` int(11) NOT NULL AUTO_INCREMENT,
|
||||
`memory_mb` int(11) NOT NULL,
|
||||
`vcpus` int(11) NOT NULL,
|
||||
`swap` int(11) NOT NULL,
|
||||
`vcpu_weight` int(11) DEFAULT NULL,
|
||||
`flavorid` varchar(255) DEFAULT NULL,
|
||||
`rxtx_factor` float DEFAULT NULL,
|
||||
`root_gb` int(11) DEFAULT NULL,
|
||||
`ephemeral_gb` int(11) DEFAULT NULL,
|
||||
`disabled` tinyint(1) DEFAULT NULL,
|
||||
`is_public` tinyint(1) DEFAULT NULL,
|
||||
`deleted` int(11) DEFAULT NULL)
|
||||
|
||||
This table will have unique constraints on (name, deleted) and (flavorid,
|
||||
deleted) attributes
|
||||
|
||||
* 'flavors_extra_specs':::
|
||||
|
||||
CREATE TABLE `flavor_extra_specs` (
|
||||
`created_at` datetime DEFAULT NULL,
|
||||
`updated_at` datetime DEFAULT NULL,
|
||||
`deleted_at` datetime DEFAULT NULL,
|
||||
`id` int(11) NOT NULL AUTO_INCREMENT,
|
||||
`flavor_id` int(11) NOT NULL,
|
||||
`key` varchar(255) DEFAULT NULL,
|
||||
`value` varchar(255) DEFAULT NULL,
|
||||
`deleted` int(11) DEFAULT NULL)
|
||||
|
||||
This table will have a unique constraint on (flavor_id, key,
|
||||
deleted) attribute and an index on (flavor_id, key)
|
||||
|
||||
* 'flavor_projects':::
|
||||
|
||||
CREATE TABLE `flavor_projects` (
|
||||
`created_at` datetime DEFAULT NULL,
|
||||
`updated_at` datetime DEFAULT NULL,
|
||||
`deleted_at` datetime DEFAULT NULL,
|
||||
`id` int(11) NOT NULL AUTO_INCREMENT,
|
||||
`flavor_id` int(11) NOT NULL,
|
||||
`project_id` varchar(255) DEFAULT NULL,
|
||||
`deleted` int(11) DEFAULT NULL)
|
||||
|
||||
This table will have a unique constraint on (flavor_id, project_id,
|
||||
deleted) attribute
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Deployers will be provided with a new nova-manage command to migrate the
|
||||
flavors to the cellsV2 DB API proposed tables. This command will need to be
|
||||
run once for any existing deployments (cell or non-cell).
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
mvineetmenon
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Create new database tables 'flavors', 'flavor_extra_specs'
|
||||
and 'flavor_projects' in API DB.
|
||||
|
||||
* Modify the flavor object to interact with API DB
|
||||
|
||||
* Create a new command in nova-manage for migrating flavors from cellsV1 to
|
||||
cellsV2
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Since this is designed to be an internal re-architecting of Nova with no user
|
||||
visible changes the current suite of Tempest or functional tests should
|
||||
suffice.
|
||||
|
||||
Also, tests need to be written to ensure that the data model doesn't change
|
||||
from what is being used in the cellsV1 model.
|
||||
|
||||
These tests should be kept until the final migration to cellsV2.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Document the `nova-manage` command to migrate flavors from top-level cell DB to
|
||||
cellsV2 API-DB.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
``https://etherpad.openstack.org/p/kilo-nova-cells``
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Mitaka
|
||||
- Introduced
|
||||
* - Newton
|
||||
- Re-proposed; flavor tables were added to the API database schema in
|
||||
Mitaka but the online flavor migration was not completed.
|
||||
Reference in New Issue
Block a user