默认部署整个磁盘镜像¶

https://blueprints.launchpad.net/tripleo/+spec/whole-disk-default

此蓝图跟踪切换到默认使用整个磁盘的 overcloud 镜像所需的任务，而不是当前的分区 overcloud-full 镜像。

整个磁盘镜像与分区镜像¶

当前的 overcloud-full 分区镜像由以下内容组成

一个压缩的 qcow2 镜像文件，其中包含一个根分区，包含所有镜像内容
用于内核启动的内核镜像文件
与内核一起启动的 ramdisk 文件

而 overcloud-hardened-uefi-full 整个磁盘镜像由一个包含以下内容的单个压缩 qcow2 镜像组成

包含 UEFI 启动、传统启动和根分区的分区布局
根分区包含一个单独的 lvm 组，其中包含多个不同大小的逻辑卷，这些逻辑卷挂载在 /、/tmp、/var、/var/log 等处。

部署分区镜像时，ironic-python-agent 会在正在部署的裸机磁盘上执行以下操作

在磁盘上创建启动和根分区
将分区镜像内容复制到根分区
用启动所需的一切（包括内核镜像、ramdisk 文件、生成的 grub 配置和安装的 grub 二进制文件）填充空的启动分区

部署整个磁盘镜像时，ironic-python-agent 只是将整个镜像复制到磁盘。

当分区镜像部署启动时，根分区会增长以占用所有可用磁盘空间。此机制由基础云镜像提供。对于多卷 LVM 整个磁盘镜像，没有等效的分区增长机制。

问题描述¶

构建和部署整个磁盘 overcloud 镜像的功能已经可用了许多版本，但现在是时候将其切换为默认设置了。这样做将避免以下问题并带来以下好处

从 CentOS-8.4 开始，grub 将停止支持在 UEFI 系统上安装引导加载程序。ironic-python-agent 依赖于 grub 安装来使用分区镜像设置 EFI 启动，因此当使用 CentOS 8.4 时，UEFI 启动将停止工作。
除了这种新的 grub 行为之外，在 ironic-python-agent 中保持分区启动工作一直是一项开发负担，并且涉及避免了整个磁盘部署的复杂代码。
TripleO 用户越来越多地希望使用启用了 UEFI 安全启动的部署，这仅在使用带有签名 shim 引导加载程序的整个磁盘镜像时才有可能。
分区镜像需要与内核和 ramdisk 文件一起分发，这增加了与单个整个磁盘镜像文件相比，已部署镜像的文件管理复杂性。
《强化镜像的要求》包括为 root、数据等拥有单独的卷。当使用整个磁盘镜像时，所有 TripleO 用户都可以获得强化镜像的安全优势。
我们目前需要专用的 CI 作业，无论是在上游检查/门控中（当相关文件更改时），还是在定期集成行中，来构建和发布最新版本的“current-tripleo”强化镜像。从长远来看，只需要构建和发布一个硬化 UEFI 整个磁盘镜像，从而减少 CI 占用空间。（短期内，CI 占用空间可能会增加，以便可以发布整个磁盘镜像，同时重构硬化与硬化-uefi 作业。）

提议的变更¶

概述¶

无论在何处构建、发布或使用分区镜像 overcloud-full.qcow2，都需要更新为默认使用 overcloud-hardened-uefi-full.qcow2。

当可以按照文档中的默认路径进行操作，并且结果是使用整个磁盘镜像部署的 overcloud 时，此蓝图将被视为已完成。

镜像上传工具¶

默认行为 openstack overcloud image upload 需要知道，当在本地目录中检测到 overcloud-hardened-uefi-full.qcow2 时，应该默认上传它。

审查镜像构建 YAML¶

更新了定期作业后，可以删除定义 overcloud-hardened-full 的镜像 YAML，只留下 overcloud-hardened-uefi-full。可以进行其他重构，例如将 -python3.yaml 重命名为 -base.yaml。

审查分区布局¶

Swift 数据存储在 /srv 中，根据强化镜像的标准，它应该位于自己的分区中。这需要添加到现有的整个磁盘 UEFI 镜像的分区布局中。

分区增长¶

在节点首次启动时，需要一种替换机制来增长根分区。这对于整个磁盘镜像创建的多个 LVM 卷来说是一个更难的问题。通常，/var 卷应该增长以占用可用磁盘空间，因为 TripleO 和 OpenStack 服务将其状态存储在此处，但有时 /srv 需要增长以用于 Swift 存储，并且有时可能需要多个卷的比例分配。这表明将需要新的 tripleo-heat-templates 变量，这些变量将指定每个角色的卷/比例增长行为。

需要一个自动化此 LVM 卷增长要求的实用程序。它可以以多种方式实现

一个新的项目/包，包含该实用程序，安装在镜像上，并由首次启动或早期 tripleo-ansible 运行。
一个实用程序脚本，由 diskimage-builder/tripleo-image-elements 元素安装，并由首次启动或作为首次启动 ansible 任务（预置或早期部署）运行。
完全在 ansible 角色中实现，要么在自己的存储库中，要么作为 tripleo-ansible 的一部分。它将由早期 tripleo-ansible 运行。

此实用程序也将对使用基于 LVM 的镜像的其他云工作负载有用，因此需要考虑将其制成一个通用工具，可以在 overcloud 镜像之外使用。因此，最初建议采用选项 2 作为安装此实用程序的首选方式，并将其作为 diskimage-builder 中的新元素提出。与 diskimage-builder 耦合意味着该实用程序可以对分区布局做出假设

单个卷组，默认名称为 vg
卷分区格式化为 XFS，可以在挂载时调整大小

替代方案¶

由于 grub 的情况，唯一的真正替代方案是放弃对 UEFI 启动的支持，这意味着无限期地仅支持传统 BIOS 启动。这可能会收到最终用户的负面反馈。

安全影响¶

所有部署都将使用符合强化镜像要求的镜像，因此部署将获得这些安全优势
整个磁盘镜像支持 UEFI 安全启动，因此此蓝图使我们更接近于建议始终启用安全启动。这将向用户验证他们已部署由 Red Hat 签名的引导/内核二进制文件。

升级影响¶

就地升级的节点将继续基于分区镜像，而新的/替换的节点将使用整个磁盘镜像部署。除非我们记录一种替换每个节点以确保所有节点都使用整个磁盘镜像部署的选项，否则这没有特定的升级影响。

其他最终用户影响¶

除了以下几点之外，对最终用户的影响很小

需要养成使用 overcloud-hardened-uefi-full.qcow2 而不是 overcloud-full.qcow2 的习惯
如果需要自定义分区增长行为，则需要设置 heat 变量

性能影响¶

此更改没有已知的性能影响。

其他部署者影响¶

所有部署器影响已经在其他地方提到。

开发人员影响¶

除了已经提到的部署器影响之外，没有开发人员影响。

实现¶

负责人¶

主要负责人: Steve Baker <sbaker@redhat.com>

工作项¶

python-tripleoclient: 镜像上传命令，如果本地存在，则处理 overcloud-hardened-uefi-full.qcow2 作为默认值
tripleo-ansible/cli-overcloud-node-provision.yaml: 检测 overcloud-hardened-uefi-full.(qcow2|raw) 作为默认值，如果它存在于 /var/lib/ironic/images 中
RDO 作业: * 添加 overcloud-hardened-uefi-full 的定期作业 * 删除 overcloud-hardened-full 的定期作业 * 修改镜像发布作业以发布 overcloud-hardened-uefi-full.qcow2
tripleo-image-elements/overcloud-partition-uefi: 添加 /srv 逻辑卷用于 swift 数据
tripleo-quickstart-extras: 使用 whole_disk_images=True 变量切换到下载/上传/部署 overcloud-hardened-uefi-full.qcow2
tripleo-ci/featureset001/002: 启用 whole_disk_images=True
diskimage-builder: 添加一个新元素，该元素安装用于根据特定卷/比例映射增长 LVM 卷的实用程序
tripleo-common/image-yaml: * 重构以删除非 UEFI 强化镜像 * 将 -python3.yaml 重命名为 -base.yaml * 添加安装分区增长实用程序的元素
tripleo-heat-templates: 定义用于驱动分区增长卷/比例映射的变量
tripleo-ansible: 消耗卷/比例映射并在早期启动时在每个节点上运行卷增长实用程序。
tripleo-docs: * 更新默认部署整个磁盘镜像的文档 * 记录控制分区增长的变量

依赖项¶

除非 diskimage-builder 需要单独跟踪以添加分区增长实用程序，否则所有任务都可以在此蓝图下跟踪。

测试¶

镜像构建和发布¶

构建镜像的定期作业以及将镜像构建和发布到可下载位置的作业需要更新为构建和发布 overcloud-hardened-uefi-full.qcow2。最初，这可以与现有的 overcloud-full.qcow2 发布并行进行，但最终可以将其关闭。

overcloud-hardened-full.qcow2 与 overcloud-hardened-uefi-full.qcow2 相同，只是它仅支持传统 BIOS 启动。由于 overcloud-hardened-uefi-full.qcow2 支持传统 BIOS 和 UEFI 启动，因此可以从 Wallaby 开始关闭构建 overcloud-hardened-full.qcow2 的定期作业（假设这些更改会回溯到 Wallaby）。

CI 支持¶

消耗已发布镜像的 CI 作业需要修改，以便可以下载 overcloud-hardened-uefi-full.qcow2 并将其作为整个磁盘镜像部署。

文档影响¶

TripleO 部署指南需要修改，以便在整个文档中引用 overcloud-hardened-uefi-full.qcow2，并正确记录基于整个磁盘镜像的 overcloud 的部署。

默认部署整个磁盘镜像