控制平面服务组基础重构¶
https://blueprints.launchpad.net/nova/+spec/servicegroup-api-control-plane
目前，有多种接口可以用来操作服务数据——管理界面 (nova-manage)、扩展 (contrib/services.py) 和服务组 API 层。使用不同的接口来操作事实来源可能会导致 nova.services 中存储的有用数据出现严重的不一致。该提案是遵循一个通用路径，通过上述三个接口中的任何一个与服务数据交互。该通用路径将通过服务组 API 层，其主要目的是管理和检查服务存活状态。这样做将有助于克服 nova 与 services 表之间的紧耦合，并获得一致的服务数据视图、服务存活状态等。
问题描述¶
1. nova 与 nova.services 表之间存在紧耦合。在决定运行在特定主机上的服务的存活状态之前，nova 会参考 services 表，该表被认为是事实来源。
2. 目前有 3 个接口，即管理界面 (nova-manage)、扩展和服务组 API 层，可以从中访问或修改服务信息。
3. 数据库服务组驱动程序是大多数部署使用的主要驱动程序。但是，对于使用 Zookeeper 或 Memcache 服务组驱动程序的部署，由于我们有 3 个不同的接口来修改存储在 nova db 中的关键服务信息，最终会导致严重的数据不一致。
4. 没有提供抽象来选择不同的后端来存储服务数据。它与数据库作为后端紧密耦合，并存储在 nova.services 表中。在 Nova 引入对象之前，服务数据是通过 sqlalchemy 层进行数据库查询来获取的。即使在实现对象层之后，数据也是从数据库获取的。访问数据的手段发生了变化，但服务数据存储的位置没有改变。这在 https://review.openstack.org/#/c/138607/ 中有更详细的介绍。此规格的范围仅限于访问和获取服务数据和通过强制所有接口通过服务组 api 层来获取服务存活状态信息的调用。
用例¶
1. 使用 Zookeeper 服务组驱动程序来管理服务存活状态的部署：在这种情况下，即使使用 Zookeeper 服务组驱动程序来管理服务和报告服务存活状态，管理界面 (nova-mange) 和扩展接口（它们作用于 nova.services 表，并将该表视为服务信息的真实来源）也可能导致严重的数据不一致。
2. 操作员使用管理界面 nova-manage service disable 来标记服务为关闭状态。Zookeeper 不会意识到此更改，仍然认为服务正在运行。因此，nova-manage 仅使用数据库作为底层后端。管理界面使用服务组层来检查服务存活状态，但随后进行数据库查询以获取服务列表。这与服务组驱动程序 API ‘get_all’ 视图在启用/禁用方面不一致。
3. 使用 Nova service delete (REST api) 的操作员似乎遵循了上述类似的损坏模式，并且仅使用数据库作为底层后端。此实现也与服务组驱动程序 API ‘get_all’ 视图的服务数据不一致。
项目优先级¶
无
提议的变更¶
1. 提议的更改是强制所有对服务数据的更改都通过服务组 API。
2. 修复代码中所有通过查询/修改 nova.services 来访问/修改服务数据的地方，nova 代码库中有很多地方都在这样做。
3. 如果服务信息存储在数据库中，所有接口都将通过服务组 API 层。将向服务组 API 添加新接口来处理这些更改。例如，需要添加 update() 调用，以便管理界面可以使用 nova-manage 更改服务状态，最终将通过服务组 API update()。
4. 如果服务信息存储在 Zookeeper 或 Memcache 中，所有访问/修改服务数据、服务存活状态信息的接口都将通过服务组 API。Zookeeper ephemeral znode 如何维护服务表示状态以及如何从现有的数据库服务组驱动程序迁移到 zookeeper 服务组驱动程序的详细信息在 https://review.openstack.org/#/c/138607 中有介绍。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
1. 为了获取服务详细信息，如服务信息、服务存活状态，调用应通过服务组 API，而不是直接通过 sqlalchemy 层和数据库或使用服务对象来获取信息。
实现¶
负责人¶
- 主要负责人
vilobhmm
- 其他贡献者
jaypipes, harlowja
工作项¶
修复管理界面 nova-manage，使其使用服务组 API，而不是直接查询数据库。
修复 REST API 扩展，用于 os-hosts、os-hypervisors、os-services 和 os-availability-zones，使其使用服务组 API。所有这些都使用对 objects.ServiceList 或 host_api.service_get_all 的直接调用（该调用被硬编码为使用 objects.ServiceList.get_all，它查询数据库 services 表，并且实际上根本没有命中服务组 API）。
依赖项¶
无
测试¶
如果需要，将添加单元测试。
将更新现有的单元测试，以确保使用服务组 API 访问/更新服务数据。
文档影响¶
无
