部署模板¶
https://storyboard.openstack.org/#!/story/1722275
这建立在 部署步骤规范之上，以便可以通过请求一组特性来请求特定的部署步骤集。
当 Ironic 与 Nova 一起使用时，这允许最终用户选择一个 Flavor，该 Flavor 需要特定的特性集，Ironic 会将其转换为在 Ironic 中请求特定的部署步骤集。
问题描述¶
单个节点可以以多种方式配置。不同的用户工作负载需要以不同的方式配置节点。因此，操作员希望拥有一个单一的硬件池，可以重新配置以匹配每个用户的需求，而不是试图提前猜测需要多少种配置。
在本规范中，我们专注于重新配置常规硬件以匹配每个用户工作负载的需求。我们不考虑可组合硬件。
当使用 Ironic 作为后端的 Nova 实例时，目前没有办法影响 Ironic 用于配置节点的部署步骤。
示例用例¶
考虑一个具有三个磁盘的裸机节点。不同的工作负载可能需要不同的 RAID 配置。操作员希望测试他们的硬件并确定最有效的特定 RAID 配置集，并向 Nova 的用户提供该选择，以便他们可以选择最适合其工作负载的配置。
提议的变更¶
上下文：部署步骤框架¶
本规范依赖于部署步骤框架规范。部署步骤框架提供了在节点部署时可以执行的部署步骤的概念。
假设存在操作员配置的默认步骤集，这些步骤默认在每次部署时发生。每个步骤任务都有一个定义的优先级，以确定该步骤相对于其他启用的部署步骤的运行顺序。配置选项和硬编码优先级定义了任务是否默认运行。优先级决定了如果任务应该在部署期间运行，则任务何时运行。
部署模板¶
本规范引入了 部署 模板 的概念。它是节点有效特性名称到一个或多个部署步骤以及应提供给这些部署步骤的所有参数的映射。Ironic 添加了一个新的 API，供操作员指定这些 部署 模板。
要允许为给定的 Ironic 节点使用 部署 模板，您需要将部署模板的特性名称添加到每个需要启用部署模板的 Ironic 节点的 特性 列表中。如果任何启用的 部署 模板 不受该节点支持，则节点的验证必须失败。
值得注意的是，节点上设置的所有特性都同步到 Nova 的 placement API。反过来，如果用户请求一个需要特性的 flavor（该特性可能或可能不映射到部署模板），只有具有该特性集的节点才会被 Nova 的 Placement API 作为候选节点提供。
要请求在配置特定 Ironic 节点时指定的 部署 模板，将相应的特性添加到 node.instance_info 下的 特性 键中的列表中。这是 Nova 的 ironic virt 驱动程序已经为 flavor 的 extra specs 中任何必需的特性所做的操作。同样，Ironic 已经通过新的 node-traits API 验证了 node.instance_info 中的特性是操作员在 Ironic 节点上设置的特性的子集。
在配置过程中，Ironic 检查 node.instance_info 中设置的特性列表，并检查它们是否与任何 部署 模板 匹配。匹配的 部署 模板 列表随后用于扩展此特定配置操作的部署步骤列表。如部署步骤框架中已经定义的，然后将其与为所有构建默认配置的部署步骤列表组合。
步骤的执行顺序将由每个步骤的优先级定义。如果部署步骤的代码定义了 0 的部署优先级，并且该优先级未被配置选项更改，则该部署步骤默认不会执行。如果部署模板指定了优先级（如果代码具有默认优先级 0，则这是必需的），这将覆盖代码默认值和任何配置覆盖。
可以请求相同的部署步骤多次是可以接受的。这可以通过使用不同的参数多次执行部署步骤来完成，例如对多个磁盘进行分区。
请求的部署模板中的任何部署步骤都将覆盖该部署步骤的默认参数和优先级。0 是可以为任何核心部署步骤设置的唯一优先级覆盖，即您只能禁用核心步骤，而不能更改其执行顺序。
在部署模板中使用的特性名称应该是唯一的 - 没有两个部署模板应该指定相同的特性名称。
总而言之，您可以使用特性来指定额外的部署步骤，通过新 部署 模板 API 中指定的特性与部署步骤之间的映射。
当前限制¶
在将其映射回 Nova 集成时，目前需要为这些资源类和特性的组合创建一个 flavor。从长远来看，预计 Nova 将提供一个选项，允许用户在启动请求中指定特性覆盖，基于 flavor 所说的可能性。本规范对 Nova ironic virt 驱动程序没有影响，超出了已经实现以支持 node-traits 的影响。
示例¶
现在让我们看看如何通过 Nova 请求特定的部署模板。
FlavorVMXMirror 具有以下 extra specs
resource:CUSTOM_COMPUTE_A = 1trait:CUSTOM_CLASS_A = requiredtrait:CUSTOM_BM_CONFIG_BIOS_VMX_ON = requiredtrait:CUSTOM_BM_CONFIG_RAID_DISK_MIRROR = required
FlavorNoVMXStripe 具有以下 extra specs
resource:CUSTOM_COMPUTE_A = 1trait:CUSTOM_CLASS_A = requiredtrait:CUSTOM_BM_CONFIG_BIOS_VMX_OFF = requiredtrait:CUSTOM_BM_CONFIG_RAID_DISK_STRIPE = required
操作员可能已经将所有具有 COMPUTE_A 资源类的 Ironic 节点设置为具有所有这些特性
CUSTOM_BM_CONFIG_BIOS_VMX_ONCUSTOM_BM_CONFIG_BIOS_VMX_OFFCUSTOM_OTHER_TRAIT_I_AM_USUALLY_IGNOREDCUSTOM_BM_CONFIG_RAID_DISK_MIRRORCUSTOM_BM_CONFIG_RAID_DISK_STRIPE
操作员还定义了以下部署模板
{
"deploy-templates": [
{
"name": "CUSTOM_BM_CONFIG_RAID_DISK_MIRROR",
"steps": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "1",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
]
},
{
"name": "CUSTOM_BM_CONFIG_RAID_DISK_STRIPE",
"steps": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "0",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
]
},
{
"name": "CUSTOM_BM_CONFIG_BIOS_VMX_ON",
"steps": [...]
},
{
"name": "CUSTOM_BM_CONFIG_BIOS_VMX_OFF",
"steps": [...]
}
]
}
当使用 FlavorVMXMirror 创建 Nova 实例时，该 flavor 的必需特性被设置为 node.instance_info['traits']，以便 Ironic 添加在 CUSTOM_BM_CONFIG_BIOS_VMX_ON 和 CUSTOM_BM_CONFIG_RAID_DISK_MIRROR 中定义的部署步骤，并且该节点被适当地配置为需要该特定 flavor 的工作负载。
备选方案¶
替代方案¶
此设计解决了两个问题
我想请求在配置裸机服务器期间应用一些自定义配置。
确保我的实例被安排到支持请求配置的裸机节点。
与 capabilities 一样，提议的设计使用单个字段（特性）来编码配置和调度信息。另一种方法可以将这两个问题分开。
部署模板可以通过一个名称（不一定是特性）或 UUID 作为 Nova flavor 的 extra_spec 来请求，并推送到 ironic 节点的 instance_info 字段中的 deploy_templates 字段，由 nova virt 驱动程序推送。Ironic 随后将在配置期间应用请求的部署模板。
如果需要在调度过程中施加影响，这可以通过特性来提供，但这将是一个单独的问题。
调整前面的示例
FlavorVMXMirror 具有以下 extra specs
resource:CUSTOM_COMPUTE_A = 1trait:CUSTOM_BM_CONFIG_BIOS_VMX_ON = requiredtrait:CUSTOM_BM_CONFIG_RAID_DISK_MIRROR = requireddeploy_template:BIOS_VMX_ON=<?>deploy_template:BIOS_RAID_DISK_MIRROR=<?>
只有支持 CUSTOM_BM_CONFIG_BIOS_VMX_ON 和 CUSTOM_BM_CONFIG_RAID_DISK_MIRROR 特性的 ironic 节点才会被安排，并且 nova virt 驱动程序会将 instance_info.deploy_templates 设置为 BIOS_VMX_ON,BIOS_RAID_DISK_MIRROR。
这种替代方案有一些好处
它将自动支持超出我们在此处拥有的简单一个特性映射到一个部署模板的情况。例如，要支持部署模板
X，必须由节点支持特性Y和Z（而不会出现组合特性爆炸）。孤立地，配置机制在概念上更简单 - flavor 直接指定部署模板。
它可以在独立的 ironic 安装中使用，而无需引入 placement 的概念。
我们不会将特性的概念用于承载配置信息。
也有一些缺点
额外的复杂性对于现在需要将特性和部署模板都应用于 flavor 的用户和操作员。
对于 capabilities 的用户来说不太熟悉。
在
extra_specs中指定资源、特性和部署模板的 flavor 可能会让操作员和用户感到困惑。
扩展¶
本规范试图指定构建在部署步骤框架规范之上的最小可行特性。因此，许多不包含在此概念的可能扩展。
虽然您可以将标准特性用作部署模板的名称，但许多操作员可能会被迫为他们的大多数部署模板使用自定义特性。如果我们添加与每个部署模板关联的特性列表，除了基于特性的名称之外，我们可以更好地支持标准特性的用户。该特性列表将充当名称的别名，但该别名也可能由许多其他部署模板使用。节点验证将失败，如果任何单个节点的其中一个设置的特性映射到多个部署模板。为了消除歧义，哪个部署模板被请求，您可以查看所选节点特性列表中有哪些部署模板名称。对于每个部署模板，您查看任何其他可用于触发该模板的特性，最终为节点上设置的每个特性构建一个特性到部署模板的映射（某些特性不会映射到任何部署模板）。这可用于检测节点上的任何特性是否映射到多个部署模板，从而导致节点验证失败。
对于某些操作员，他们最终会创建大量的 flavor 来涵盖他们想要提供的所有可能的硬件组合。希望 Nova 最终允许操作员拥有列出可能特性的 flavor，以及默认特性集，以便最终用户可以请求他们需要的特定特性集，以及所选的 flavor。
虽然 ironic inspector 可用于确保每个节点都赋予了适当的特性集，但将如此多的特性添加到每个 Ironic 节点似乎容易出错。希望在添加节点组的概念时，可以将特性应用于一组节点而不是仅应用于单个节点（可能类似于 Nova 中的主机聚合）。一个建议是使用资源类作为可能的分组，但这只是更一般问题的一部分，即将节点分组到物理网络、路由网络段、电源分配组，所有这些都映射到不同的 ironic 导体等。
有人讨论过自动检测每个节点支持哪些部署模板。但是，大多数操作员希望控制只有他们希望支持的内容才能提供的内容。
数据模型影响¶
将添加两个新的数据库表用于部署模板
CREATE TABLE deploy_templates (
id INT(11) NOT NULL AUTO_INCREMENT,
name VARCHAR(255) CHARACTER SET utf8 NOT NULL,
uuid varchar(36) DEFAULT NULL,
PRIMARY KEY (id),
UNIQUE KEY `uniq_deploy_templaes0uuid` (`uuid`),
UNIQUE KEY `uniq_deploy_templaes0name` (`name`),
)
CREATE TABLE deploy_template_steps (
deploy_template_id INT(11) NOT NULL,
interface VARCHAR(255) NOT NULL,
step VARCHAR(255) NOT NULL,
args TEXT NOT NULL,
priority INT NOT NULL,
KEY `deploy_template_id` (`deploy_template_id`),
KEY `deploy_template_steps_interface_idx` (`interface`),
KEY `deploy_template_steps_step_idx` (`step`),
CONSTRAINT `deploy_template_steps_ibfk_1` FOREIGN KEY (`deploy_template_id`) REFERENCES `deploy_templates` (`id`),
)
deploy_template_steps.args 列是一个 JSON 编码的步骤参数对象，JsonEncodedDict。
将添加新的 ironic.objects.deploy_template.DeployTemplate 和 ironic.objects.deploy_template_step.DeployTemplateStep 对象到对象模型。部署模板对象将提供支持，用于查找与任何特性列表匹配的部署模板列表。
状态机影响¶
除了部署步骤规范中已经指定的内容之外，没有影响。
REST API 影响¶
将添加一个新的 REST API 端点用于部署模板，隐藏在新的 API 微版本之后。该端点将支持标准的 CRUD 操作。
在以下 API 中，UUID 或特性名称被接受作为部署模板的标识。
列出所有¶
列出所有部署模板
GET /v1/deploy-templates
请求：空
响应
{
"deploy-templates": [
{
"name": "CUSTOM_BM_CONFIG_RAID_DISK_MIRROR",
"steps": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "1",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
],
"uuid": "8221f906-208b-44a5-b575-f8e8a59c4a84"
},
{
...
}
]
}
响应代码：200、400
策略：admin 或 observer。
显示一个¶
显示单个部署模板
GET /v1/deploy-templates/<deploy template ident>
请求：空
响应
{
"name": "CUSTOM_BM_CONFIG_RAID_DISK_MIRROR",
"steps": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "1",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
],
"uuid": "8221f906-208b-44a5-b575-f8e8a59c4a84"
}
响应代码：200、400、404
策略：admin 或 observer。
创建¶
创建一个部署模板
POST /v1/deploy-templates
请求
{
"name": "CUSTOM_BM_CONFIG_RAID_DISK_MIRROR",
"steps": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "1",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
],
}
响应：与显示一个相同。
响应码：201, 400, 409
策略：admin。
更新¶
更新部署模板
PATCH /v1/deploy-templates/{deploy template ident}
请求
[
{
"op": "replace",
"path": "/name"
"value": "CUSTOM_BM_CONFIG_RAID_DISK_MIRROR"
},
{
"op": "replace",
"path": "/steps"
"value": [
{
"interface": "raid",
"step": "create_configuration",
"args": {
"logical_disks": [
{
"size_gb": "MAX",
"raid_level": "1",
"is_root_volume": true
}
],
"delete_configuration": true
},
"priority": 10
}
]
}
]
响应：与显示一个相同。
响应码：200, 400, 404, 409
策略：admin。
字段 name 和 steps 可以更新。字段 uuid 不能更新。
删除¶
删除部署模板
DELETE /v1/deploy-templates/{deploy template ident}
请求：空
响应：空
响应码：204, 400, 404
策略：admin。
客户端 (CLI) 影响¶
“ironic” CLI¶
无
“openstack baremetal” CLI¶
在以下每个命令中，都可以接受 UUID 或特征名称作为部署模板的标识。
对于 --steps 参数，需要提供包含 JSON 数据的文件的路径或 -。如果传递 -，则 JSON 数据将从标准输入读取。
列出部署模板
openstack baremetal deploy template list
显示单个部署模板
openstack baremetal deploy template show <deploy template ident>
创建一个部署模板
openstack baremetal deploy template create --name <trait> --steps <deploy steps>
更新部署模板
openstack baremetal deploy template set <deploy template ident> [--name <trait] [--steps <deploy steps>]
删除部署模板
openstack baremetal deploy template delete <deploy template ident>
在这些命令中，<deploy steps> 采用 JSON 格式，并支持与 clean steps 相同的输入方法 - 字符串、文件或标准输入。
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
现有的特征集成已经足够，现在在启动时选择的特征变得更加重要。
Ramdisk 影响¶
无
安全影响¶
允许通过部署模板自定义部署过程可能会打开安全漏洞。这些风险通过以下观察得到缓解
只有管理员可以定义每个节点的允许特征集。
只有管理员可以定义每个 Nova flavor 的请求特征集，并允许其他用户访问该 flavor。
只有管理员可以通过 API 创建或更新部署模板。
部署模板中引用的部署步骤在驱动程序代码中定义。
其他最终用户影响¶
用户需要能够发现每个 Nova flavor 在部署自定义方面的作用。除了检查请求的特征并与 ironic 部署模板 API 交叉引用外，这被认为超出范围。操作员应提供关于每个 flavor 属性的充分文档。通过特征名称查找部署模板应该有所帮助。
可扩展性影响¶
部署期间增加的活动可能会对 ironic 的可扩展性产生负面影响。
性能影响¶
部署期间增加的活动可能会对 ironic 的性能产生负面影响，包括增加配置节点所需的时间。
其他部署者影响¶
部署者需要确保 Nova flavor 设置了所需的特征。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Mark Goddard (mgoddard)
其他贡献者
Dmitry Tantsur (dtantsur)
Ruby Loo (rloo)
工作项¶
添加用于部署模板的 DB 表和对象
编写代码以将特征映射到部署模板
扩展节点验证以检查所有部署模板是否有效
添加用于添加部署模板的 API
扩展 CLI 以支持上述 API
编写测试
依赖项¶
测试¶
将添加单元测试到 ironic。Tempest API 测试将执行部署模板 CRUD API。
升级和向后兼容性¶
部署步骤 API 端点将隐藏在新的 API 版本之后。
在正常操作期间，当 ironic conductor 未被固定时，即使调用节点状态 API 的用户使用的微版本不支持部署模板，部署模板也将用于在节点配置期间添加部署步骤。
在升级期间，当 ironic conductor 被固定时，部署模板将不会用于在节点配置期间添加部署步骤。
文档影响¶
关于如何配置 Nova flavor 和部署模板的管理员指南
更新 API 参考
更新 CLI 文档
