向 create_export 调用中添加连接器对象¶
https://blueprints.launchpad.net/cinder/+spec/add-create-export-connector
目前 Cinder 中有相当数量的卷驱动程序使用 initialize_connection 来完成将卷作为目标导出到发起方（nova 计算主机）的工作。 驱动程序这样做的一个原因是 create_export 方法 API 中没有传递连接器对象。 本规范概述了将连接器对象添加到标准卷驱动程序 API 的 create_export 中。
问题描述¶
今天 Cinder 中有许多驱动程序在 initialize_connection 内部执行卷目标导出，而不是在 create_export 方法中。 这其中的一个原因是，对这两种方法之间的区别存在文档化的理解。 阻止驱动程序在 create_export 内部执行工作的另一个问题是，create_export 缺少来自发起方的连接器对象。 一些后端需要连接器对象，其中包含发起方信息，才能从其阵列导出目标。 因此，驱动程序最终将所有导出代码移动到 initialize_connection 中，因为这是唯一具有连接器对象驱动程序调用的方法。
Cinder 驱动程序在 initialize_connection 中执行卷目标导出的另一个问题是，Nova 在其他不涉及附加卷的过程（例如实时迁移）期间会重复调用 initialize_connection。 Nova 将调用驱动程序的 initialize_connection，只是为了获取已导出卷的 connection_information，而不是因为它想要附加卷。
用例¶
主要用例是附加卷。 当有人调用 Cinder 附加卷时，最终会调用卷管理器的 initialize_connection 方法。 卷管理器的 initialize_connection 方法首先调用 create_export，目的是要求驱动程序创建从阵列导出到发起方的目标。 然后卷管理器调用驱动程序的 initialize_connection 以获取目标信息，以传回给调用者，以发现显示的卷。
提议的变更¶
拟议的更改很简单。 将已经存在的连接器对象添加到对 create_export 的调用中。 这使得连接器对象在 create_export 时间对所有驱动程序普遍可用。 然后，每个维护者都可以逐步更改每个驱动程序，以在 create_export 时间执行目标导出，而不是在 initialize_connection 时间执行。
备选方案¶
我们可以什么都不做，并要求每个驱动程序维护者在 initialize_connection 内部执行任何创建导出的操作时更加小心，如果它们已经存在的话。 这基本上使 create_export 对于所有这些驱动程序来说都是无用的和空操作。 我更希望每个驱动程序都按其预期的方式使用每个方法，以便更一致地审查所有 Cinder 中的驱动程序。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
如果驱动程序开发人员将创建导出的操作移动到 create_export 中，那么对 initialize_connection 的任何调用都应该更快，具体取决于驱动程序。
其他部署者影响¶
无
开发人员影响¶
一旦连接器对象在 create_export 内部可用，驱动程序就可以将现有的导出创建代码从 initialize_connection 迁移到 create_export。 审查人员还应在现有和未来的审查中寻找这一点，并且不应批准忽略 create_export 的驱动程序。
实现¶
负责人¶
- 主要负责人
walter-boring
工作项¶
首先是更新基础 driver.py 的 create_export 方法。 然后，每个定义 create_export 的其他驱动程序都必须接受新的连接器对象。
然后，卷管理器对 create_export 的调用需要传递连接器。
依赖项¶
无
测试¶
所有单元测试都需要更新，以注意新的连接器对象参数。 驱动程序的单元测试也需要更新。
文档影响¶
无
参考资料¶
由于尝试使 Nova 实时迁移与 cinder 卷一起工作所做的努力，已经进行了大量的研究。 存在一个 etherpad，讨论了 Nova、Cinder 交互的已知问题。 该 etherpad 还列出了由于在 initialize_connection 内部创建导出而可能存在问题的 Cinder 驱动程序。
