可插拔网络提供者¶
https://bugs.launchpad.net/ironic/+bug/1526401
目前，Ironic 在与租户相同的（扁平）网络上配置服务器。Ironic 应该能够逻辑地分离配置网络和租户网络，并在需要时在它们之间切换。
注意：此规范中提到的“网络”通常指的是“Neutron 网络”，它可能以不同的方式实现。
问题描述¶
目前 Ironic 在与租户相同的（扁平）网络上配置服务器。显然，Ironic 应该允许操作员分离配置网络和租户网络；其中部署 ramdisk 在“配置”网络上运行，实例在一个或多个“租户”网络上运行。
为了保护配置网络，Ironic 在生成和销毁实例时应该能够在这两个网络之间切换。
此方法也应扩展到其他管理网络，这些网络可能与配置网络分离；例如，操作员可能希望对清理或救援任务使用不同的管理网络。
提议的变更¶
Ironic 应该有一个可插拔的“网络提供者”，可以处理在不同网络之间切换节点。该提供者应该能够为每个 Ironic 节点对象选择。将添加一个新的 network_provider 字段到节点对象中，以定义该节点使用哪个网络提供者。还应该有一个配置选项用于默认网络提供者，目前默认值为“none”。node.network_provider 的默认值将为 NULL，表示使用配置选项。节点字段和配置选项都可以设置为“none”或“neutron”，分别映射到无操作提供者和 Neutron 提供者。
此网络提供者系统将不属于 Ironic 的驱动程序接口混合系统；相反，它是独立的，并通过 stevedore 按需加载的。这类似于今天的 DHCP 提供者代码的工作方式。
应该编写一个无操作网络提供者的初始实现，以便将逻辑放置在 Ironic 中，同时保持与现有模型的兼容性。
应该编写第二个实现，该实现使用 Neutron 根据需要将硬件连接到网络，并且应该按以下方式工作。
网络提供者应该具有“配置网络”的概念，控制平面可以通过该网络与 Ironic 管理的节点通信，以便部署、拆除或以其他方式管理节点。它应该能够连接和断开节点与此网络的连接。
网络提供者还应该知道如何连接和断开节点与任意租户网络的连接。这些网络由 Nova 用户和 Nova 定义。Nova 应该继续创建 Neutron 端口（网络的逻辑连接），但这些端口将保持未绑定状态，因为它们没有足够的信息来完成连接。Ironic 稍后应该向 Neutron 发送端口更新调用，以传递完成绑定的必要信息。此调用应在部署镜像之后、引导到实例镜像的关机和开机调用之间发生。这可能对“从卷引导”工作负载产生影响。由于 Ironic 尚未支持这些工作负载，因此它们不在此规范的范围内。
在 Ironic 驱动程序使用的情况下，Nova 应该在绑定配置文件中发送一个 null host_id。这将阻止 Neutron 立即绑定端口，以便我们可以推迟此操作并允许 Ironic 告诉 Neutron 绑定端口。Ironic 应该将节点 UUID 作为 host_id 发送。Ironic 也会在这个时候删除连接到配置网络的 Neutron 端口。反之亦然，在拆除时发生。
如果使用较旧的客户端（例如 Nova），它最初会发送 host_id，Ironic 需要处理这种情况。这里有两种情况
节点正在使用 Neutron 网络提供者。在这种情况下，Ironic 应该首先获取端口，如果端口已经使用正确的信息绑定，则不执行任何操作。如果由于缺少交换机端口信息而绑定失败，Ironic 应该适当地更新端口并允许其绑定。
节点正在使用“none”网络提供者。在这种情况下，预计节点在部署后位于配置网络上（今天的当前模型）。在这种情况下，端口应该像今天一样处理，将 DHCP 配置放在这些端口上等。
Nova 和 Ironic 都应该使用 binding:profile 字典来发送诸如物理交换机端口信息之类的数据。
Nova 当前有一个错误的假设，即每个 Ironic 端口（物理 NIC）只能连接到一个网络。这个假设需要修复，因为硬件（今天）无法像虚拟服务器那样生成任意 NIC。将来，我们可能还需要一种方法让 Nova 用户定义哪个 NIC 连接到哪个网络。第一个版本应该为了简单起见而保留这个假设。
如果节点存在端口组，则应将这些端口组连接到网络，而不是单个端口。这允许聚合连接，例如 LAG 连接到网络。
请注意，Ironic 环境可以在没有 Nova 的情况下部署。在这种情况下，用户应该发出 Nova 将发出的相同调用。
这里的一个注意事项是，如果节点无法到达 conductor（用于 tftp），则无法使用 PXE 引导实例镜像。对于部署在配置网络之外的任何节点，必须使用本地引导。任何未使用本地引导且部署在配置网络之外的部署都应该出错。
部署驱动程序应该在适当的时间调用此接口以在网络之间切换。例如，完成部署的驱动程序应该关闭节点，切换到实例网络，然后打开节点。这将确保部署 ramdisk 永远不会在实例网络上运行，并且实例镜像永远不会在配置网络上运行。
备选方案¶
或者，Ironic 可以继续规定操作员在租户和控制平面之间共享的单个扁平网络上运行 Ironic。这显然不适用于许多实际用例。
数据模型影响¶
将向 Node 对象添加一个 network_provider 字段。
状态机影响¶
无。
REST API 影响¶
更新节点对象的 REST API 以允许读取和修改新的 network_provider 字段。这可能需要版本升级。
客户端 (CLI) 影响¶
需要更新 CLI 以打印新的 Node.network_provider 字段（如果可用）。
RPC API 影响¶
无。
驱动程序 API 影响¶
这添加了一个新的接口，NetworkProvider。需要明确的是，此接口不是 Ironic 驱动程序组合系统的组成部分。此接口将定义以下方法
def add_provisioning_network(self, task):
"""Add the provisioning network to a node."""
def remove_provisioning_network(self, task):
"""Remove the provisioning network from a node."""
def add_cleaning_network(self, task):
"""Add the cleaning network to a node."""
def remove_cleaning_network(self, task):
"""Remove the cleaning network from a node."""
def configure_tenant_networks(self, task):
"""Configure tenant networks (added by Nova/user) for a node."""
def unconfigure_tenant_networks(self, task):
"""Unconfigure tenant networks (to be removed by Nova/user) for a node."""
Nova 驱动程序影响¶
Nova 驱动程序此处不会受到直接影响；但是，这取决于 Nova 中 Neutron 网络驱动程序的更改，如上所述。
Ramdisk 影响¶
N/A
安全影响¶
这可以通过限制租户访问控制平面来提高安全性。
其他最终用户影响¶
要使用此功能，最终用户需要
将节点设置为使用 Neutron 提供者。
对于使用 Neutron 提供者的节点，请使用本地引导。
可扩展性影响¶
配置为使用 Neutron 插件时，这将导致向 Neutron 发送额外的 API 调用以管理节点。但是，对可伸缩性的影响应该可以忽略不计。
性能影响¶
无。
其他部署者影响¶
将添加两个新的配置选项
CONF.provisioning_network指定配置网络的 ID。CONF.default_network_provider指定为 network_provider 设置为 NULL 的节点的默认网络提供者。
还添加了一个新的数据库列（Node.network_provider），因此部署此更改需要运行数据库迁移。
如果使用 Nova，部署者需要部署支持此功能的 Nova 版本。
部署者需要部署支持将裸机资源连接到 Neutron 网络的 ML2 机制驱动程序。
开发人员影响¶
驱动程序作者应该通过调用提供的方法来支持此功能。
实现¶
负责人¶
jroll <jim@jimrollenhagen.com>
希望还有更多！:)
工作项¶
添加 Node.network_provider 字段和 default_network_provider 配置选项。
实现基本接口。
实现无操作提供者。
使用此接口对每个部署驱动程序进行检测。
实现 Neutron 插件提供者。
修改 Nova 以在创建使用 Ironic virt 驱动程序的机器的端口时发送上述额外标志。
依赖项¶
无。
测试¶
无操作提供者将默认在 gate 中进行测试。
Neutron 将提供一个 ML2 机制，模拟将真实硬件连接到真实交换机。当该机制可用时，我们可以测试 gate 中的 Neutron 提供者。
升级和向后兼容性¶
默认行为是当前行为，因此此更改应完全向后兼容。
文档影响¶
此功能将完全记录。
参考资料¶
关于此主题的讨论包括
