启动配置 API

https://bugs.launchpad.net/ironic/+bug/2044561

问题描述

目前,Ironic conductor 会在与其关联的 HTTP 服务器的公共目录中生成各种启动文件(例如 iPXE 脚本)。然后,使用 Neutron 的动态 DHCP 配置将节点指向正确的 HTTP 服务器。

对于独立安装,DHCP 配置通常是静态的。它在单个 conductor 的情况下工作良好,但在多 conductor 设置中无法开箱即用:节点根本不知道从哪个 HTTP 服务器启动。

提议的变更

将向 Ironic 添加新的 API 以提供启动配置文件,iPXE 将作为参考实现。这种方法将允许我们依赖现有的哈希环将请求定向到正确的 conductor。有关更多详细信息,请参阅 REST API 影响

这是在 iPXE、独立 Ironic 和静态 DHCP 配置的情况下启动过程的工作方式

  1. 节点的 iPXE 固件启动新的 DHCP 会话。

  2. DHCP 请求到达 Ironic 的 DHCP 服务器(通常是 dnsmasq)。

  3. DHCP 服务器响应一个 IP 地址和通配符启动脚本。此启动脚本将位于任意一个 conductor 旁边,很可能与 DHCP 服务器共存。

  4. 启动脚本会将 iPXE 固件定向到以下形式的 URL:http://<IP>:6385/v1/boot/<MAC>/boot.ipxe,其中 <IP> 是任何 Ironic API 实例的 IP(最有可能与 HTTP 服务器共存),<MAC> 是节点的 MAC 地址。

  5. Ironic API 将通过 MAC 地址找到节点,并将请求定向到正确的 conductor。

  6. 负责该节点的 conductor 返回 iPXE 脚本。

备选方案

一种提议的方法是 启用 conductor 之间的协调。虽然在更多情况下可能有用,但该提案在独立设置中存在 JSON RPC 乘法问题。

解决此问题的另一种方法是引入管理的独立 DHCP。朝着这个方向迈出的第一步已经完成:Ironic 可以管理它的 dnsmasq 服务器。在多 conductor 设置中,这可能意味着在同一网络上存在多个 dnsmasq 实例,这是一种潜在的问题设置。当前实现仍然需要 conductor 之间的某种协调或定期任务来禁用对无关 conductor 的 DHCP 服务器的访问。

一个更好,但也是最复杂的选择是使用具有 API 访问权限的现有 DHCP 服务器。例如 Kea。主要问题是:这样的复杂更改可能对 Ironic 来说太多了。贡献者已经人手不足。此外,我听说只有付费插件才能提供我们所需的功能。

数据模型影响

状态机影响

REST API 影响

GET /v1/boot/<MAC>/<NAME>

<MAC>

节点的任何 NIC 的 MAC 地址。

<NAME>

要请求的配置名称(例如 boot.ipxe)。

API 将通过 MAC 地址找到节点,检查其配置状态,并在成功时调用 get_boot_config RPC。如果失败,将返回通用的 HTTP 404,以避免泄露任何进一步的信息。

注意

整个 API 分支 /v1/boot 将不会进行版本控制,因为我们预计固件实现不支持额外的标头或任何合理的版本协商。

客户端 (CLI) 影响

无。API 不面向最终用户。

“openstack baremetal” CLI

“openstacksdk”

RPC API 影响

def get_boot_config(self, context, node_id, name):
    """Request a boot configuration file."""

驱动程序 API 影响

“boot”接口将获得一个新的调用

def get_boot_config(self, task, name):
    """Request a boot configuration file.

    :param task: a TaskManage instance with a shared lock.
    :param name: configuration name.
    :raises: NotFound if the configuration cannot be produced.
    """
    raise exception.UnsupportedDriverExtension(
        driver=task.node.driver, extension='get_boot_config')

将添加一个参考实现到 iPXE 启动接口,支持名为 boot.ipxe 的配置 - iPXE 脚本。

Nova 驱动程序影响

Ramdisk 影响

安全影响

新的 API 将允许通过其 MAC 地址枚举处于特定状态的节点。某些信息可能通过启动配置泄露。已经可以通过查找 API 进行枚举,并且配置可以通过 HTTP 服务器中的启动脚本泄露。我们将建议操作员限制对新的 API 端点的访问。

此外,启动接口的 validate 将不会被调用,以避免暴露有关节点字段的信息。

其他最终用户影响

可扩展性影响

通过 API 提供启动脚本比从 HTTP 服务器提供效率稍低。担心影响的操作员可以选择使用旧方法。

我们将在实现中避免使用独占锁或启动额外的线程。初始版本将只是从磁盘读取现有文件。

性能影响

其他部署者影响

该功能将通过几个新选项进行配置

[pxe]ipxe_use_boot_config_api = False

启用该功能。如果为 true,生成的根 iPXE 脚本 (boot.ipxe) 将包含指向启动配置 API 的链接,而不是指向 HTTP 服务器的链接。

[pxe]ipxe_config_api_root_url = <None>

指定用于链接到启动配置 API 的根 URL。一个示例用例是使用 TLS 的 Ironic 部署:iPXE 在不重新编译固件的情况下不支持自定义证书,因此例如必须建立一个代理。

[api]restrict_boot_config = True

指示 API 仅限于处于 * WAIT 状态的节点。使用快速通道的操作员可能希望将其设置为 False。

开发人员影响

实现

负责人

主要负责人

Dmitry Tantsur (dtantsur)

工作项

TODO

依赖项

测试

我们可以将 Bifrost 切换到新的 API。Metal3 也可能在不久的将来切换到它,因为我们正在开发它的 HA 故事。

升级和向后兼容性

无。

文档影响

可能需要调整安装指南。

参考资料