Cinder 配置变更后的动态重新配置¶
https://blueprints.launchpad.net/cinder/+spec/dynamic-reconfiguration/
问题描述¶
目前，每次对 Cinder 配置文件进行更改时，都需要重新启动所有 Cinder 服务才能应用新的配置。在实际环境中，用户不希望在配置的某些方面发生更改时，需要处理服务的关闭和启动。为了保持一致性，能够随着更改动态更新的持续运行的服务，提供了用户与服务交互的更现实的视图。
用例¶
允许开发人员测试新的配置选项，更改选项设置并进行测试，而无需重新启动所有 Cinder 服务。
允许开发人员通过在 cinder.conf 中启用和禁用配置选项来测试驱动程序中实现的新功能，而无需每次选项值从“disabled”更改为“enabled”时都重新启动 Cinder 服务。
允许管理员管理 cinder.conf 中各种后端 IP 地址，并动态更新连接。
提议的变更¶
SIGHUP 方法：管理员将发送 SIGHUP 信号，Cinder 进程会捕获该信号。然后，这些进程将被配置为捕获该信号，排空进行中的操作并重新加载配置文件。 这也将处理驱动程序的重新初始化。但这仍然需要管理员在更改配置文件后采取额外的手动步骤来发送 SIGHUP。这种方法要求部署者更新他们的 sysinit 脚本以支持重新加载进程。总体而言，这是一个更干净的方法，因为所有内容都会关闭，内存会被清理，然后 sysinit 脚本将负责重新加载进程。
注意：所有这些操作都是基于每个主机的；在多节点设置中，需要将信号发送到每个节点。目前在 Active/Active 环境中，这是一个需要调查的重要问题。
备选方案¶
手动方法：继续手动重新启动 Cinder 服务，当 cinder.conf 文件中的设置发生更改时。这是当前的方法，也是我们试图解决的问题。
重新加载和重新启动方法：首先，每个进程都需要完成正在进行的操作。 接下来，数据库和 RPC 连接需要断开，然后所有缓存和所有驱动程序缓存都需要刷新，然后才能重新加载。这种方法增加了大量的复杂性和许多可能导致故障的可能性，因为每个缓存都需要刷新 - 有些东西可能会被遗漏或未正确刷新。
文件观察器：将在 Cinder 进程中添加代码以监视 cinder.conf 文件的更改。 一旦进程检测到已进行更改，该进程将排空并采取必要的措施来重新配置自身，然后自动重新启动。 此功能也可以由配置选项控制，以便如果用户不想启用动态重新配置，他们可以在 cinder.conf 文件中禁用它。这种方法很危险，因为它不会考虑保存到变量中的配置选项。为了解决这些情况，开发人员需要找到并替换所有配置变量的实例，从而破坏部署、配置、工具和打包的许多假设。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
为了编辑 cinder.conf 文件，用户必须具有 root 权限。 因此，没有额外的安全影响。
通知影响¶
需要通知重新加载何时开始和结束。
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
更新 sysinit 脚本以支持新的“cinder-<服务> reload”命令。
开发人员影响¶
使用供应商的驱动程序测试功能，以确保正确的行为。
实现¶
负责人¶
- 主要负责人
kendall-nelson
- 二级分配人
jacob-gregor
工作项¶
实现 SIGHUP 信号处理 - 确保清除缓存 - 更新依赖变量 - 清理断开连接
编写单元测试
在各种驱动程序上进行测试
更新 devref 以描述 SIGHUP/reload 过程
依赖项¶
测试¶
文档影响¶
我们需要更新文档以描述新的功能。
参考资料¶
每周会议记录[1]
[1]http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-03-16-16.01.log.txt
