From 367d32080174f6ff0c32eb3e05c3b9df982f9a04 Mon Sep 17 00:00:00 2001 From: Matt Riedemann Date: Wed, 16 Mar 2016 19:41:08 -0400 Subject: [PATCH] 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 --- specs/newton/approved/flavor-cell-api.rst | 243 ++++++++++++++++++++++ 1 file changed, 243 insertions(+) create mode 100644 specs/newton/approved/flavor-cell-api.rst diff --git a/specs/newton/approved/flavor-cell-api.rst b/specs/newton/approved/flavor-cell-api.rst new file mode 100644 index 000000000..0acb4de68 --- /dev/null +++ b/specs/newton/approved/flavor-cell-api.rst @@ -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.