QuintupleO - TripleO on OpenStack¶
https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack
这旨在成为在虚拟化环境中进行 TripleO 部署的一种新方法。我们不再直接通过 virsh 预置目标虚拟机，而是可以使用标准的 OpenStack API 来创建和管理实例。这应该使虚拟 TripleO 环境更具可扩展性，并且更易于管理。
最终目标是使能够在任何 OpenStack 云上进行虚拟 TripleO 部署，除非必要功能已被明确禁用。我们希望在用于 OpenStack CI 的公共云上提供所需的功能，因此邀请现有提供商审查此规范。
问题描述¶
TripleO 的开发和测试需要大量的硬件资源，并且随着 HA 默认启用等功能的增加，这种需求只会增加。此外，我们希望能够测试比单个物理机器所能容纳的更大的部署。虽然可以手动设置，但 OpenStack 已经提供了能够管理大量物理主机和虚拟机的服务，因此没有必要重复造轮子。
提议的变更¶
为 OpenStack 实例编写虚拟电源驱动程序。我已经有了一个针对 nova-baremetal 的粗略版本，但它需要在合并到主代码库之前进行大量的清理。我们还需要与 Ironic 团队合作以在该功能上启用它。
确定 Neutron 是否需要更改才能允许我们运行自己的 DHCP 服务器，如果是，则与 Neutron 团队合作进行这些更改。这可能需要允许在没有分配任何 IP 的情况下启动实例。如果不是，则启动没有 IP 的实例将是一个很好的未来增强功能，以避免浪费 IP 配额。
同样，确定如何在 Neutron 中使用虚拟 IP 与 keepalived/corosync+pacemaker，如果 Neutron 需要更改，则与他们的团队合作以启用该功能。
在 Nova 中启用 PXE 启动。已经有一个 bug 报告来跟踪此功能请求，但似乎已被放弃。请参阅本文档的“参考文献”部分中的链接。理想情况下，应该以每个实例为基础启用此功能，这样就不需要专门的计算节点，这不允许我们在标准的公共云上运行。
为了与当前虚拟 devtest 环境的性能和功能保持一致，我们希望允许对虚拟裸机实例使用不安全的缓存。
一旦所有 OpenStack 服务都支持此用例，我们希望将我们的 CI 环境转换为标准的 OpenStack KVM 云，并弃用现有运行 TripleO 的虚拟方法，并启用 devtest 来安装和配置本地 OpenStack 安装（可能使用 devstack）以在其上运行。
根据当时我们的容器支持状态，我们可能希望使用容器运行 devtest OpenStack，以避免像 devstack 通常那样接管主机系统。当我们达到那个点时，这可能需要自己的规范。
替代方案¶
编写虚拟电源驱动程序没有真正的替代方案。为了使这项工作能够实现，我们必须能够将 OpenStack 实例作为裸机节点进行管理。
创建连接到本地桥接器的扁平 Neutron 网络可以解决 Neutron 不允许 DHCP 流量的问题，但这仅在您可以访问创建本地桥接器并配置新网络时才有效。这在许多（全部？）公共云提供商中可能不成立。
我尚未对 Neutron 中的虚拟 IP 地址进行任何工作，因此我不清楚是否存在任何替代方案。
如前所述，使用 iPXE 镜像可以允许 PXE 启动 Nova 实例。但是，由于该镜像在部署期间被覆盖，因此无法在之后 PXE 启动该实例。使 TripleO 镜像能够自行启动可能是一种选择，但这将偏离真实裸机环境的工作方式，因此可能不是理想的选择。
通过 PXE 启动部署 overcloud¶
由于在 OpenStack 云上进行 TripleO 开发的许多复杂问题与启动实例的 PXE 启动有关，因此在某些情况下，一种有用的选择是能够直接部署镜像。由于我们使用 Heat 进行部署，因此应该能够使用 vm 元素构建 TripleO 镜像，并将它们作为常规实例而不是假裸机实例进行部署。
这有一个缺点，即无法像完整的虚拟 PXE 启动过程那样行使 TripleO 裸机功能的那么多功能，但它应该更容易实现，并且对于不涉及部署过程的一些开发工作来说，足以验证功能是否按预期工作。它可能是在我们努力在 OpenStack 云中启用完整 PXE 启动功能时的一个很好的中间步骤。
它还会阻止行使 HA 功能，因为如果无法使用 DHCP/PXE 来管理我们自己的网络环境，我们可能无法使用虚拟 IP 地址。
安全影响¶
虚拟电源驱动程序需要访问 OpenStack 凭据才能控制实例。
Neutron 更改以允许私有网络表现为扁平网络可能会产生安全影响，尽管我不确定具体是什么。虚拟 IP 支持也是如此。
从理论上讲，PXE 启动实例可以允许攻击者覆盖 DHCP 服务器并启动任意镜像，但为了做到这一点，他们已经需要访问正在使用的私有网络，因此我不认为这是一个重大的新威胁。
其他最终用户影响¶
使用虚拟部署环境进行概念验证的最终用户需要切换到这种新方法，但这应该主要由 devtest 的必要更改来处理，因为这就是将用于此类部署的工具。
性能影响¶
在我的测试中，我的 OpenStack 虚拟电源驱动程序比现有的基于 virsh 的驱动程序慢得多，但我相信通过更好的实现可以轻松解决这个问题。
在公共云上运行 TripleO 时，开发人员将受到共享硬件的通常限制——给定的资源可能会被过度订阅，并导致处理或磁盘密集型 TripleO 部署的操作出现性能问题。
其他部署者影响¶
这不打算对常规部署者可见，但它应该使我们的 CI 环境更灵活，从而可以更动态地分配资源。
开发人员影响¶
如果这成为进行 TripleO 开发的主要方法，devtest 需要更改为指向现有的 OpenStack 环境，或者配置一个本地环境。这将影响开发人员调试其环境的方式，但由于他们将调试 OpenStack，因此从长远来看，这将是有益的。
实现¶
负责人¶
- 主要负责人
bnemec
- 其他贡献者
jang
工作项¶
实现 Ironic OpenStack 虚拟电源驱动程序。
实现 nova-baremetal OpenStack 虚拟电源驱动程序，可能基于我们从 Nova 和 Ironic 处收到的反馈，构建在树之外。
在 Nova 中启用 PXE 启动。
允许在 Nova 实例上启用不安全的缓存。
允许 DHCP/PXE 流量在 Neutron 中的私有网络上进行。
如果未包含在前面的点中，则允许在没有 IP 地址的情况下启动实例。
将 CI 迁移到使用 OpenStack 云作为其虚拟裸机实例。
将 devtest 迁移到安装和配置 OpenStack 云，而不是手动管理实例和网络。
为了简化 VM 预置过程，我们应该能够预置但不启动 Nova VM。
依赖项¶
工作项部分中的 Ironic、Neutron 和 Nova 更改都必须完成，TripleO 才能完全采用此功能。
测试¶
其他项目中的所有更改都将进行单元和功能测试，就像任何其他新功能一样。
我们无法通过在 gate VM 中运行 devstack 来预置 OpenStack 云来测试此功能，就像 Tempest 所做的那样，因为嵌套 qemu 虚拟机的性能会使该过程变得过于缓慢。我们需要一个可以由测试目标定位的裸机 OpenStack 部署。然而，今天 virsh 实例也存在类似的问题，并且可能以类似的方式通过专用的 CI 环境来解决。
我们需要对我们依赖的功能进行功能测试，并在我们使用的所有项目上进行 Tempest 测试。这应该主要由第一个点的功能测试涵盖，但我们可能会发现需要添加 TripleO 特定场景。
文档影响¶
devtest 需要更新以反映运行它所需的新的设置步骤，以针对基于 OpenStack 的环境。
参考资料¶
这主要基于 https://etherpad.openstack.org/p/devtest-env-reqs 中 Devtest on OpenStack 的讨论
Nova bug 请求 PXE 启动支持：https://bugs.launchpad.net/nova/+bug/1183885
