Merge "Cleaning with custom hardware manager docs"

This commit is contained in:
Jenkins 2015-08-19 22:20:43 +00:00 committed by Gerrit Code Review
commit 47f497f75b

View File

@ -160,6 +160,61 @@ may want to implement are list_hardware_info(), to add additional hardware
the GenericHardwareManager is unable to identify and erase_devices(), to
erase devices in ways other than ATA secure erase or shredding.
Custom HardwareManagers and Cleaning
------------------------------------
One of the reasons to build a custom hardware manager is to expose extra steps
in Ironic Cleaning [4]_. A node will perform a set of cleaning steps any
time the node is deleted by a tenant or moved from MANAGEABLE state to
AVAILABLE state. If the node is using an agent\_\* driver, Ironic will query
IPA for a list of clean steps that should be executed on the node. IPA
will dispatch a call to `get_clean_steps()` on all available hardware managers
and then return the combined list to Ironic.
To expose extra clean steps, the custom hardware manager should have a function
named `get_clean_steps()` which returns a list of dictionaries. The
dictionaries should be in the form::
{
// A function on the custom hardware manager
'step': 'upgrade_firmware',
// An integer priority. Largest priorities are executed first
'priority': 10,
// Should always be the deploy interface
'interface': 'deploy',
// Request the node to be rebooted out of band by Ironic when the
// step completes successfully
'reboot_requested': False
}
Then, you should create functions which match each of the `step` keys in
the clean steps you return. The functions will take two parameters: `node`,
a dictionary representation of the Ironic node, and `ports`, a list of
dictionary representations of the Ironic ports attached to `node`.
When a clean step is executed in IPA, the `step` key will be sent to the
hardware managers in hardware support order, using
`hardware.dispatch_to_managers()`. For each hardware manager, if the manager
has a function matching the `step` key, it will be executed. If the function
returns a value (including None), that value is returned to Ironic and no
further managers are called. If the function raises
`IncompatibleHardwareMethodError`, the next manager will be called. If the
function raises any other exception, the command will be considered failed,
the command result's error message will be set to the exception's error
message, and no further managers will be called. An example step::
def upgrade_firmware(self, node, ports):
if self._device_exists():
# Do the upgrade
return 'upgraded firmware'
else:
raise errors.IncompatibleHardwareMethodError()
.. note::
If two managers return steps with the same `step` key, the priority will
be set to whichever manager has a higher hardware support level and then
use the higher priority in the case of a tie.
Versioning
~~~~~~~~~~
Each hardware manager has a name and a version. This version is used during
@ -174,15 +229,15 @@ is '1.0'. You should change this version string any time you update your
hardware manager. You can also change the name your hardware manager presents
by creating a class variable called HARDWARE_MANAGER_NAME, which is a string.
The name defaults to the class name. Currently IPA only compares version as a
string; any version change whatsoever will enduce cleaning to restart.
string; any version change whatsoever will induce cleaning to restart.
Priority
~~~~~~~~
A hardware manager has a single overall priority, which should be based on how
well it supports a given piece of hardware. At load time, IPA executes
`evaluate_hardware_support()` on each method. This method should return an int
representing hardware manager priority, based on what it detects about the
platform its running on. Suggested values are included in the
`evaluate_hardware_support()` on each hardware manager. This method should
return an int representing hardware manager priority, based on what it detects
about the platform it's running on. Suggested values are included in the
`HardwareSupport` class. Returning a value of 0 aka `HardwareSupport.NONE`,
will prevent the hardware manager from being used. IPA will never ship a
hardware manager with a priority higher than 3, aka
@ -204,6 +259,7 @@ References
.. [1] CoreOS PXE Images - https://coreos.com/docs/running-coreos/bare-metal/booting-with-pxe/
.. [2] CoreOS Cloud Init - https://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config/
.. [3] DIB Element for IPA - https://github.com/openstack/diskimage-builder/tree/master/elements/ironic-agent
.. [4] Ironic Cleaning - http://docs.openstack.org/developer/ironic/deploy/cleaning.html
Indices and tables
==================