移除 API 端点中的 project_id 要求¶

https://blueprints.launchpad.net/cinder/+spec/project-id-optional-in-urls

问题描述¶

目前 Cinder 假定 API URL 包含关联的 project_id。在 URL 中包含 project_id 是多余的，因为 project_id 通常可在 API 请求的 keystone 上下文中获得。此外，要求 project_id 与 keystone 的系统范围概念不兼容，在这种概念中，API 不与特定项目关联。系统范围的 API 请求将没有 project_id，因此这些请求的 URL 不应包含 project_id。

此外，Cinder 在其 API URL 中包含 project_id 与其他 OpenStack 服务不同步。Images (glance API v2)、Compute (nova API 截至 v2.16)、Identity (keystone API v3) 和 Shared File Systems (manila API 截至 v2.60) 服务在其 API URL 中都不需要 project_id。

用例¶

云管理员希望利用 keystone personas，以便为分配到不同角色的用户授予适当的访问权限，例如实验室操作员和项目管理员。实验室人员通常需要管理系统范围的 Cinder 资源，例如存储后端和卷类型。但是，这些人员不应有权访问特定于项目的资源，例如 Cinder 卷。同样，项目管理员需要能够管理他们负责的项目拥有的资源，但应限制对系统范围资源的访问，例如配置卷类型的权限。

为了支持系统范围的 personas，API 请求的 URL 不应要求包含 project_id。

提议的变更¶

本规范建议增强 Cinder API，使其不再要求在 API 的 URL 中包含 project_id。在 URL 中包含 project_id 将是可选的，这意味着提议的更改保留了向后兼容性。将引入一个新的 microversion，以便客户端可以知道在 API URL 中包含 project_id 是可选的还是强制的。

microversion 将仅用作指示 API 可以处理没有 project ID 的 URL 的指标，并且这适用于所有请求，无论请求中的 microversion 如何。例如，如果新的提议 microversion 是 v3.67，则提供 v3.67 或更高版本的 API 节点将正确路由没有 project_id 的请求，即使您请求 v3.0。同样，它将正确路由包含 project_id 的 URL 的请求，即使您请求 v3.67。

该提议不会对 API 引入任何行为或功能上的更改。无论 URL 是否包含 project_id，将调用相同的 API 方法，并且与调用关联的实际 project_id 将是 API 请求的 keystone 上下文中包含的 project_id。如果请求 URL 包含与 keystone 上下文中的 project_id 不匹配的 project_id，则当前行为将保留，即返回 HTTP 400。

备选方案¶

可以定义一个虚拟的 project_id 值（也许全部为零），供系统范围的 API 请求使用。这不是一个优雅的解决方案，并且需要对 keystone 进行更改。

可以要求云管理员创建一个实际的项目，仅用于在发出系统范围的 API 请求时使用。这也不是一个优雅的解决方案，而是将管理系统范围的负担转移到云管理员身上。

数据模型影响¶

无

REST API 影响¶

每个 API 方法的行为将保持不变。但是，API 路由将得到增强，以向每个方法提供重复的路由。

现有的路由，其中 URL 中包含 project_id
一个新的路由，当 URL 不包含 project_id 时

安全影响¶

没有安全影响，因为 keystone 将继续为每个 API 请求提供授权上下文，无论请求 URL 是否包含 project_id。

Active/Active HA 影响¶

无

通知影响¶

无

其他最终用户影响¶

最终用户通常通过其他客户端（例如 python-cinderclient、python-openstackclient 或 openstacksdk）与 Cinder API 交互。在这种情况下，对最终用户没有直接影响。

直接使用诸如 curl 之类的工具与 API 交互的最终用户可以继续在 URL 中包含 project_id。他们可以选择不在 URL 中包含 project_id。

性能影响¶

无

其他部署者影响¶

部署工具，这些工具在 keystone 目录中创建 Cinder 端点，不再需要使用 project_id 模板。目录中的端点应如下所示

$ openstack endpoint list --service cinderv3 -c 'Service Name' -c URL
+--------------+---------------------------------+
| Service Name | URL                             |
+--------------+---------------------------------+
| cinderv3     | http://192.168.100.30/volume/v3 |
+--------------+---------------------------------+

而不是这样

$ openstack endpoint list --service cinderv3 -c 'Service Name' -c URL
+--------------+------------------------------------------------+
| Service Name | URL                                            |
+--------------+------------------------------------------------+
| cinderv3     | http://192.168.100.30/volume/v3/$(project_id)s |
+--------------+------------------------------------------------+

开发人员影响¶

无

实现¶

负责人¶

主要负责人：abishop

工作项¶

定义一个新的 microversion
添加 API 路由，以将 URL 中没有 project_id 的 API 请求连接到关联的方法
添加或增强单元测试
更新 devstack，以便 Cinder 端点不使用 project_id 模板

依赖项¶

无

测试¶

现有的 tempest 测试肯定会验证 API 是否正常工作。挑战在于验证遗留行为（其中 URL 包含 project_id）和新行为（当 URL 不包含 project_id 时）。一种可能性是使用一个周期性的 zuul 作业，专门测试遗留行为。详细信息可以在开发阶段中确定。

文档影响¶

现有的 API 参考基本不受影响。这是因为参考指南是未分叉的，并且旧版本的 Cinder 需要 project_id。将在 API 参考中添加一个简短的注释，说明从新的 microversion 开始，project_id 是可选的。

参考资料¶

OpenStack 的支持通用操作员和最终用户 personas 社区目标
Cinder 的安全 RBAC Ready 规范

移除 API 端点中的 project_id 要求