openstack
/
ironic-specs
Code Issues Proposed changes

Follow-up on DPU Management Change 

Fixing a few typos and make some changes which I noted in the
specification as it was being reviewed.

Nothing major, just clean-up.

Change-Id: Ic8b3b371488d97396f413168dd1720d4ec47c73c
This commit is contained in:
Julia Kreger 2023-05-09 14:19:50 -07:00
parent cc621b075f
commit c2de25bb23
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
specs/approved/smartnics-to-dpus.rst
View File

@ -8,10 +8,9 @@
The evolution of the Smart NICs to DPUs The evolution of the Smart NICs to DPUs
======================================= =======================================
https://bugs.launchpad.net/ironic/+bug/2019043
https://storyboard.openstack.org/#!/story/XXXXXXX The ideas behind "Smart NICs" have evolved as time has progressed.
The ideas behind "Smart NICs" has evolved as time has progressed.
And honestly it feels like we in the Ironic community helped drive some And honestly it feels like we in the Ironic community helped drive some
of that improvement in better, more secure directions. Hey! We said we of that improvement in better, more secure directions. Hey! We said we
@ -57,7 +56,7 @@ behavior of a Fibre Channel HBA.
Composible Hardware Composible Hardware
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
The phrase "Composible Hardware" is unfortuantely overloaded. This is best The phrase "Composible Hardware" is unfortunately overloaded. This is best
described as use of a centralized service to "compose" hardware for use by described as use of a centralized service to "compose" hardware for use by
a workload. A good way to view this, at least in a classical sense is through a workload. A good way to view this, at least in a classical sense is through
an API or application constructing a cohesive functioning computer resource an API or application constructing a cohesive functioning computer resource
@ -89,8 +88,8 @@ Given the overall general purpose capabilities of DPUs and increased
focus of specific computing workload offloads, we need to be careful focus of specific computing workload offloads, we need to be careful
to specifically delineate which use cases we're attempting to support, to specifically delineate which use cases we're attempting to support,
and also not try to assume one implies the other. In other words, DPUs do and also not try to assume one implies the other. In other words, DPUs do
offer some interesting capabilities towards Compisible Hardware, however offer some interesting capabilities towards Composible Hardware, however
it is inhernetly not full configuration as the underlying host is still it is inherently not full configuration as the underlying host is still
a static entity. a static entity.
.. NOTE:: .. NOTE::
@ -98,7 +97,7 @@ a static entity.
cards are Graphics Processing Units. While there does not appear to be cards are Graphics Processing Units. While there does not appear to be
any explicit movement into supporting that specific offload, some vendors any explicit movement into supporting that specific offload, some vendors
are working on highly specific processing cards such those as performing are working on highly specific processing cards such those as performing
protocol/signal translation. They may, or may not be able to have a protocol/signal translation. They may, or may not be able to have
an operating system or provisioned application. an operating system or provisioned application.
The problem The problem
@ -128,7 +127,7 @@ But to do so:
requesting the BMC on the card to permit the overall host OS to requesting the BMC on the card to permit the overall host OS to
Access the card's BMC. This is achievable with an IPMI raw command, but Access the card's BMC. This is achievable with an IPMI raw command, but
against the card's BMC. against the card's BMC.
2) Then you would apply BMC firmware updates, to the card's BMC/ 2) Then you would apply BMC firmware updates, to the card's BMC
Today this would boot IPA, and perform it from the host OS, which also Today this would boot IPA, and perform it from the host OS, which also
means that we're going to need to interact with the overall host BMC, means that we're going to need to interact with the overall host BMC,
and boot the baremetal machine overall. and boot the baremetal machine overall.
@ -188,9 +187,14 @@ child devices.
query filter to return nodes with parents as well. query filter to return nodes with parents as well.
* Introduction of a new step field value, ``execute_on_child_nodes`` which * Introduction of a new step field value, ``execute_on_child_nodes`` which
can be submitted, which includes a list of child nodes, or a value of can be submitted. The default value is False. Steps which return CLEANWAIT,
``true`` which would result on the defined step to execute upon all child i.e. steps which expect asynchronous return will not be permitted under
nodes. normal conditions, however this will be avaiable via a configuration option.
* Introduction of a new step field value, ``limit_child_node_execution``,
which accepts a list of node UUIDs to allow filtering and constraint
of steps on some nodes. Sepcifically, this is largely separate from the
``execute_on_child_nodes`` field due to JSON Schema restrictions.
* Introduction of the ability to call a vendor passthrough interface * Introduction of the ability to call a vendor passthrough interface
as a step. In the case of some smartnics, they need the ability to as a step. In the case of some smartnics, they need the ability to
@ -220,7 +224,8 @@ child devices.
based upon their experiences. based upon their experiences.
With these high level and workflow changes, it will be much easier for an With these high level and workflow changes, it will be much easier for an
operator to orchustrate management actions across an single operator to orchestrate management actions across an single node to extend
further into distinct devices within the whole of the system.
In this model, the same basic rules for child nodes would apply, they may have In this model, the same basic rules for child nodes would apply, they may have
their own power supplies and their own power control, and thus have inherent their own power supplies and their own power control, and thus have inherent
@ -364,11 +369,6 @@ GET /v1/nodes/?include_children=True
Returns a list of base nodes with all child nodes child nodes, useful for Returns a list of base nodes with all child nodes child nodes, useful for
a big picture view of all things Ironic is responsible for. a big picture view of all things Ironic is responsible for.
GET /v1/nodes/?is_child_node=True
Returns a list of only nodes with a parent node defined.
Standard /v1/nodes access contstraints and behaivors will still apply.
GET /v1/nodes/ GET /v1/nodes/
The view will by default return only nodes where the ``parent_node`` field The view will by default return only nodes where the ``parent_node`` field