TripleO 网络配置

https://blueprints.launchpad.net/tripleo/+spec/os-net-config

我们需要一个工具（或工具集）来帮助配置 TripleO 中的主机级网络。这包括以下内容：

  • 静态 IP

  • 多个 OVS 桥接

  • 绑定

  • VLAN

问题描述

目前在 TripleO 中，我们使用 DHCP 引导节点，以便它们可以从 Heat 下载自定义的节点元数据。此元数据包含每个实例的网络信息，允许我们创建定制的主机级网络配置。

目前，这通过两个脚本完成：

现有脚本的问题在于它们的功能集过于严格且有限。目前我们仅支持将单个 NIC 桥接到 OVS 桥接，VLAN 支持有限，并且更高级的配置（即使是像 MTU 这样的常见 IP 地址属性）也是不可能的。

此外，我们还希望对网络更改的方式以及它们是否持久化有一定的控制权。在这方面，提供程序层会很有用，以便用户可以选择例如：

  • ifcfg/eni 脚本：用于需要持久性并且我们希望使用发行版支持的默认值配置接口

  • iproute2：用于提供优化/简化的网络配置，可能包含也可能不包含持久性

我们目前的能力有限，以至于我们无法完全配置我们的 TripleO CI overcloud，而无需对镜像本身进行手动更改和/或修改。因此，我们需要扩展我们的主机级网络功能。

提议的变更

创建一个新的 Python 项目，封装主机级网络配置。

这可能包括：

  • 一个内部 Python 库，用于促进主机级网络配置

  • 一个二进制文件，它处理 YAML（或 JSON）格式并调用关联的 Python 库来配置主机级网络。

通过遵循这种设计，该工具应该可以与 Heat 驱动的元数据配合使用，并为我们提供未来将部分库代码移动到 Oslo（oslo.network？）或 Neutron 本身的选项。

该工具将支持“提供程序”层，以便多个实现可以驱动主机级网络配置（iproute2、ifcfg、eni）。这一点很重要，因为随着发行版采用新的网络配置格式，我们可能希望逐渐开始使用它们（例如，展望 systemd.network）。

该工具还需要是可扩展的，以便我们可以随着时间的推移添加新的配置选项。例如，我们可能希望在稍后添加更高级的绑定选项……这应该尽可能容易。

该工具的初始重点将是现有 TripleO 功能（接口、桥接、VLAN）的主机级网络配置，方式更加灵活。虽然我们今天以一种规定性的方式支持这些内容，但新的工具将立即支持可以临时创建的多个桥接、接口和 VLAN。可以创建 Heat 模板来驱动常见配置，并且人们可以根据需要自定义这些模板以进行更高级的网络设置。

初始实现将侧重于 ifcfg 和 eni 的持久化配置格式，就像我们今天通过 ensure-bridge 所做的那样。这将帮助我们继续朝着在断电后使裸机恢复在线迈进（例如，为 DHCP 服务器提供静态 IP）。

该工具的主要重点应始终是主机级网络配置和我们无法在 Neutron 本身中轻松进行调整的微调。随着时间的推移，该工具的范围和概念可能会随着 Neutron 功能的添加或删除而发生变化。

替代方案

另一种选择是继续扩展 ensure-bridge 和 init-neutron-ovs，这将需要大量的新的 bash 选项和参数来配置所有新功能（VLAN、绑定等）。

OpenStack 生态系统中的许多部署项目今天都在做类似的网络工作。请考虑：

这些选项中的大多数都是不可取的，因为它们会给 TripleO 添加大量的依赖项。

安全影响

该工具使用的数据已经是面向管理员的，并将继续由 Heat 提供。因此，关于访问配置数据的用户面临安全问题，不应存在任何已经存在的问题。

此实现将直接影响 TripleO 所有层中的低级网络连接，包括 seed、undercloud 和 overcloud 网络。任何尚未由 Neutron 提供的host 级网络都可能受到影响。

其他最终用户影响

此功能使部署者能够构建更高级的 undercloud 和 overcloud 网络，因此应该有助于提高 TripleO 中基本主机网络功能的可靠性和性能。

最终用户应该从这些努力中受益。

性能影响

此功能将允许我们构建更好/更高级的网络，因此应该有助于提高性能。特别是接口绑定和 VLAN 支持在这方面有所帮助。

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

Dan Prince (dan-prince on Launchpad)

工作项

  • 在 GitHub 上创建项目：os-net-config

  • 将项目导入 openstack-infra，获取单元测试门控等。

  • 构建一个 Python 库来配置主机级网络，最初的重点是与我们已经拥有的内容（包括我们绝对需要的 TripleO CI overcloud 网络）的奇偶校验。

    该库将包含一个对象模型，该模型将允许用户创建接口、桥接、VLAN 和绑定（可选）。这些类型中的每一个都将充当地址对象（IPv4 和 IPv6）和路由（可以定义多个路由）的容器。此外，每个对象将包括启用/禁用 DHCP 和设置 MTU 的选项。

  • 为 ifcfg/eni 创建提供程序层。提供程序接受一个对象模型并应用它（“使其生效”）。ifcfg 提供程序将编写持久化配置文件到 /etc/sysconfig/network-scripts/ifcfg-<name> 并使用 ifup/ifdown 在更改后启动和停止接口。eni 提供程序将把配置写入 /etc/network/interfaces，同样使用 ifup/ifdown 在更改后启动和停止接口。

  • 为 iproute2 创建一个提供程序层。可选，以后可以完成。此提供程序很可能不使用持久化格式，并且将运行各种 ip/vconfig/route 命令来配置给定对象模型的host 级网络。

  • 创建一个二进制文件，该文件处理 YAML 配置文件格式并发出正确的 Python 库调用。该二进制文件应该是幂等的，即使用给定的配置运行该二进制文件一次应该“使其生效”。第二次运行相同的配置应该什么也不做（即，可以安全地多次运行）。以下是一个示例 YAML 配置格式，描述了连接到桥接的单个 OVS 桥接，这与 ensure-bridge 今天创建的内容相匹配

network_config:
  -
    type: ovs_bridge
    name: br-ctlplane
    use_dhcp: true
    ovs_extra:
      - br-set-external-id br-ctlplane bridge-id br-ctlplane
    members:
      -
        type: interface
        name: em1

上述格式使用嵌套方法来定义连接到桥接的接口。

  • TripleO 元素以安装 os-net-config。很可能使用 pip（但我们可能会先使用 git，直到它发布）。

  • 将其连接到 TripleO……使用现有的 Heat 元数据格式使其全部协同工作。这包括对 tripleo-incubator 的任何文档更改、弃用旧元素等。

  • TripleO heat 模板更改以使用新的 YAML/JSON 格式。我们的默认配置很可能做我们今天所做的事情（带有单个连接接口的 OVS 桥接）。我们可能希望创建一些其他示例 heat 模板，这些模板可以在其他环境中使用（例如，我们用于 CI overcloud 的多桥接设置）。

依赖项

无

测试

现有的 TripleO CI 将有助于确保在我们实现此功能时，我们保持与当前功能集的奇偶校验。

能够配置和使用我们的 Triple CI 云，而无需自定义修改/修改，也将是我们这里大部分工作的试验场。

对于更高级的操作模式（绑定、VLAN 等），可能需要额外的手动测试。

文档影响

由于此功能，用于网络配置的推荐 Heat 元数据可能会发生变化。旧格式将保留以实现向后兼容性。

参考资料

关于此主题的亚特兰大峰会会议的说明可以在这里找到（包括可能的 YAML 配置格式）