PTG直击｜Cinder项目重要变化纪要

由OpenStack基金会举办的 Project Teams Gathering（以下简称 PTG ）会议已于9月11-15日在 Denver 举行，共计420名开发者参加，踊跃讨论有关 OpenStack 下一个版本 Queens cycle 的开发工作，积极推动OpenStack各项能力的提升，甚至许多开发工作也在 PTG 过程中实际展开。

Cinder 是 OpenStack Block Storage 的项目名称，它为虚拟机 （VM） 提供了持久块存储。对于可扩展的文件系统、最大性能、与企业存储服务的集成以及需要访问原生块级存储的应用程序而言，块存储通常是必需的。它类似于 Amazon 的 EBS 块存储服务，OpenStack 中的实例是不能持久化的，需要挂载 volume，在 volume 中实现持久化。Cinder 就是提供对 volume 实际需要的存储块单元的实现管理功能。

本次 PTG 为期5天，在 PTG 举办期间，OpenStack基金会组织了 Cinder sessions 进行讨论与现场开发。Cinder sessions 是从13日到15日，包括不少重要项目改进和重要功能热点，有些话题是从巴塞罗那峰会遗留下来的。

EasyStack派出多名工程师参与了本届PTG，其中EasyStack研发工程师Apolloliuhx参与了 Cinder sessions。

以下是来自Apolloliuhx带来的会议纪要：

笔者第一次参加 PTG，所以不能与之前的会议进行比较，但总的来说感觉这是一次较为成功的会议。

以下涉及的所有讨论详见：https://etherpad.openstack.org/p/cinder-ptg-queens

Day 1

1.Replication Failback

比较让人激动的一个 feature ，将实现完整的容灾恢复功能。之前 Cinder 项目的一些驱动已经支持 failover api，但是 failover 之后实现 failback 是尚未实现完成，因此 PTG 会议上重点讨论了该问题。Failback 之后可能原来的 primary system 就不再是原来的系统，但很难跟用户解释实现这个得有多困难，比如RBD可以实现这个功能，但其他 Drivers 呢？这些 Drivers 有很多需要考虑的问题。

这是一个怎么样的过程呢？用简短的话来说就是：从 primary cluster failover 到secondary cluster，promote 这个集群到 primary 让其正常运行，这个过程中需要添加一个状态“ promoting ”，这样我们可以看到整个 promotion 过程，并且可以看到这个过程需要很长时间完成，完成之后状态会修改为“ replicated ”。现在对于 replication 这个功能并未完成，因此用户没有使用。Cinder team 在此次PTG 会议上重点讨论了该功能，不过需要进一步讨论，不光得考虑对其他 drivers 的影响，还有 active/active HA 影响。

BP链接：

https://blueprints.launchpad.net/cinder/+spec/replication-backend-promotion

2.Micro version设置constraints

为 micro vision 设置 constants 。为了避免 rebase 的时候起冲突，比较好的方式是给 micro vision 设置 constants ，比如 GROUP_REPLICATION=3.35，这样在之后使用到改版本的功能代码会比较方便的直接 rebase 。

3.最小功能集文档化

Cinder 准备对每个 divers 进行文档化归类，并指出某些 driver 不提供某个功能或者某个值。

Cinder为每个driver实现基本的功能，包括：

Volume Create/Delete

Volume Attach/Detach

Snapshot Create/Delete

Create Volume from Snapshot

Get Volume Stats

Copy Image to Volume

Copy Volume to Image

Clone Volume

Extend Volume

每个driver为scheduler服务提供调度的状态值

driver_version

free_capacity_gb

storage_protocol

total_capacity_gb

vendor_name

volume_backend_name

4.自动配置项生成

为方便直接生成配置项文件，cinder使用oslo库来实现新的配置项生成。Oslo config and oslo policy 提供了sphinxconfiggen and sphinxpolicygen 插件来使用产生ini格式的文档，还有 sphinxext plugins可以生成漂亮的表格格式的文档，利用这些工具来提取 cinder 项目所有配置项，最终生成配置项文档。

5.浓缩/标准化基本配置项集合

很多 drivers 的配置项是一样的或者说是重复的，比如 SAN 驱动的很多选项其他一些 driver 可以共用，需要浓缩一下配置项集合，弃用那些多余的部分。对于弃用某个配置项， nova 的做法是在选项中加入信息说明该选项已经弃用，请用新的选项代替，保证至少一个版本以上才可考虑删除，每次弃用或者删除都要加入 releasenote ，并且写入相应的驱动文档。

Day 2 & Day 3

以下是 Cinder 第二天和第三天的会议纪要，其中 1、2、3 是 Nova 和 cinder 跨项目综合讨论。

1.Multi-attach

这个无疑是本次PTG跨项目 （ nova/cinder ） 讨论里的重头戏。Cinder 项目为了支持 multi-attach 功能将引入新的 attach/detach api 。启用该功能的主要的问题是怎么处理共享连接。Nova 调用 create_attachment（没有 connector ），cinder 的配置项 is_using_shareable_backend_connection_thingy 设置为True；如果 is_using_shareable_backend_connection_thingy 设置为 True，nova 调用 delete_attachment（有 connector ）时会有一个 host 锁，这个锁将影响所有和挂载有关系的操作，比如 create_attachment 。从 Policy 控制的角度，通过 nova 的 policy 可以允许 multi-attach 从 volume 启动虚机，通过 cinder 的 policy ，cinder 需要后端允许的前提下才能实现 multi-attach ，并且只允许 read-only 的卷 multi-attach 。能否从一个 multi-attach 卷起虚机，还需要看操作系统是否能实现。os-brick 实现 host 的共享连接，必须提的是锁只用在使用了共享连接的 host 上，且基于 IQN 。最后还讨论了升级连接调用的问题，针对旧的 attachment 升级，但是具体尚无结论。

<p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; padding: 0px; word-wrap: break-word; color: rgb(89, 87, 87); font-family: "Microsoft Yahei", "Hiragino Sans GB", "WenQuanYi Micro Hei", sans-serif; white-space: normal; back