ironic_python_agent.hardware_managers.container module

class ironic_python_agent.hardware_managers.container.ContainerHardwareManager

Bases: HardwareManager

Hardware manager for container-based cleanup.

HARDWARE_MANAGER_NAME = 'ContainerHardwareManager'

HARDWARE_MANAGER_VERSION = '1'

container_clean_step(node, ports, container_url, pull_options=None, run_options=None)

evaluate_hardware_support()

Determine if container runner exists and return support level.

get_clean_steps(node, ports)

Dynamically generate cleaning steps.

get_deploy_steps(node, ports)

Get a list of deploy steps with priority.

Returns a list of steps. Each step is represented by a dict:

{
 'interface': the name of the driver interface that should execute
              the step.
 'step': the HardwareManager function to call.
 'priority': the order steps will be run in. Ironic will sort all
             the deploy steps from all the drivers, with the largest
             priority step being run first. If priority is set to 0,
             the step will not be run during deployment
             automatically, but may be requested via deploy
             templates.
 'reboot_requested': Whether the agent should request Ironic reboots
                     the node via the power driver after the
                     operation completes.
 'argsinfo': arguments specification.
}

If multiple hardware managers return the same step name, the following logic will be used to determine which manager’s step “wins”:

• Keep the step that belongs to HardwareManager with highest HardwareSupport (larger int) value.

• If equal support level, keep the step with the higher defined priority (larger int).

• If equal support level and priority, keep the step associated with the HardwareManager whose name comes earlier in the alphabet.

The steps will be called using hardware.dispatch_to_managers and handled by the best suited hardware manager. If you need a step to be executed by only your hardware manager, ensure it has a unique step name.

node and ports can be used by other hardware managers to further determine if a deploy step is supported for the node.

Parameters:

• node – Ironic node object

• ports – list of Ironic port objects

Returns:

a list of deploying steps, where each step is described as a dict as defined above

get_service_steps(node, ports)

Get a list of service steps.

Returns a list of steps. Each step is represented by a dict:

{
 'interface': the name of the driver interface that should execute
              the step.
 'step': the HardwareManager function to call.
 'priority': the order steps will be run in if executed upon
             similar to automated cleaning or deployment.
             In service steps, the order comes from the user request,
             but this similarity is kept for consistency should we
             further extend the capability at some point in the
             future.
 'reboot_requested': Whether the agent should request Ironic reboots
                     the node via the power driver after the
                     operation completes.
 'abortable': Boolean value. Whether the service step can be
              stopped by the operator or not. Some steps may
              cause non-reversible damage to a machine if interrupted
              (i.e firmware update), for such steps this parameter
              should be set to False. If no value is set for this
              parameter, Ironic will consider False (non-abortable).
}

If multiple hardware managers return the same step name, the following logic will be used to determine which manager’s step “wins”:

• Keep the step that belongs to HardwareManager with highest HardwareSupport (larger int) value.

• If equal support level, keep the step with the higher defined priority (larger int).

• If equal support level and priority, keep the step associated with the HardwareManager whose name comes earlier in the alphabet.

The steps will be called using hardware.dispatch_to_managers and handled by the best suited hardware manager. If you need a step to be executed by only your hardware manager, ensure it has a unique step name.

node and ports can be used by other hardware managers to further determine if a step is supported for the node.

Parameters:

• node – Ironic node object

• ports – list of Ironic port objects

Returns:

a list of service steps, where each step is described as a dict as defined above