为 os-brick 添加 API 以允许扩展附加卷¶
https://blueprints.launchpad.net/cinder/+spec/brick-extend-attached-volume
为 os-brick 连接器对象添加 extend_volume API，以允许更新宿主机内核大小信息，用于附加卷。
问题描述¶
目前，Cinder 具有扩展未附加卷的能力。不幸的是，这对于附加卷不起作用，因为附加卷的宿主机内核无法看到新的大小，除非在宿主机上采取行动。Linux 内核不会自动看到远程存储服务器上的大小变化。本规范概述了在附加卷扩展大小时，在宿主机服务器上执行这些所需操作的想法。
用例¶
OpenStack 用户有一个 Cinder 卷附加到宿主机/虚拟机，他们希望在附加状态下扩展/增大该卷。
提议的变更¶
添加一个新的 os-brick 连接器 API，名为“extend_volume”，该 API 在宿主机上执行工作以更新卷的大小。 这还需要考虑原始设备和多路径设备（如果可用）。 它将返回调整大小完成后卷的大小，如果失败则返回 None。
本规范不涵盖 Cinder 和 Nova 完成解决方案所需的工作。 本规范仅涵盖 os-brick 所需的工作，以确保附加到 nova 计算主机的卷可以更新其宿主机内核以查看卷的新大小。 Cinder 必须进行更改，以允许扩展附加卷，并在完成后调用新的 Nova API，以启动计算主机上的工作。 然后 Nova 必须在 virt 中发出 blockresize 命令，以调整虚拟机虚拟设备的大小。 对于 RBD 等卷类型，Nova 不使用 os-brick 作为管理卷的库，Nova 必须自行执行发出命令以扩展卷的工作。
备选方案¶
不幸的是，如果卷附加到虚拟机，最终用户无法做任何事情，因为 Nova 计算主机内核必须在虚拟机看到新大小之前看到更改。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
拥有虚拟机的最终用户可能需要发出文件系统调整大小命令，以使卷上的本机文件系统识别新的卷大小。 对于 ext* 风格的文件系统，用户可以使用 resize2fs。
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
walter-boring
工作项¶
将新的 API 添加到基础 Connector 类，然后在 linuxscsi.py 中添加通用的必需代码来执行实际工作。
依赖项¶
为了让 OpenStack 最终用户使用它，Cinder 必须选择性地允许扩展附加卷。
还需要进行一些 Nova 工作，以启动对 os-brick 新 API 的调用以执行工作，然后在成功后通知虚拟机。
测试¶
在端到端 Cinder -> Nova 功能到位之前，无法自动测试此功能。 目前，这是一个手动过程。
文档影响¶
此更改对文档团队有什么影响？有些更改可能需要向文档团队捐赠资源以更新文档。不要重复上面讨论的细节，但请在此处引用它们。
参考资料¶
一个相关的 cinder-spec 已经在这里发布了一段时间
有关如何手动执行通知宿主机内核的工作的相关信息
