将风味表添加到 API 数据库¶

https://blueprints.launchpad.net/nova/+spec/flavor-cell-api

CellsV2 需要存储风味信息以启动实例。由于此信息将位于 Cell API 中，因此需要在 API 数据库中创建与风味相关的表。

问题描述¶

风味是虚拟硬件模板，Nova 在创建新实例时会使用它们，例如。在 CellsV1 中，风味存储在父单元和子单元中。保持所有单元之间信息的同步需要大量的手动工作。

风味是一个全局概念，应该只存储在一个数据库中。因此，CellsV2 的风味相关表将仅在 API 数据库中创建。

用例¶

运营商希望将他们的部署划分为单元，以实现扩展、故障域和构建原因。在划分后，风味信息需要在 API 级别存储。

项目优先级¶

Nova CellV2 在自由软件项目中具有优先地位。

提议的变更¶

通过此规范，我们建议在 API 数据库中创建所有与风味相关的表。它们是

* instance_types
* instance_type_extra_specs
* instance_type_projects

表名将分别更改为 flavors、flavor_extra_specs 和 flavor_projects，但表模式将保持不变。

风味对象将被修改为与 API 数据库中的表进行交互。create() 和 save() 方法将被更新为使用 API 数据库表。

get_by_*() 方法将被修改为查询 API 数据库，如果未找到风味，则查询 nova 数据库。get_all() 方法将被修改为显示所有风味，这将是 API 数据库和 nova 数据库中存在的风味的联合。它将查询 API 数据库，然后查询 nova 数据库以获取尚未存在于 API 数据库中的风味。

destroy() 方法将从两个数据库中删除风味。这将确保所有与风味相关的操作都在新表上完成，并且旧的风味也会在被使用时主动迁移到新表。nova 中现有的风味表将继续保留，但不再访问，并且可以在后续版本中删除。

在过渡阶段，与 cellV1 和 V2 对应的数据库将同时存在，并且将编写测试以确保 CellsV2 中的风味表与 CellV1 中的模型相同。任何对表的更改都应应用于两个数据库。

为了将现有的风味数据迁移到建议的 cellsV2 表，将添加一个新的“nova-manage”命令。

此命令将从顶级单元数据库复制风味条目到新的 API 数据库。它不接受任何参数，执行时会读取风味表（instance_types、instance_type_extra_specs 和 instance_type_projects）中的数据，并将其放入 API 数据库中对应的表中（如果它不存在）。

备选方案¶

我们可以继续在 api 和 cell 级别同时存储风味，或者只在 compute cell 级别存储风味。这两种方法都会引入风味管理方面的额外复杂性。

数据模型影响¶

将在 ‘nova_api’ 数据库中创建三个新表，如下所示。相应的模式如下详细说明：

‘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)

此表将在 (name, deleted) 和 (flavorid, deleted) 属性上具有唯一约束

‘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 影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

无

其他部署者影响¶

将向部署者提供一个新的 nova-manage 命令，以将风味迁移到 cellsV2 DB API 建议的表。对于任何现有的部署（单元或非单元），都需要运行此命令一次。

开发人员影响¶

无

实现¶

负责人¶

主要负责人: mvineetmenon
其他贡献者: 无

工作项¶

在 API 数据库中创建新的数据库表 ‘flavors’、‘flavor_extra_specs’ 和 ‘flavor_projects’。
修改风味对象以与 API 数据库交互
在 nova-manage 中创建一个新命令，用于将风味从 cellsV1 迁移到 cellsV2

依赖项¶

无

测试¶

由于这被设计为 Nova 的内部重构，没有用户可见的更改，因此当前的 Tempest 或功能测试套件应该足够。

此外，需要编写测试以确保数据模型不会从 cellsV1 模型中使用的模型更改。

这些测试应保留到最终迁移到 cellsV2 为止。

文档影响¶

记录 nova-manage 命令，以将风味从顶级单元数据库迁移到 cellsV2 API-DB。

参考资料¶

https://etherpad.openstack.org/p/kilo-nova-cells

在 API 数据库中添加 Flavor 表