为 Neutron 网络添加级联删除的可能性

https://bugs.launchpad.net/neutron/+bug/1870319

在创建网络时，用户需要根据其需求创建其他资源，例如子网和端口。他们需要向 Neutron 服务器发出许多 API 调用才能实现这一点，这没问题。但是，删除网络不应该如此繁琐。本规范探讨了一种扩展删除 API 命令的方法，包括一个参数，以便在删除网络时级联删除所有相应的端口和子端口。

问题描述

当前，删除具有许多端口的网络需要向 Neutron 服务器发出许多 API 调用，因为用户需要先列出所有端口并删除它们，然后才能请求删除网络本身。当网络连接到路由器或具有中继端口时，需要更多的请求，因为这些也需要在网络删除之前删除。按照 OpenStackClient (OSC) 规定的简单 openstack network delete <network name or ID> 命令删除给定网络，如果网络上仍有端口在使用，则无法工作。在其他情况下，例如使用 Kuryr [1] 时，它会给 Neutron 的客户端带来很大的负载。这是 Kuryr 当前需要执行的操作才能删除“命名空间”

  • 获取子网中的 ACTIVE 端口。

  • 获取中继端口。

  • 对于每个 ACTIVE 端口，获取它连接的中继端口，并调用 Neutron 进行分离。

  • 删除端口（逐个删除；没有批量删除）。

  • 获取给定子网中的 DOWN 端口。

  • 删除端口（逐个删除；没有批量删除）。

  • 将子网从路由器分离。

  • 删除网络（这将同时删除子网）。

提议的变更

本规范的目标是添加一个新的 API，以允许级联删除给定的网络及其属于该网络的所有资源，类似于 Octavia 的 loadbalancer delete --cascade 选项 [2]。当提出的网络级联删除 API 调用发送到 Neutron 服务器时，预计它会找到并清理

  • 属于该网络中子网的所有路由器接口，

  • 其父端口位于该网络中的所有中继端口。它还需要找到并删除这些中继中的所有子端口，

  • 删除该网络中的所有端口，这尤其包括属于 nova compute 的端口，连接到虚拟机；属于 DEVICE_OWNER_DHCP、DEVICE_OWNER_DISTRIBUTED 或 DEVICE_OWNER_AGENT_GW 的端口可以省略，因为它们将已被自动删除。

完成所有清理后，网络将被最终删除。

REST API 影响

新的选项将被添加到 DELETE /v2.0/networks/{network_id} API [3]。

新的选项将被称为 cascade，并且将是一个布尔值。

如果将此新选项设置为 True，Neutron 将删除所有需要清理的资源，以成功删除给定的网络。

关于所提议的 API 的主要问题是，如果某些资源的删除失败，从而请求仅部分完成，则返回码是什么。在这种情况下，有几种可能的选项

  1. 返回 HTTP 207 Multi-status [4]，并在响应主体中，返回有关各种资源及其状态的操作列表，例如

    {
    "data": [
        {
            "message": "Success",
            "resource": {
                "name": "port",
                "id": "40ac1143-1488-42df-bf85-b0fde7598c97"
            },
            "status": 200
        },
        {
            "message": "Forbidden",
            "resource": {
                "name": "trunk",
                "id": "cb4acbfa-190a-4ad2-9227-ea8595b59b19",
            },
            "status": 403
        },
        {
            "message": "Network in use.",
            "resource": {
                "name": "network",
                "id": "a7ebad6d-fd63-4024-b7db-8c30f5f9dea3"
            },
            "status": 409
        }
    ]
}

    在这种情况下，Neutron 总是可以在第一次失败时停止，因此响应主体将始终仅包含一个或两个资源，这些资源在请求期间失败：网络和其他需要级联清理但由于某种原因失败的资源之一。

  2. 在第一次失败时停止处理级联请求，并始终返回 HTTP 409 Conflict，并提供有关发生情况的详细信息，例如“无法删除端口 <port_id>。原因：<message>”。

  3. 使此 Neutron API 异步。在这种情况下，返回码只会告诉级联删除请求是否被接受，并将由服务器处理，或者不被接受。稍后，用户可以定期检查网络是否已删除。这是 Octavia 实现负载均衡器级联删除的方式 [2]。但这将破坏 Neutron API 的文档行为 [4]。

本规范的建议是实施上述第三种解决方案，并使此 Neutron API 异步。

数据模型影响

网络的 status 字段将具有新的可能值 DELETING，这将指示网络正处于异步删除过程中。

为了避免一次执行多个 DB 事务，例如，当一个 worker 继续异步级联删除网络及其所有资源，而另一个 worker 尝试更新其中一个端口/子网时，需要添加对所有 CREATE/UPDATE/DELETE 操作以及子网的连接/断开操作的网络状态检查。

安全影响

无

性能影响

查找和删除所有要级联删除的资源将很慢，因此具有许多资源的网络的级联删除可能需要很长时间。为了最大限度地减少该时间，我们可以考虑一些优化措施，例如

  • 实施批量端口删除，

  • 如果端口是中继的子端口，则自动从中继中删除端口。

实现

负责人

主要负责人

Sharon Koech <skoech@protonmail.ch> (IRC: skoech)

工作项

  • REST API 更新。

  • ML2 插件更新。

  • CLI 更新。

  • 文档。

  • 测试和 CI 相关更改。

测试

  • 单元测试。

  • API 测试。

文档影响

用户文档

新的 API 选项必须在 Neutron api-ref 文档中记录。

参考资料