Cinder Client V2 支持¶
https://blueprints.launchpad.net/nova/+spec/support-cinderclient-v2
Cinder 拥有新的 API 版本 2 [1]。该版本自 Grizzly [2] 以来就已存在，并且自 Havana [3] 以来就在 devstack 中可用。
该 API 提供
更一致的响应，例如 name、description，而不是 ‘display_name’ 等。
在控制器之间缓存数据，而不是多次访问数据库。
在列出卷、快照和备份的信息时进行过滤。Nova 拥有这种支持将会很好，这样 Nova 无需通过网络获取资源的完整列表来进行排序。[4]
Cinder 也在弃用版本 1，转而支持版本 2，因此为用户提供一个过渡期在其他项目中会很有帮助。
问题描述¶
Nova 当前在 nova.volumes.cinder 中拥有一个 Cinder 客户端的封装器，它支持版本 1，并期望各种响应键，例如 ‘display_name’ 和 ‘display_description’，这些键在版本 2 中不可用。这些键已被更改为与其他项目一致，这些项目只使用 ‘name’ 和 ‘description’。
提议的变更¶
Nova 应该使用 Cinder v2 客户端 [5]，它了解如何与 Cinder v2 API 通信。由于 v1 已被弃用，我们可以保留 Cinder 客户端 v1 的支持。
nova.conf 中的 cinder_catalog_info 选项也应设置为 volumev2:cinder:publicURL，这将默认新用户使用 v2 API，该 API 自 Grizzly 以来在 Cinder 中默认启用。
对封装器进行这些更改不会需要任何更改其接口或更改其返回信息的方式。这是通过封装器进行翻译并仍然返回预期的数据结构（就像使用 v1 一样）来实现的。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
现有的部署在 Juno 版本中不需要对 nova.conf 进行任何更改。Cinder 只是会弃用 v1 支持，因此它们会在 cinder-api 服务启动时收到警告。如果部署者希望 Nova 使用 Cinder v2，他们需要将 cinder_catalog_info 更改为使用 Cinder v2 端点在服务目录中设置的适当的 service_type。假设 Cinder 中同时启用了 v1 和 v2，Nova 主机可以使用不同版本的 Cinder API 是可以接受的。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
thingee
- 其他贡献者
dzyu
工作项¶
在 nova.volumes.cinder 中编写更改以支持 Cinder 客户端 v2，同时保留对 v1 的支持。[6]
在 Nova 中添加 Cinder 过滤支持。
依赖项¶
无
测试¶
Tempest gate 测试将针对 Cinder v2 进行测试。Tempest 已经提供了两个版本，因此 Nova 的 cinder_catalog_info 配置选项将被更新为 v2 的适当 service_type。如果资源允许，我们也可以针对 v1 进行测试。
单元测试将针对与 Cinder 客户端通信的 Nova 的封装器进行测试。这将专门验证 v1 和 v2 之间的使用在此层处理，并且对 Nova 的其余部分是透明的。
文档影响¶
无
参考资料¶
[1] - https://docs.openstack.org/api/openstack-block-storage/2.0/content/ [2] - https://review.openstack.org/#/q/status:merged+project:openstack/cinder+branch:master+topic:bp/bp,n,z [3] - https://review.openstack.org/#/c/22489/ [4] - https://github.com/openstack/cinder/commit/88e688317dc4066f2f0b4dfc454a3f049da4d0e3 [5] - https://github.com/openstack/python-cinderclient/tree/master/cinderclient/v2 [6] - https://review.openstack.org/#/c/43986/
