可配置的持久化和有状态数据目录¶
https://blueprints.launchpad.net/tripleo/+spec/tripleo-juno-configurable-mnt-state
将有状态数据硬编码的 /mnt/state 路径设为可配置。
问题描述¶
1. 为持久化数据硬编码的 /mnt/state 目录与基于 Red Hat 的发行版可用的有状态数据路径机制不兼容。基于 Red Hat 的发行版，例如 Fedora、RHEL 和 CentOS，具有使用绑定挂载将路径挂载到有状态数据分区的功能，而无需手动重新配置软件以使用 /mnt/state。
2. 使用 SELinux 的发行版具有允许访问特定路径的预先存在的策略。将这些路径重新配置到 /mnt/state 下，会导致现有服务的 SELinux 拒绝，需要编写和维护额外的策略。
3. 一些操作员和管理员认为重新配置许多服务以不使用文件系统路径的常用默认值会造成破坏性和不一致性。在使用他们已经了解并期望某些配置的发行版时，他们不会期望这些更改。这些类型的更改还需要更改现有文档和流程的文档。
提议的变更¶
部署者将能够选择一个可配置的路径，而不是有状态路径的硬编码值 /mnt/state。
将添加一个新的元素，stateful-path，用于定义有状态路径的值。默认值将为 /mnt/state。
有 3 个区域需要尊重可配置的路径
- os-apply-config 模板生成
stateful-path 元素将通过将 JSON 文件安装到 os-collect-config 用作本地数据源的已知位置来设置有状态路径值。这将需要向 os-collect-config 添加一个新的本地数据源收集器（参见 依赖项）。
JSON 文件的内容将基于 $STATEFUL_PATH，例如：
{‘stateful-path’: ‘/mnt/state’}
文件模板（os-apply-config 中的元素下的文件）然后将更新，以将硬编码的 /mnt/state 替换为 {{stateful-path}}。
目前，os-apply-config 模板的根位置混合在一起。大多数都写入在 / 下，而有些则写入在 /mnt/state 下。/mnt/state 在这些元素中的 os-apply-config 目录树中是硬编码的，因此这将被删除，以便模板仅写入在 / 下。可以在这些元素中使用符号链接来设置正确的路径。还可以向 os-apply-config 的控制文件机制添加支持，以指示这些文件应写入有状态路径下。一个执行此操作的示例补丁位于：https://review.openstack.org/#/c/113651/
- os-refresh-config 脚本在启动时运行
为了使有状态路径可配置，os-refresh-config 脚本中所有硬编码的 /mnt/state 引用都将被替换为环境变量 $STATEFUL_PATH。
stateful-path 元素将为 os-refresh-config 提供一个 environment.d 脚本，该脚本从 os-apply-config 读取该值
export STATEFUL_PATH=$(os-apply-config –key stateful-path –type raw)
- 在镜像构建时运行的 Hook 脚本
stateful-path 元素将为在镜像构建时使用提供一个 environment.d 脚本
export STATEFUL_PATH=${STATEFUL_PATH:-“/mnt/state”}
use-ephemeral 元素将依赖于 stateful-path 元素，从而有效地使默认有状态路径保持为 /mnt/state。
可以通过在镜像构建之前在环境中定义 $STATEFUL_PATH，或者在运行早于 stateful-path environment.d 脚本的环境.d 脚本的元素中来重新配置有状态路径。
替代方案¶
目前没有想到，此规范的目的是启用现有替代方案。可能还有其他替代方案，其他人可能希望添加支持。
安全影响¶
无
其他最终用户影响¶
最终用户使用更改有状态路径位置的元素，从 /mnt/state 到其他位置，将在配置文件和用于持久化和有状态数据的目录中看到此更改。他们需要知道如何配置和访问有状态路径。
如果使用配置有状态路径不同的元素，不同的 TripleO 安装看起来会不同。
这也会增加阅读 TripleO 代码的复杂性，因为与其存在显式路径，不如存在对可配置值的引用。
性能影响¶
os-refresh-config 中将会有额外的逻辑来确定和设置有状态路径，以及 os-collect-config 将使用的额外本地收集器。但是，这些对性能的负面影响可以忽略不计。
其他部署者影响¶
部署者将能够选择可能重新配置有状态路径或更改 $STATEFUL_PATH 值的不同元素。但是，默认值将保持不变。
部署者需要知道有状态路径是什么，如果它在他们的环境中不同，这可能会令人困惑。但是，这似乎不太可能，因为部署者可能会标准化为一组常见的元素、发行版等。
将来，如果基于 Red Hat 发行版的 TripleO CI 和 CD 云使用此功能来启用 Red Hat 只读根支持，那么这些云的配置将与配置为使用 /mnt/state 的云不同。作为一个团队，tripleo-cd-admins 需要知道使用了哪种配置。
开发人员影响¶
1. 开发人员需要在打算引用有状态路径时使用 $STATEFUL_PATH 和 {{stateful-path}} 替换。
2. 需要知道有状态路径的代码需要访问定义路径的变量，它将无法假定路径为 /mnt/state。可以调用 os-apply-config 来查询定义路径的键，只要 os-collect-config 至少运行过一次即可。
实现¶
负责人¶
- 主要负责人
james-slagle
工作项¶
tripleo-incubator¶
更新故障排除文档，提及 /mnt/state 是一个可配置的路径，并且在本地环境中可能不同。
tripleo-image-elements¶
添加一个新的 stateful-path 元素，该元素将 stateful-path 和 $STATEFUL_PATH 配置为 /mnt/state
更新 os-apply-config 模板，将 /mnt/state 替换为 {{stateful-path}}
更新 os-refresh-config 脚本，将 /mnt/state 替换为 $STATEFUL_PATH
更新所有在 /mnt/state 下具有 os-apply-config 模板文件的元素，仅放在 / 下。
更新 os-apply-config 元素，以使用 –root $STATEFUL_PATH 选项调用 os-apply-config
更新具有到 os-apply-config 生成文件的路径的元素（例如 /etc/nova/nova.conf），将这些路径引用为 $STATEFUL_PATH/path/to/file。
使 use-ephemeral 元素依赖于 stateful-path 元素
依赖项¶
os-collect-config 需要一个新的功能来从元素可以安装 JSON 文件的本地数据源目录读取，例如 source.d。将为此功能提交一个新的规范。 https://review.openstack.org/#/c/100965/
os-apply-config 需要在其控制文件中添加一个选项，以支持在可配置的有状态路径下生成模板。这里有一个补丁：https://review.openstack.org/#/c/113651/
测试¶
目前没有测试来验证所有有状态和持久化数据是否实际写入有状态分区。
我们应该添加 tempest 测试，以直接行使 preserve_ephemeral 选项，并进行测试以检查所有有状态数据是否在“nova rebuild”之后得到保留。Tempest 似乎是添加这些测试的合理位置，因为 preserve_ephemeral 是 Nova OpenStack 功能。此外，一旦 TripleO CI 在部署的 OverCloud 上运行 tempest，我们将测试此功能。
我们还应该在 TripleO CI 中测试重建过程中是否保留状态，方法是在重建之前添加有状态数据，并在重建后验证它是否仍然存在。
文档影响¶
我们将记录新的 stateful-path 元素。
TripleO 文档需要提及如果使用其他于 /mnt/state 的值，配置文件和持久化数据的位置可能存在差异。
参考资料¶
os-collect-config 本地数据源收集器规范
这将启用 Red Hat 样式的有状态分区支持
