diff options
Diffstat (limited to 'doc/source/contributor/hardware_managers.rst')
| -rw-r--r-- | doc/source/contributor/hardware_managers.rst | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/source/contributor/hardware_managers.rst b/doc/source/contributor/hardware_managers.rst index ee3d6357..f0f78f7d 100644 --- a/doc/source/contributor/hardware_managers.rst +++ b/doc/source/contributor/hardware_managers.rst @@ -10,6 +10,13 @@ deploying your own hardware manager. IPA ships with :doc:`GenericHardwareManager </admin/hardware_managers>`, which implements basic cleaning and deployment methods compatible with most hardware. +.. warning:: + Some functionality inherent in the stock hardware manager cleaning methods + may be useful in custom hardware managers, but should not be inherently + expected to also work in custom managers. Examples of this are clustered + filesystem protections, and cleaning method fallback logic. Custom hardware + manager maintainers should be mindful when overriding the stock methods. + How are methods executed on HardwareManagers? --------------------------------------------- Methods that modify hardware are dispatched to each hardware manager in @@ -149,6 +156,18 @@ function with extra parameters. be set to whichever manager has a higher hardware support level and then use the higher priority in the case of a tie. +In some cases, it may be necessary to create a customized cleaning step to +take a particular pattern of behavior. Those doing such work may want to +leverage file system safety checks, which are part of the stock hardware +managers. + +.. code-block:: python + + def custom_erase_devices(self, node, ports): + for dev in determine_my_devices_to_erase(): + hardware.safety_check_block_device(node, dev.name) + my_special_cleaning(dev.name) + Custom HardwareManagers and Deploying ------------------------------------- |