API：将 Neutron 配置代理到客户实例¶

https://blueprints.launchpad.net/nova/+spec/metadata-service-network-info

改进实例中 config drive 和元数据服务提供的网络信息。

问题描述¶

用例¶

目前，cloud-init 接收从模板生成的 Debian 风格的 interfaces 文件，并需要将其转换为 RHEL 或 Windows 等其他操作系统的 interfaces 文件。随着网络配置变得越来越复杂，这变得越来越具有挑战性。

Ironic 正在使用裸机硬件。他们的网络配置可能需要更复杂的网络配置，例如通过绑定接口上的多个 VLAN。然后将网络模板转换为多个操作系统比今天更具挑战性。虽然目前 Neutron 不支持这些，但已经提出了多个更改来添加支持。使用灵活的设计将更容易地添加新的网络配置。

替代用例：考虑一个第一个接口通过 DHCP 配置的 VM，所有其他接口都在私有网络上，这些接口是静态配置的，但您没有使用 config drive，只是使用元数据服务，并且不通过文件注入作弊，以与客户机无关的方式呈现数据。

在 interfaces 模板中不声明全局路由的情况下设置静态路由。

为了未来扩展：未来的用例将使用这种格式来创建绑定接口，无论是物理接口还是虚拟接口。许多超融合服务器部署在具有绑定接口的硬件上，因此 Ironic/TripleO 需要绑定接口是合理的。今天创建这些绑定接口，需要对正在绑定的接口名称做出假设，而这些名称可能会根据操作系统而更改。通过此更改，绑定接口可以以通用方式描述，并以一致的方式为操作系统实现。

项目优先级¶

没有，但结合 Neutron 对绑定的支持，将增加 Ironic 节点的容错能力。在 Triple O 的情况下，这也将增加运行 Nova 的硬件的容错能力。

提议的变更¶

创建一个版本化的 network_data（就像元数据服务和 configdrive 中已经存在的 user_data 和 vendor_data），提供更详细的网络信息
一个灵活的 JSON 模式，用于处理复杂的网络布局，并且可以轻松扩展，因为 Neutron 支持更多的配置
信息来自实例的当前 network_info
在 Neutron 支持之前，某些内容（例如绑定）将不受支持
我们真正需要的是具体信息：mac 地址、固定 IP 地址、子网、网关、主机路由、neutron port-id、neutron network-id、neutron subnet-id
应该将链接从网络信息中分离出来，以便更容易地实现分层结构，例如绑定
VIF 将作为一种 Link 支持
当 neutron-external-attachment-points 蓝图完成时，将支持物理链接。[1]
VLAN 将作为另一种类型的 Link 支持
添加一个“services”部分，用于与特定网络或接口无关的网络服务。主要用途将是 DNS 服务器。
将来，可以将绑定作为另一种类型的 Link 支持，指向多个其他 Link

备选方案¶

Neutron 可以创建 network_data.json，Nova 只需要下载该文件并将其添加到元数据服务和 configdrive。

数据模型影响¶

无

REST API 影响¶

从元数据服务获取网络信息的示例 API

GET: http://169.254.169.254/openstack/$VERSION/metadata/network_data.json

JSON 响应

{
"links": [
    { // Example of VIF
        "id": "interface2", // Generic, generated ID
        "type": "vif", // Can be 'vif', 'phy' or (future) 'bond'
        "ethernet_mac_address": "a0:36:9f:2c:e8:70", // MAC from Neutron
        "vif_id": "e1c90e9f-eafc-4e2d-8ec9-58b91cebb53d",
        "mtu": 1500 // MTU for links
    },
    { // Example of physical NICs
        "id": "interface0",
        "type": "phy",
        "ethernet_mac_address": "a0:36:9f:2c:e8:80",
        "mtu": 9000
    },
    {
        "id": "interface1",
        "type": "phy",
        "ethernet_mac_address": "a0:36:9f:2c:e8:81",
        "mtu": 9000
    },
    { // Bonding two NICs together (future support)
        "id": "bond0",
        "type": "bond",
        "bond_links": [
            "interface0",
            "interface1"
        ],
        "ethernet_mac_address": "a0:36:9f:2c:e8:82",
        "bond_mode": "802.1ad",
        "bond_xmit_hash_policy": "layer3+4",
        "bond_miimon": 100

    },
    { // Overlaying a VLAN on a bond (future support)
        "id": "vlan0",
        "type": "vlan",
        "vlan_link": "bond0",
        "vlan_id": 101,
        "vlan_mac_address": "a0:36:9f:2c:e8:80",
        "vif_id": "e1c90e9f-eafc-4e2d-8ec9-58b91cebb53f"
    },
],
"networks": [
    { // Standard VM VIF networking
        "id": "private-ipv4",
        "type": "ipv4",
        "link": "interface0",
        "ip_address": "10.184.0.244",
        "netmask": "255.255.240.0",
        "routes": [
            {
                "network": "10.0.0.0",
                "netmask": "255.0.0.0",
                "gateway": "11.0.0.1"
            },
            {
                "network": "0.0.0.0",
                "netmask": "0.0.0.0",
                "gateway": "23.253.157.1"
            }
        ],
        "network_id": "da5bb487-5193-4a65-a3df-4a0055a8c0d7"
    },
    { // IPv6
        "id": "private-ipv4",
        "type": "ipv6",
        "link": "interface0",
        // supports condensed IPv6 with CIDR netmask
        "ip_address": "2001:cdba::3257:9652/24",
        "routes": [
            {
                "network": "::",
                "netmask": "::",
                "gateway": "fd00::1"
            },
            {
                "network": "::",
                "netmask": "ffff:ffff:ffff::",
                "gateway": "fd00::1:1"
            },
        ],
        "network_id": "da5bb487-5193-4a65-a3df-4a0055a8c0d8"
    },
    { // One IP on a VLAN over a bond of two physical NICs (future support)
        "id": "publicnet-ipv4",
        "type": "ipv4",
        "link": "vlan0",
        "ip_address": "23.253.157.244",
        "netmask": "255.255.255.0",
        "dns_nameservers": [
            "69.20.0.164",
            "69.20.0.196"
        ],
        "routes": [
            {
                "network": "0.0.0.0",
                "netmask": "0.0.0.0",
                "gateway": "23.253.157.1"
            }
        ],
        "network_id": "62611d6f-66cb-4270-8b1f-503ef0dd4736"
    }
],
"services": [
    {
        "type": "dns",
        "address": "8.8.8.8"
    },
    {
        "type": "dns",
        "address": "8.8.4.4"
    }
]
}

相同的 JSON 将存储在 configdrive 下的 openstack/$VERSION/network_data.json 中

安全影响¶

JSON 数据可以比以往任何时候都为客户实例提供更多关于网络的见解。在锁定环境中，用户可能能够在元数据服务中看到比他们可能通过其他方式发现的更多网络详细信息。例如，一个加固的 SELinux VM。应该记录一个安全说明。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

无

其他部署者影响¶

意图是这个网络元数据可以被 cloud-init 和其他实例内代理用来以更高级的方式配置网络。根据代理的实现，网络配置可能会与之前此新元数据生成的配置略有不同。例如，网络接口的命名方式可能与操作系统命名的方式略有不同。这在很大程度上取决于对 cloud-init 等代理的更改。

开发人员影响¶

无

实现¶

负责人¶

主要负责人: JoshNang
其他贡献者: claxton JayF

工作项¶

从 neutron 获取基本网络信息到元数据服务（列表：mac、IP、子网、网关、neutron-port-id、host-routes）
将上述信息添加到 ConfigDrive 中作为“network_data”

依赖项¶

无

测试¶

将添加单元和功能测试来检查是否返回网络数据。

文档影响¶

更改元数据服务 api 以请求和返回网络数据。

参考资料¶

[1] https://blueprints.launchpad.net/neutron/+spec/neutron-external-attachment-points

[2] https://etherpad.openstack.org/p/IcehouseNovaMetadataService

API：将 neutron 配置代理到 guest 实例