在 SIGHUP 信号上重新加载配置文件¶
https://blueprints.launchpad.net/glance/+spec/sighup-conf-reload
我们建议消除在修改配置文件时重启 glance api 服务的必要性。操作员可以向 glance 服务发送 SIGHUP 信号，这将重新加载配置文件。
问题描述¶
在生产环境中，管理员会在存储空间即将耗尽时修改 glance-api.conf 配置文件参数，例如 filesystem_store_datadirs，以通过添加更多磁盘来增加容量，或者增加工作线程数量或日志配置等。然后他们需要显式地重启 glance 服务才能加载这些更改。重启服务会中断与其连接的用户，这对用户来说是不好的。
提议的变更¶
添加在不影响服务的情况下动态更改正在运行的 glance 服务器配置设置的能力。
正在运行的 glance 服务器由一个父进程和一个或多个子进程组成。
收到 SIGHUP 信号后，父进程将
重新加载配置
向原始子进程发送 SIGHUP 信号
使用新配置启动新的子进程
其监听套接字不会被关闭
收到 SIGHUP 信号后，每个原始子进程将
关闭监听套接字，以免接受新的请求
完成任何正在处理中的请求
退出
这种方法基于 nginx 的行为，并避免了当前 oslo’s Launcher 重新加载的一些缺点
竞争条件：Launcher 无法干净地关闭 eventlet，现有的请求可能会失败。
如果所有子进程都很忙，当新的请求未被处理时可能会有较长的延迟。
长期存在的预 SIGHUP 空闲客户端连接可能会无限期地阻塞请求处理。
并非所有参数都可以更改，例如工作线程数量。
无法更改 wsgi 管道，例如启用缓存。
备选方案¶
另一种方法可能是尝试使用 taskflow 保存然后恢复长期运行的任务。然后进程重启只需要处理短期的请求（例如 API DB 查询），并且不需要对常规重启进行用户可见的停机时间
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
如果重新加载花费的时间过长（例如，>50ms），那么 API 请求将会明显延迟。
我们建议当前的 worker 进程停止接受请求并继续执行它们正在做的事情，而父进程启动并生成具有新配置的新子进程。因此，有可能 glance 节点将运行两倍于其配置运行的子进程数量一段时间。这可能会影响性能，特别是如果它是一个配置为运行尽可能多的子进程而没有性能下降的低配置节点。
作者认为，操作员有责任确保节点不会因子进程（worker）而过度配置。如果操作员想要运行一个没有额外子进程容量的节点，作者建议该操作员不要通过 SIGHUP 使用动态配置。相反，该操作员应该使用老式的重启 api 服务技术。
其他部署者影响¶
需要记录某些参数（如 workers、host、port 等）的配置更改的影响。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
stuart-mclaren
- 其他贡献者
abhishek-kekane
评审人员¶
- 核心评审人
nikhil-komawar flaper87
- 其他审核员
icordasc
工作项¶
添加 SIGHUP 信号处理程序
重新加载配置文件参数
单元和功能测试以覆盖
依赖项¶
无
测试¶
无
文档影响¶
请参考 其他部署器影响
