Ironic 逻辑名称

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/ironic/+spec/logical-names

Ironic 中所有追踪的信息都通过 UUID 进行。这对于人类来说不太友好。我们应该支持通过逻辑名称引用节点，而不仅仅是当前通过 UUID 引用节点的方式。这应该在 REST API 和我们的命令行客户端中得到支持。

问题描述

使用 Ironic 的操作员和其他用户发现使用 UUID 引用 Ironic 追踪的实体既繁琐又容易出错。

然而，计算机和极客们更喜欢通过规范标识符（即 UUID）来追踪事物。

虽然人类更有可能使用命令行工具，但计算机更有可能使用 REST API。然而，情况也可能相反，因此 API 和命令行客户端都需要更新以支持节点的逻辑名称。

能够为节点分配语义含义（例如数据中心位置（即“DC6”），或节点功能（即“数据库”））对于协助操作员管理网络中的节点非常有用。节点的语义标识符类似于节点的hostname，并且可能与之相关。

例如，逻辑名称“DC6-db-17”可能与 UUID 为“9e592cbe-e492-4e4f-bf8f-4c9e0ad1868f”的节点相关联。在与 ironic 的所有交互中，可以使用节点的 UUID 或逻辑名称来标识特定的节点。

提议的变更

我们建议在 ironic 中添加一个新的概念，即 <逻辑名称>，它可以与 <节点 UUID> 互换使用。在可以指定 <节点 UUID> 的任何地方，如果该节点存在这样的关联，我们应该能够指定 <逻辑名称>。这应该适用于 REST API 和 python-ironicclient。

在 REST API 级别，用于设置/检索节点字段的机制将用于设置/检索节点的逻辑名称。

在 python-ironiclient 级别，将添加支持以管理节点与 <逻辑名称> 之间的关联。有关详细信息，请参见下文。

当需要更改接口时，例如对象上的新属性、字典中的新键或 POST 数据中的新字段时，<逻辑名称> 将被称为“name”（除非已使用该名称）。这是为了与其他的 OpenStack API 保持一致。

备选方案

无

数据模型影响

<逻辑名称> 和 <节点 UUID> 之间应该存在 1:1 的映射。我们可以将 <逻辑名称> 视为 <节点 UUID> 的别名。

当包含这些更改的 ironic 版本运行到现有的安装上时，数据库将被升级以支持将 <逻辑名称> 字段添加到节点对象中。

逻辑名称和 UUID 之间的关联需要作为节点对象上的新属性存储。

如果未设置逻辑名称，则此字段将为 None。

什么是逻辑名称？

此更改为 ironic 引入了 <逻辑名称> 的概念，以便可以将人类可读的名称与节点关联。此 <逻辑名称> 应该是 hostname 安全的，也就是说，节点逻辑名称也应该可以用作实例的hostname。为了实现这一点，应该使用以下参考来定义什么是有效的 <逻辑名称>：[wikipedia:hostname]、[RFC952] 和 [RFC1123]。

简单地说，这意味着 <逻辑名称> 可以是 1 到 63 个字符长，有效的字符是 [a-z0-9] 和 ‘-‘，但 <逻辑名称> 不能以 ‘-‘ 开头或结尾。

作为正则表达式，这可以表示为：<逻辑名称> == [a-z0-9]([a-z0-9-]{0,61}[a-z0-9]|[a-z0-9]{0,62})?

注意：承认有效的 <逻辑名称> 也可能是有效的 <节点 UUID>，这可能会导致混淆。因此，如果逻辑名称是有效的 UUID，则将被拒绝为无效。

搜索顺序（实现提示）

由于我们现在有两种选项来指定节点——逻辑名称和节点 UUID——因此建议实施以下搜索顺序来定义 ironic 的行为。提供以下伪代码以协助实施

if is_uuid_like(value)

# 像 UUID 一样处理它

else if is_hostname_like(value)

# 像逻辑名称一样处理它

else

# 格式无效，引发错误

REST API 影响

需要修改许多现有的 API 以支持使用 <logical_name>。

以下 API 将在新的 JSON 主体参数中添加名为“name”

  • DELETE /v1/nodes

  • PATCH /v1/nodes

  • GET /v1/nodes/validate

以下 API 将在响应主体中添加一个名为“name”的新字段

  • GET /v1/nodes

以下 API 将反映现有的 node_uuid 版本的 API，同时添加支持在 URL 中指定 logical_name 而不是 node_uuid

  • GET /v1/nodes/(node_logical_name)

  • PUT /v1/nodes/(node_logical_name)/maintenance

  • DELETE /v1/nodes/(node_logical_name)/maintenance

  • GET /v1/nodes/(node_logical_name)/management/boot_device

  • PUT /v1/nodes/(node_logical_name)/management/boot_device

  • GET /v1/nodes/(node_logical_name)/management/boot_device/supported

  • GET /v1/nodes/(node_logical_name)/states

  • PUT /v1/nodes/(node_logical_name)/states/power

  • PUT /v1/nodes/(node_logical_name)/states/provision

  • GET /v1/nodes/(node_logical_name)/states/console

  • PUT /v1/nodes/(node_logical_name)/states/console

  • POST /v1/nodes/(node_logical_name)/vendor_passthru

RPC API 影响

无

驱动程序 API 影响

无

Nova 驱动程序影响

此处指定的更改完全包含在 ironic 本身中。将逻辑名称的概念暴露给 ironic 之外的 Nova API 可能是非常有益的。

如果需要，将在独立的规范中解决此问题。

安全影响

无

其他最终用户影响

如果 Horizon 允许用户输入节点 UUID 并将其验证为符合特定的正则表达式，那么这很可能需要更改以支持 <节点 UUID> 或 <逻辑名称>。

python-ironicclient

在 python-ironicclient 的每个子命令中，如果可以指定节点 UIUD，我们需要能够在其位置支持逻辑名称。有关所需更改范围的详细信息，请参阅 REST API 部分。

可扩展性影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

mrda - Michael Davies <michael@the-davies.net>

工作项

  1. REST API 的添加和修改

  2. python-ironicclient 的添加和修改

依赖项

无

测试

单元测试足以验证此更改的真实性

升级和向后兼容性

如上所述，当包含此更改的代码运行到以前的 Ironic 安装上而没有此更改时，数据库需要更新其模式以添加额外的字段“name”。

文档影响

需要更新 Ironic API 和 python-ironicclient 的在线文档以配合此更改。

参考资料

对此更改的需求在巴黎 Kilo Summit 上进行了讨论（参考 https://etherpad.openstack.org/p/kilo-ironic-making-it-simple）