NovaV3API

Launchpad 条目: NovaSpec:nova-v3-api
创建时间: 2012年11月02日
贡献者: Sean Dague

总结

Nova v2 API 存在许多不一致之处，包括错误码不一致（200 与 202 返回值）、格式不一致（时间戳有多种格式）、错误和直接缺失的功能，我们假设用户拥有直接访问数据库的工具。我们将创建一个 v3 API，重点是清理这些更改，并升级一些关键扩展。

发布说明

将有一个新的 v3 API，v2 API 将被弃用，但将在 v3 的首次发布中仍然受支持。

原理

在 Folsom 发布周期中，API 中一些看似微小的更改，例如将成功值从 200 更改为 202，导致 Tempest 出现故障。现在我们已经在 Tempest 中拥有大量的 API 覆盖，很明显，为了清晰和一致性而进行的微小更改无法在稳定的 API 中修复。然而，这些问题中的许多是在 Folsom RC 结束时出现的。单独来看，每个问题都容易被忽略，但总体而言，它们会在 API 结构中造成很大的困惑。为了长期采用，这些问题应该得到解决，并且应该制定指南，以确保所有被接受到 OpenStack 的扩展都遵循相同的指南。

这将也为我们提供一个机会，与整体努力保持一致，以使分页和排序在 OpenStack 项目中保持一致，从而使外部 API 消费者能够使用这些 API 变得可行且合理。

还有一些希望推广少量广泛启用的核心扩展。

用户故事

前提条件

在发布 v3 API 时，v2 API 将被弃用，但根据我们的弃用标准，至少在下一个主要版本中不会将其删除。

设计

实现

实施过程必须分几个离散的步骤进行

v2 API 审计和最佳实践指南

第一步是对现有的 v2 API 进行系统审计，寻找正确的模式，确定在 nova 代码中 API 编写的最佳状态码和用法。

在流程文档中标记需要更改的错误，使用以下标签

nova-v2-bug - API 的直接问题。例如，删除不存在的资源返回 200 而不是 404
nova-v2-non-best-practice - 最佳实践未被遵循的问题。API 使用 200 而应该使用 202。API 使用非标准时间格式。API 使用错误返回类型。还应在此处评估有关排序和排序的最佳实践。
nova-v2-hole - API 存在于设置对象，但无法获取它。或者可以获取对象但无法设置它。

带有这些标签的错误，如果无法在 v2 API 中修复，则应拒绝针对它们的审查，直到 v3 API 开通。

v2 扩展升级和版本控制

应考虑升级一小部分扩展。这不是一次免费的活动。这应该与 v2 审计同时进行。

此外，需要考虑扩展版本控制，因为某些扩展需要更改以支持最佳实践。

v3 API 开通

完成扫描后，确定要升级的扩展，开通 v3 API 树。复制 v2 API，并通过错误队列进行大规模推动，以解决不一致之处。

Tempest 的工作需要与 nova 在 v3 中的更改并行进行。

Nova v2 修复

Nova v3 建议内容

降级接口

服务器上的属性

admin_password
personalities

升级接口