Deploy Templates
This builds on the deployment steps framework spec (I2f68170e6741b0dbb6d5fbd5315a3be9fd7b28a7) such that it is possible to request a particular set of deployment steps by requesting a set of traits. Change-Id: I7a56db52873655b15efe83282df8f864d932ca79 Story: 1722275 Task: 10626
This commit is contained in:
parent
8722aa582a
commit
8e95563a68
|
@ -0,0 +1,721 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
================
|
||||||
|
Deploy Templates
|
||||||
|
================
|
||||||
|
|
||||||
|
https://storyboard.openstack.org/#!/story/1722275
|
||||||
|
|
||||||
|
This builds on the `deployment steps
|
||||||
|
spec <http://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html>`__,
|
||||||
|
such that it is possible to request a particular set of deployment steps by
|
||||||
|
requesting a set of traits.
|
||||||
|
|
||||||
|
When Ironic is used with Nova, this allows the end user to pick a Flavor, that
|
||||||
|
requires a specific set of traits, that Ironic turns into a request for a
|
||||||
|
specific set of deployment steps in Ironic.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
One node can be configured in many ways. Different user workloads require the
|
||||||
|
node to be configured in different ways. As such, operators would like a single
|
||||||
|
pool of hardware to be reconfigured to match each users requirements, rather
|
||||||
|
than attempting to guess how many of each configurations are required in
|
||||||
|
advance.
|
||||||
|
|
||||||
|
In this spec, we are focusing on reconfiguring regular hardware to match the
|
||||||
|
needs of each users workload. We are not considering composable hardware.
|
||||||
|
|
||||||
|
When creating a Nova instance with Ironic as the backend, there is currently no
|
||||||
|
way to influence the deployment steps used by Ironic to provision the node.
|
||||||
|
|
||||||
|
Example Use Case
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Consider a bare metal node that has three disks. Different workloads may
|
||||||
|
require different RAID configurations. Operators want to test their hardware
|
||||||
|
and determine the specific set of RAID configurations that work best, and offer
|
||||||
|
that choice to users of Nova, so they can pick the configuration that best
|
||||||
|
matches their workload.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Context: Deployment Steps Framework
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
This spec depends on the deployment steps framework spec. The deployment steps
|
||||||
|
framework provides the concept of a deployment step that may be executed when a
|
||||||
|
node is deployed.
|
||||||
|
|
||||||
|
It is assumed that there is a default set of steps that an operator configures
|
||||||
|
to happen by default on every deploy. Each step task has a priority defined, to
|
||||||
|
determine the order that that step runs relative to other enabled deploy steps.
|
||||||
|
Configuration options and hard-coded priorities define if a task runs by
|
||||||
|
default or not. The priority says when a task runs if the task should run
|
||||||
|
during deployment.
|
||||||
|
|
||||||
|
Deploy Templates
|
||||||
|
----------------
|
||||||
|
|
||||||
|
This spec introduces the concept of a ``Deploy Template``. It is a mapping
|
||||||
|
from a valid trait name for the node to one or more Deployment Steps and all
|
||||||
|
the arguments that should be given to those deployment steps. There is a new
|
||||||
|
API added to Ironic for Operators to specify these ``Deploy Templates``.
|
||||||
|
|
||||||
|
To allow a ``Deploy Template`` for a given Ironic node, you add the
|
||||||
|
trait name of the deploy template to the ``traits`` list on each Ironic
|
||||||
|
node that needs the deploy template enabled. The validation of the node must
|
||||||
|
fail if any of the enabled ``Deploy Templates`` are not supported on that node.
|
||||||
|
|
||||||
|
It is worth noting that all traits set on the node are synchronised to Nova's
|
||||||
|
placement API. In turn, should a user request a flavor that requires a trait
|
||||||
|
(that may or may not map to a deploy template) only nodes that have the trait
|
||||||
|
set will be offered as candidates by Nova's Placement API.
|
||||||
|
|
||||||
|
To request the specified ``Deploy Template`` when you provision a particular
|
||||||
|
Ironic node, the corresponding trait is added to a list in
|
||||||
|
``node.instance_info`` under the key of ``traits``. This is what Nova's ironic
|
||||||
|
virt driver already does for any required trait in the flavor's extra specs for
|
||||||
|
that instance. Again, Ironic already validates that the traits in
|
||||||
|
``node.instance_info`` are a subset of the traits that the Operator has set on
|
||||||
|
the Ironic node, via the new node-traits API.
|
||||||
|
|
||||||
|
During the provisioning process Ironic checks the list of traits set in
|
||||||
|
``node.instance_info`` and checks if they match any ``Deploy Templates``. The
|
||||||
|
list of matching ``Deploy Templates`` are then used to extend the list of
|
||||||
|
deployment steps for this particular provision operation. As already
|
||||||
|
defined in the deployment steps framework, this is then combined with the list
|
||||||
|
of deployment steps from what is configured to happen by default for all
|
||||||
|
builds.
|
||||||
|
|
||||||
|
The order in which the steps are executed will be defined by the priority of
|
||||||
|
each step. If the code for a deploy step defines a deploy priority of 0, and
|
||||||
|
that is not changed by a configuration option, that deploy step does not
|
||||||
|
get executed by default. If a deploy template specifies a priority
|
||||||
|
(this is required if the code has a default priority of 0), this overrides both
|
||||||
|
the code default and any configuration override.
|
||||||
|
|
||||||
|
It is acceptable to request the same deploy step more than once. This could be
|
||||||
|
done to execute a deploy step multiple times with different arguments, for
|
||||||
|
example to partition multiple disks.
|
||||||
|
|
||||||
|
Any deploy step in a requested deploy template will override the default
|
||||||
|
arguments and priority for that deploy step. 0 is the only priority override
|
||||||
|
that can be set for any of the core deploy steps, i.e. you can only disable the
|
||||||
|
core step, you can't change the order of its execution.
|
||||||
|
|
||||||
|
Trait names used in Deploy Templates should be unique - no two deploy templates
|
||||||
|
should specify the same trait name.
|
||||||
|
|
||||||
|
In summary, you can use traits to specify additional deploy steps, by the
|
||||||
|
mapping between traits and deploy steps specified in the new
|
||||||
|
``Deploy Templates`` API.
|
||||||
|
|
||||||
|
Current Limitations
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
When mapping this back to Nova integration, currently there would need to be
|
||||||
|
a flavor for each of these combinations of traits and resource_class. Longer
|
||||||
|
term Nova is expected to offer the option of a user specifying an override
|
||||||
|
trait on a boot request, based on what the flavor says is possible. This spec
|
||||||
|
has no impact on the Nova ironic virt driver beyond what is already implemented
|
||||||
|
to support `node-traits
|
||||||
|
<http://specs.openstack.org/openstack/ironic-specs/specs/approved/node-traits.html>`__.
|
||||||
|
|
||||||
|
Example
|
||||||
|
-------
|
||||||
|
|
||||||
|
Lets now look at how we could request a particular deploy template via Nova.
|
||||||
|
|
||||||
|
``FlavorVMXMirror`` has these extra specs:
|
||||||
|
|
||||||
|
* ``resource:CUSTOM_COMPUTE_A = 1``
|
||||||
|
* ``trait:CUSTOM_CLASS_A = required``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_BIOS_VMX_ON = required``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_RAID_DISK_MIRROR = required``
|
||||||
|
|
||||||
|
``FlavorNoVMXStripe`` has these extra specs:
|
||||||
|
|
||||||
|
* ``resource:CUSTOM_COMPUTE_A = 1``
|
||||||
|
* ``trait:CUSTOM_CLASS_A = required``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_BIOS_VMX_OFF = required``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_RAID_DISK_STRIPE = required``
|
||||||
|
|
||||||
|
It's possible the operator has set all of the Ironic nodes with ``COMPUTE_A``
|
||||||
|
as the resource class to have all of these traits assigned:
|
||||||
|
|
||||||
|
* ``CUSTOM_BM_CONFIG_BIOS_VMX_ON``
|
||||||
|
* ``CUSTOM_BM_CONFIG_BIOS_VMX_OFF``
|
||||||
|
* ``CUSTOM_OTHER_TRAIT_I_AM_USUALLY_IGNORED``
|
||||||
|
* ``CUSTOM_BM_CONFIG_RAID_DISK_MIRROR``
|
||||||
|
* ``CUSTOM_BM_CONFIG_RAID_DISK_STRIPE``
|
||||||
|
|
||||||
|
The Operator has also defined the following 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
|
||||||
|
}
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"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": [...]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
When a Nova instance is created with ``FlavorVMXMirror``, the required traits
|
||||||
|
for that flavor are set on ``node.instance_info['traits']`` such that Ironic
|
||||||
|
adds the deploy steps defined in ``CUSTOM_BM_CONFIG_BIOS_VMX_ON`` and
|
||||||
|
``CUSTOM_BM_CONFIG_RAID_DISK_MIRROR``, and the node is appropriately configured
|
||||||
|
for workloads that want that specific flavor.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Alternative approach
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
This design solves two problems:
|
||||||
|
|
||||||
|
1. I want to request some custom configuration to be applied to my bare metal
|
||||||
|
server during provisioning.
|
||||||
|
2. Ensure that my instance is scheduled to a bare metal node that supports
|
||||||
|
the requested configuration.
|
||||||
|
|
||||||
|
As with capabilities, the proposed design uses a single field (traits) to
|
||||||
|
encode configuration and scheduling information. An alternative approach could
|
||||||
|
separate these two concerns.
|
||||||
|
|
||||||
|
Deploy templates could be requested by a name (not necessarily a trait) or UUID
|
||||||
|
as a nova flavor ``extra_spec``, and pushed to a ``deploy_templates`` field in
|
||||||
|
the ironic node's ``instance_info`` field by the nova virt driver. Ironic would
|
||||||
|
then apply the requested deploy templates during provisioning.
|
||||||
|
|
||||||
|
If some influence in the scheduling process is required, this could be provided
|
||||||
|
by traits, but this would be a separate concern.
|
||||||
|
|
||||||
|
Adapting the earlier example:
|
||||||
|
|
||||||
|
``FlavorVMXMirror`` has these extra specs:
|
||||||
|
|
||||||
|
* ``resource:CUSTOM_COMPUTE_A = 1``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_BIOS_VMX_ON = required``
|
||||||
|
* ``trait:CUSTOM_BM_CONFIG_RAID_DISK_MIRROR = required``
|
||||||
|
* ``deploy_template:BIOS_VMX_ON=<?>``
|
||||||
|
* ``deploy_template:BIOS_RAID_DISK_MIRROR=<?>``
|
||||||
|
|
||||||
|
Only ironic nodes supporting the ``CUSTOM_BM_CONFIG_BIOS_VMX_ON`` and
|
||||||
|
``CUSTOM_BM_CONFIG_RAID_DISK_MIRROR`` traits would be scheduled to, and the
|
||||||
|
nova virt driver would set ``instance_info.deploy_templates`` to
|
||||||
|
``BIOS_VMX_ON,BIOS_RAID_DISK_MIRROR``.
|
||||||
|
|
||||||
|
There are some benefits to this alternative approach:
|
||||||
|
|
||||||
|
* It would automatically support cases beyond the simple one trait mapping to
|
||||||
|
one deploy template case we have here. For example, to support deploy
|
||||||
|
template ``X``, features ``Y`` and ``Z`` must be supported by the node
|
||||||
|
(without combinatorial trait explosions).
|
||||||
|
* In isolation, the configuration mechanism is conceptually simpler - the
|
||||||
|
flavor specifies a deploy template directly.
|
||||||
|
* It would work in standalone ironic installs without introducing concepts from
|
||||||
|
placement.
|
||||||
|
* We don't overload the concept of traits for carrying configuration
|
||||||
|
information.
|
||||||
|
|
||||||
|
There are also some drawbacks:
|
||||||
|
|
||||||
|
* Additional complexity for users and operators that now need to apply both
|
||||||
|
traits and deploy templates to flavors.
|
||||||
|
* Less familiar for users of capabilities.
|
||||||
|
* Having flavors that specify resources, traits and deploy templates in
|
||||||
|
``extra_specs`` could leave operators and users scratching their heads.
|
||||||
|
|
||||||
|
Extensions
|
||||||
|
~~~~~~~~~~
|
||||||
|
|
||||||
|
This spec attempts to specify the minimum viable feature that builds on top
|
||||||
|
of the deployment steps framework specification. As such, there are many
|
||||||
|
possible extensions to this concept that are not being included:
|
||||||
|
|
||||||
|
* While you can use standard traits as names of the deploy templates, it is
|
||||||
|
likely that many operators will be forced into using custom traits for most
|
||||||
|
of their deploy templates. We could better support the users of standard
|
||||||
|
traits if we added a list of traits associated with each deploy template,
|
||||||
|
in addition to the trait based name. This list of traits will act as an alias
|
||||||
|
for the name of the deploy template, but this alias may also be used
|
||||||
|
by many other deploy templates. The node validate will fail if for any
|
||||||
|
individual node one of traits set maps to multiple deploy templates.
|
||||||
|
To disambiguate which deploy template is requested, you can look at what
|
||||||
|
deploy template names are in the chosen node's trait list. For each deploy
|
||||||
|
template you look at any other traits that can be used to trigger that
|
||||||
|
template, eventually building up a trait to deploy template mapping for each
|
||||||
|
trait set on the node (some traits will not map to any deploy template).
|
||||||
|
That can be used to detect if any of the traits on the node map to multiple
|
||||||
|
deploy templates, causing the node validate to fail.
|
||||||
|
|
||||||
|
* For some operators, they will end up creating a crazy number of flavors to
|
||||||
|
cover all the possible combinations of hardware they want to offer. It is
|
||||||
|
hoped Nova will eventually allow operators to have flavors that list possible
|
||||||
|
traits, and a default set of traits, such that end users can request the
|
||||||
|
specific set of traits they require in addition to the chosen flavor.
|
||||||
|
|
||||||
|
* While ironic inspector can be used to ensure each node is given an
|
||||||
|
appropriate set of traits, it feels error prone to add so many traits to each
|
||||||
|
Ironic node. It is hoped when a concept of node groups is added, traits could
|
||||||
|
be applied to a group of nodes instead of only applying traits to individual
|
||||||
|
nodes (possibly in a similar way to host aggregates in Nova). One suggestion
|
||||||
|
was to use the Resource Class as a possible grouping, but that is only a very
|
||||||
|
small part of the more general issue of groups nodes to physical networks,
|
||||||
|
routed network segments, power distribution groups, all mapping to different
|
||||||
|
ironic conductors, etc.
|
||||||
|
|
||||||
|
* There were discussions about automatically detecting which Deploy
|
||||||
|
Templates each of the nodes supported. However most operators will want to
|
||||||
|
control what is available to only the things they wish to support.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Two new database tables will be added for deploy templates::
|
||||||
|
|
||||||
|
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`),
|
||||||
|
)
|
||||||
|
|
||||||
|
The ``deploy_template_steps.args`` column is a JSON-encoded object of step
|
||||||
|
arguments, ``JsonEncodedDict``.
|
||||||
|
|
||||||
|
New ``ironic.objects.deploy_template.DeployTemplate`` and
|
||||||
|
``ironic.objects.deploy_template_step.DeployTemplateStep`` objects will be
|
||||||
|
added to the object model. The deploy template object will provide support for
|
||||||
|
looking up a list of deploy templates that match any of a list of trait names.
|
||||||
|
|
||||||
|
State Machine Impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
No impact beyond that already specified in the deploy steps specification.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
A new REST API endpoint will be added for deploy templates, hidden behind a new
|
||||||
|
API microversion. The endpoint will support standard CRUD operations.
|
||||||
|
|
||||||
|
In the following API, a UUID or trait name is accepted for a deploy template's
|
||||||
|
identity.
|
||||||
|
|
||||||
|
List all
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
List all deploy templates::
|
||||||
|
|
||||||
|
GET /v1/deploy-templates
|
||||||
|
|
||||||
|
Request: empty
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
"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"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
...
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
||||||
|
Response codes: 200, 400
|
||||||
|
|
||||||
|
Policy: admin or observer.
|
||||||
|
|
||||||
|
Show one
|
||||||
|
~~~~~~~~
|
||||||
|
|
||||||
|
Show a single deploy template::
|
||||||
|
|
||||||
|
GET /v1/deploy-templates/<deploy template ident>
|
||||||
|
|
||||||
|
Request: empty
|
||||||
|
|
||||||
|
Response::
|
||||||
|
|
||||||
|
{
|
||||||
|
"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"
|
||||||
|
}
|
||||||
|
|
||||||
|
Response codes: 200, 400, 404
|
||||||
|
|
||||||
|
Policy: admin or observer.
|
||||||
|
|
||||||
|
Create
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
|
Create a deploy template::
|
||||||
|
|
||||||
|
POST /v1/deploy-templates
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
{
|
||||||
|
"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
|
||||||
|
}
|
||||||
|
],
|
||||||
|
}
|
||||||
|
|
||||||
|
Response: as for show one.
|
||||||
|
|
||||||
|
Response codes: 201, 400, 409
|
||||||
|
|
||||||
|
Policy: admin.
|
||||||
|
|
||||||
|
Update
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
|
Update a deploy template::
|
||||||
|
|
||||||
|
PATCH /v1/deploy-templates/{deploy template ident}
|
||||||
|
|
||||||
|
Request::
|
||||||
|
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"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
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
|
||||||
|
Response: as for show one.
|
||||||
|
|
||||||
|
Response codes: 200, 400, 404, 409
|
||||||
|
|
||||||
|
Policy: admin.
|
||||||
|
|
||||||
|
The ``name`` and ``steps`` fields can be updated. The ``uuid`` field cannot.
|
||||||
|
|
||||||
|
Delete
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
|
Delete a deploy template::
|
||||||
|
|
||||||
|
DELETE /v1/deploy-templates/{deploy template ident}
|
||||||
|
|
||||||
|
Request: empty
|
||||||
|
|
||||||
|
Response: empty
|
||||||
|
|
||||||
|
Response codes: 204, 400, 404
|
||||||
|
|
||||||
|
Policy: admin.
|
||||||
|
|
||||||
|
Client (CLI) impact
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
"ironic" CLI
|
||||||
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
"openstack baremetal" CLI
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
In each of the following commands, a UUID or trait name is accepted for the
|
||||||
|
deploy template's identity.
|
||||||
|
|
||||||
|
For the ``--steps`` argument, either a path to a file containing the JSON data
|
||||||
|
or ``-`` is required. If ``-`` is passed, the JSON data will be read from
|
||||||
|
standard input.
|
||||||
|
|
||||||
|
List deploy templates::
|
||||||
|
|
||||||
|
openstack baremetal deploy template list
|
||||||
|
|
||||||
|
Show a single deploy template::
|
||||||
|
|
||||||
|
openstack baremetal deploy template show <deploy template ident>
|
||||||
|
|
||||||
|
Create a deploy template::
|
||||||
|
|
||||||
|
openstack baremetal deploy template create --name <trait> --steps <deploy steps>
|
||||||
|
|
||||||
|
Update a deploy template::
|
||||||
|
|
||||||
|
openstack baremetal deploy template set <deploy template ident> [--name <trait] [--steps <deploy steps>]
|
||||||
|
|
||||||
|
Delete a deploy template::
|
||||||
|
|
||||||
|
openstack baremetal deploy template delete <deploy template ident>
|
||||||
|
|
||||||
|
In these commands, ``<deploy steps>`` are in JSON format and support the same
|
||||||
|
input methods as clean steps - string, file or standard input.
|
||||||
|
|
||||||
|
RPC API impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Driver API impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Nova driver impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Existing traits integration is enough, only now the selected traits on boot
|
||||||
|
become more important.
|
||||||
|
|
||||||
|
Ramdisk impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Allowing the deployment process to be customised via deploy templates could
|
||||||
|
open up security holes. These risks are mitigated, as seen through the
|
||||||
|
following observations:
|
||||||
|
|
||||||
|
* Only admins can define the set of allowed traits for each node.
|
||||||
|
* Only admins can define the set of requested traits for each Nova flavor, and
|
||||||
|
allow access to that flavor for other users.
|
||||||
|
* Only admins can create or update deploy templates via the API.
|
||||||
|
* Deploy steps referenced in deploy templates are defined in driver code.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Users will need to be able to discover what each Nova flavor does in terms of
|
||||||
|
deployment customisation. Beyond checking requested traits and
|
||||||
|
cross-referencing with the ironic deploy templates API, this is deemed to be
|
||||||
|
out of scope. Operators should provide sufficient documentation about the
|
||||||
|
properties of each flavor. The ability to look up a deploy template by trait
|
||||||
|
name should help here.
|
||||||
|
|
||||||
|
Scalability impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Increased activity during deployment could have a negative impact on the
|
||||||
|
scalability of ironic.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Increased activity during deployment could have a negative impact on the
|
||||||
|
performance of ironic, including increasing the time required to provision a
|
||||||
|
node.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Deployers will need to ensure that Nova flavors have required traits set
|
||||||
|
appropriately.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Mark Goddard (mgoddard)
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
|
||||||
|
* Dmitry Tantsur (dtantsur)
|
||||||
|
* Ruby Loo (rloo)
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Add DB tables and objects for deploy templates
|
||||||
|
* Write code to map traits to deploy templates
|
||||||
|
* Extend node validation to check all deploy templates are valid
|
||||||
|
* Add API to add deploy templates
|
||||||
|
* Extend CLI to support above API
|
||||||
|
* Write tests
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
* Node traits spec
|
||||||
|
http://specs.openstack.org/openstack/ironic-specs/specs/approved/node-traits.html
|
||||||
|
* Deploy steps spec
|
||||||
|
http://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Unit tests will be added to ironic. Tempest API tests will exercise the deploy
|
||||||
|
templates CRUD API.
|
||||||
|
|
||||||
|
Upgrades and Backwards Compatibility
|
||||||
|
====================================
|
||||||
|
|
||||||
|
The deploy steps API endpoint will be hidden behind a new API version.
|
||||||
|
|
||||||
|
During normal operation when the ironic conductor is not pinned, deploy
|
||||||
|
templates will be used to add deploy steps during node provisioning, even if
|
||||||
|
the caller of the node state API uses a microversion that does not support
|
||||||
|
deploy templates.
|
||||||
|
|
||||||
|
During an upgrade when the ironic conductor is pinned, deploy templates will
|
||||||
|
not be used to add deploy steps during node provisioning.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
* Admin guide on how to configure Nova flavors and deploy templates
|
||||||
|
* Update API ref
|
||||||
|
* Update CLI docs
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
* http://specs.openstack.org/openstack/ironic-specs/specs/11.1/deployment-steps-framework.html
|
||||||
|
* http://specs.openstack.org/openstack/ironic-specs/specs/approved/node-traits.html
|
|
@ -0,0 +1 @@
|
||||||
|
../approved/deploy-templates.rst
|
Loading…
Reference in New Issue