Project Mercury¶
https://bugs.launchpad.net/ironic/+bug/2063169
这是一个创建 Ironic 和物理网络配置之间简化框架的项目，旨在促进网络编排，使其与现有的 OpenStack Neutron 服务分离，并采用一种能够由非“云”团队，而是“网络”团队有效操作的模型。
原因有很多
使用 Ironic 的运营商数量持续增长，但完全集成配置下的运营商数量增长速度不如以“独立”模式运行的运营商快。
需要物理交换机管理的运营商通常需要在具有严格职责分离的环境中运行。例如，软件可能无法访问交换机管理框架，并且在任何情况下都不能允许任何用户访问此类服务。
DPU 的引入通常意味着我们现在有潜在的情况，需要编程交换机来配置 DPU，然后需要编程 DPU 来配置服务器。
目标可以概括为
提供一种在交换机上配置 L2 网络机制，这可以通过修改后的 networking-generic-switch 或类似插件来实现。
提供一种将 L2 网络配置为从 DPU 提供给主机的机制。
提供一种适应高度隔离的网络管理接口的机制，运营商限制访问权限，以便只有 Ironic 才能连接到远程端点。
提供一种应用和清理配置的工具，不跟踪然后断言配置。这并不排除将来存在“双重检查此配置”模式，但最小可行功能是网络配置的应用和删除。
提供一种接收调用以执行某项操作的机制，从本地存储读取网络配置凭据，然后执行，而无需数据库或共享消息总线。
这个项目不是
旨在提供任何类型的 IPAM 功能。
旨在提供路由管理。
旨在提供安全组或防火墙管理。
旨在提供公共 ReSTful API，也不需要数据库。
这个项目可能
提供一种帮助启用和部署高级工具到 Ironic 控制下的 DPU 的手段。
提供一种在同时使用 Neutron 和 Ironic 的环境中卸载部分 L2 交互责任的手段，尤其如此。
警告
本文档不是精确且规范性的设计文档，而是一份记录和呈现想法的文档，以便促进沟通和共识建设。在这种情况下，我们可能会将实施者留给自由发挥，而本文档则作为整体指导原则。
问题描述¶
目前，Ironic 只有一种选择来促进交换机级别基础设施的自动化，那就是利用 Neutron 和 ML2 接口。不幸的是，需要 Ironic 的基础设施运营商大多拒绝这种模式，因为网络通常由独立的团队拥有。
因此，我们需要一项服务来促进安全和明确的网络管理，该服务可以由企业组织中的独立基础设施团队拥有和运营，并将简单代码模式和 playbook 结合起来，以便他们信任接口层来应用基本的网络配置并更容易地使用裸机。在大多数需要这种配置的情况下，只需要将物理端口设置为特定的网络；寻址通常由单独管理，与我们无关。
此外，DPU 领域的可用生态系统希望以各种方式建模其设备，其中一些设备具有固有的限制。例如，某些设备只是嵌入的另一个计算机，并连接到相同的 PCI 设备总线。其他设备提供了加载 P4 程序来处理特定任务的能力。或者设备的可用 Flash 和 RAM 非常有限，以至于选项非常有限，并且完全排除了所有“现成的”操作系统及其实用程序。这种特性使得几乎每个设备及其产生的用例都完全控制其配置和使用模型，这意味着易于修改的模块化接口将提供最大的潜在影响。
提议的变更¶
我们建议使用 RPC 服务。具体来说，类似于 JSON-RPC 端点，多个 ironic conductor 都可以连接到该端点，以请求进行网络更改。
除了 RPC 服务之外，我们还将拥有一个适当命名的 network_interface 驱动程序，以获取存储在 Ironic 内部的信息，并根据提供的信息执行接口的连接。
注意
存在一种可能性，我们实际上可以从混合双 network_interface 驱动程序开始，以帮助我们明确地处理集成。这更像是实施者的自由裁量权。
MVP 可能不包括锁定，但建模为单个工作程序服务或容器，不维护状态，这在很大程度上简化了问题，变成了“谁登录到什么”以进行并发更改，这一直是锁定的历史驱动因素。
注意
教 networking-baremetal 调用这个建议的 RPC 服务通常不在此工作范围内，但完全有可能促进它，这将为一些调用通过代理并与 Neutron 部署相关联以最终也调用这个新服务提供功能。
总体调用模型，在高层上可以采用以下流程。
┌──────────────────────────┐
│Inbound Request/Connection│
└───┬──────────────────────┘
│
┌───▼────────────────────────────┐
│{"type": "attach_port", │
│ "payload": {"context": {...}}} │
└───┬────────────────────────────┘
│
┌───▼──────────────────────────┐
│Invoke Plugin With Context │
└───┬──────────────────────────┘
│
┌───▼────────────────────────────────┐
│Plugin handles locking, if necessary│
└───┬────────────────────────────────┘
│
┌───▼───────────────────────────────────────────────────────┐
│Plugin succeeds (HTTP 200?) or fails and returns HTTP error│
└───────────────────────────────────────────────────────────┘
虽然最初设想的是可以直接加载 ML2 插件，但插件的设计模型在这种远程执行的上下文中存在一些挑战，这可能是为什么远程 RPC 模型从未在 Neutron 中发展的原因。
两个基本问题
插件在完成绑定操作后，通过更新 neutron 数据库的模式来更新 neutron 数据库中的状态。这需要数据库访问权限和凭据，这在我们的用例和模型中不可用。
插件还可以调用原始提供的上下文中的方法。在这种情况下，Neutron 中的上下文不是由 oslo.context 提供的上下文，而是完全独立的结构，包含正在修改的网络状态的过去和未来信息。
因此，显而易见的方法是简化模型，并围绕基本操作设计用于此交互的 RPC 模型，并允许 ML2 用户能够进行调用，从而将操作与信息/状态/配置更新抽象化。
get_allowed_network_types - 返回支持的网络类型列表，允许调用者确定是否可以提供该操作。目前，baremetal 参与 ML2 插件大多只是将其硬编码为仅支持 VLAN 类型，但将此尽可能推送到执行的插件允许其成为通用的传递。
is_link_valid - 根据请求是否具有足够的正确信息来执行，返回 True/False。可用于基本的预操作验证。
is_port_supported - 根据请求的端口是否支持操作，返回 True/False。通常，这是一种 VNIC 类型检查，但也可以由远程服务用于执行基本的预飞行验证操作，并允许客户端快速失败。
attach_port - 执行将端口“附加”（添加 VLAN 或最终 VNI）的实际操作。
detach_port - 执行从端口“分离”（删除网络访问权限）的实际操作。
update_port - 尝试更新端口以进行“附加”，例如，如果端口通道/绑定属性已更改。
add_network - 将网络添加到远程设备。
delete_network - 从远程设备删除网络。
从某种意义上说，这改变了“加载 ML2 插件”的想法，变成了“加载混合 ML2 插件接口，或者定义我们自己的插件模型，该模型可以得到支持”，因此这是一个本规范试图找到答案的未决问题。
对于远程 RPC 服务，预计日志记录需要足够详细，以便运营商能够理解他们可能在调查问题时提出的问题。例如：何时、谁、什么、为什么以及如何。Ironic 中的插件代码也应该详细记录，以便在调用时确保运营商可以匹配请求和由此产生的更改，如果出现问题。
虽然超出了基本功能的初始 MVP，但为了解决 DPU 的情况，整体模式模型可能采用以下形式：Ironic 将遍历“子节点”，将子节点附加到请求的物理网络，然后以某种程度的编程方式进行交互，这可能需要根据整体用例进行供应商或部署特定的操作。目前无法确定这些细节，因为需要在构建基础层之后才能在此基础上构建。
从用户的角度来看，以下序列描述了他们的基本交互和整体结果序列。
┌──────────────────────────────┐
│ Existing node chosen by user │
└───┬──────────────────────────┘
│
┌───▼───────────────────────────────────────────────┐
│ User posts to /v1/nodes/<ident>/vifs with payload │
│ containing an id of a vlan ID. │
└───┬───────────────────────────────────────────────┘
│
┌───▼──────────────────────────────────────────────┐
│ User requests the node to deploy via the │
│ /v1/nodes/<ident>/states/provision API interface │
└───┬──────────────────────────────────────────────┘
│
┌───▼──────────────────────────────────────────────┐
│ Ironic follows existing flow, triggering the new │
│ network_interface module which calls this new │
│ service to perform the attach/detach operations │
│ in accordance with the existing model and node │
│ lifecycle state. │
│ Initial network in a deploy is the provisioning │
│ network. │
└───┬──────────────────────────────────────────────┘
│
┌───▼──────────────────────────────────────────────┐
│ Node deployment proceeds with resources already │
│ connected to the desired network. │
└───┬──────────────────────────────────────────────┘
│
┌───▼──────────────────────────────────────────────┐
│ Once deployment has been completed, the network │
│ interface module calls the new service to change │
│ the attachment to the requested vlan ID. In the │
│ event of a failure, the physical switch port │
│ is detached. │
└──────────────────────────────────────────────────┘
备选方案¶
最接近的替代方案是与某种扩展/代理 RPC 模型相结合的 独立 Neutron，这很好，但这并没有解决基础设施运营商需要的附加/分离功能的基本挑战。它还引入了可能不适合批量基础设施运营商的建模，因为他们需要以物理基础设施模型而不是云模型进行思考和操作。此外，操作 Neutron 需要管理数据库，从而增加了运营复杂性，并且还需要导航状态，这增加了基于不同 Neutron 用例的配置和代码复杂性。
另一种可能性是将网络附加/分离加载和逻辑直接嵌入到 Ironic 本身，但是这将给维护带来困难，而我们主要希望解锁能力。
数据模型影响¶
目前，我们正在建模的想法是利用存储在 Ironic 内部的现有端口数据，该数据用于附加操作。
存在一种可能性，我们可能会查看在 Ironic 的数据库中存储一些额外的物理和逻辑网络详细信息，以包含在请求中，这可能是同步的，但在初始阶段，我们打算使用 VIF 附加/分离模型来表示逻辑网络。
状态机影响¶
无
REST API 影响¶
对于 MVP，我们预计不会对 Ironic 本身进行任何 REST API 更改，唯一的例外是失去 Ironic 接受 VIF 附加请求的正则表达式。Ironic 社区已经很久以前同意了这一点，但从未执行。
现有节点和端口上的字段将继续像以前一样使用 MVP。
MVP 之后可能会包含某种 /v1/physical_network 端点进行设计，但预计将在我们了解更多信息后进行设计。
客户端 (CLI) 影响¶
“openstack baremetal” CLI¶
无
“openstacksdk”¶
无
RPC API 影响¶
此更改提出了一个将通过 RPC 模型交互访问的 Ironic 的服务。这意味着将以库的形式存在一些共享的调用含义。
很可能这就像“附加”和“分离”一样简单，但考虑到 MVP 的整体需求以及我们专注于利用现有工具的用例，确切的细节最好通过开发过程来发现，这可能涵盖了上述“拟议的更改”部分中提到的内容。
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
Ramdisk 影响¶
无
安全影响¶
Ironic 本身的影响很小，尽管需要设置远程服务的凭据以指示接口附加/分离。
安全风险主要围绕着我们正在努力创建的新服务。用于连接到远程服务的共享库可能还需要包含必要的客户端包装代码，因为 MVP 服务可能只会从 HTTP Digest 认证开始，然后随着其发展转向证书认证。
很大程度上，因为该服务需要加载和组合一组凭据和访问信息。因此，这个新服务不会是用户面临的服务。
今天，单个端口通过网络标识符和用于将端口映射到交换机的绑定配置文件来附加。在这种模型中，不会有实质性的差异。network_id 将是用户提供的详细信息，local_link_information 将包含足够的执行插件识别设备的详细信息。新服务将从本地配置中检索访问远程设备的详细信息，并将其余的绑定配置文件和目标网络标识符组合起来，以便将端口附加到设备。
注意
此安全影响不包括未来执行 DPU 凭据管理等方面的机制，我们目前将这种可能性推迟到达到初始最小可行产品状态之后再关注。
注意
此安全风险不包括任何未来的机制来执行诸如在 DPU 上部署软件以促进与 Neutron 完全集成之类的操作，这是我们希望在迭代支持这种能力的过程中识别和确定的一些事情。
其他最终用户影响¶
无
可扩展性影响¶
请参阅下面的性能影响部分。
性能影响¶
该提案有意设计为有限且隔离的，以最大限度地降低风险并减少部署复杂性。它也故意建模为一种“执行某项操作”的工具，而该“操作”恰好是在需要设备锁定的区域进行配置。现实意义是，写入磁盘的唯一内容将是锁文件。
此外，有可能 Ironic 驱动程序代码可以等待响应，而今天 Neutron 端口附加/分离调用是异步的。这将为 Ironic 的最终用户提供整体改进。今天，这通过默认的 15 秒睡眠来解决，并且可能在本设计中不需要，从而提高 Ironic 的性能。
其他部署者影响¶
要使用此功能，部署者需要部署一项新服务。
这将是选择加入的，并且不会影响现有用户。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
<志愿者 #1>
- 其他贡献者
<志愿者 #2>
工作项¶
广义地说，工作项目将包括
原型化这项新服务。
连接一个 ML2 驱动程序，以便我们拥有可以加载和调用的接口。预计这将是 networking-generic-switch。
原型化一个 ironic network_interface 驱动程序来使用这项新服务。
测试！
注意
以下列表旨在描绘我们认为可能的步骤，超越创建最小可行产品的初始步骤。它们包括在内，以提供完整的上下文，帮助读者理解我们的思维模型。
原型化之后，以下内容可能适用
创建用于 Ironic 和任何其他程序或工具来利用以组合 RPC 调用到此服务的通用库。
扩展对 VXLAN 端口的支持，这可能需要额外的详细信息或设计工作来发生并与任何使用的 ML2 驱动程序一起工作。
设计一个 API rest 端点，以促进跟踪要附加到裸机节点的物理网络。
添加对 networking-baremetal 的支持，以尝试将这些物理网络协调到 Ironic，以便可以进行节点端口附加/分离。
添加对 networking-baremetal 的支持，以便它可以代理请求到此服务以进行 Neutron 中的端口绑定请求。
设计一个新的模型，可能取代 VIFS，但 VIFS 也可能只是未来内部网络 ID。 这可能需要 Metal3 正式采用此功能，但独立用户一旦实现即可立即使用。
开发一种模型和流程，允许 DPU 设备在 Ironic 调用步骤时部署服务。 这将涉及许多挑战，但可用于支持 Neutron 集成的 OVS/OVN 代理在卡上运行，例如当远程卡位于 hypervisor 节点时。
依赖项¶
待定。
测试¶
上游 CI 的理想测试模型尚未确定，并且取决于达到最小可行产品状态后的状态，以及后续目标是什么。
这可能涉及复制 Ironic 现有的多节点作业，并以独立形式进行复制。 最终的期望是我们将拥有一个或多个 CI 作业专门用于支持对此功能的测试。
升级和向后兼容性¶
预计此功能将是 Ironic 的“全新”功能，并通过专用的 network_interface 模块向最终用户公开，用户可以在未来的某个时间点选择该模块。 因此，预计不会出现升级或向后兼容性问题。
文档影响¶
目前预计没有影响。
