Jump to: navigation, search

Difference between revisions of "Ironic/blueprints/ironic-snmp-power-driver"

(One intermediate revision by the same user not shown)
Line 14: Line 14:
 
* Other classes of physical equipment (network switches and middleboxes for example) do not offer integrated power management.
 
* Other classes of physical equipment (network switches and middleboxes for example) do not offer integrated power management.
  
This blueprint proposes widening Ironic’s capabilities by adding support for a class of power controllers that are implement SNMP interfaces, including smart PDUs with network connectivity. For example, remote control of node power can be achieved by enabling or disabling sockets on a rack power strip.
+
This blueprint proposes a new power driver.  Ironic's capabilities would be widened by adding support for a class of power controllers that implement SNMP interfaces, including smart PDUs with network connectivity. For example, remote control of node power can be achieved by enabling or disabling sockets on a rack power strip.
  
 
SNMP appears to be a good choice for the following reasons:
 
SNMP appears to be a good choice for the following reasons:
Line 25: Line 25:
 
==Use Case Scenarios==
 
==Use Case Scenarios==
  
A cost-conscious user may want to use bare metal compute without the addition expense of server equipment that supports integrated power management.
+
A cost-conscious user may want to use bare metal compute without the additional expense of server equipment that supports integrated power management.
  
A power-conscious user may want to power off sections of network while attached server hardware is also out of service.
+
A power-conscious user may want to power off sections of network while attached server hardware is also out of service.  Note that this blueprint only proposes power management for baremetal compute node instances, although a sufficiently general mechanism could be extended to arbitrary physical devices.
  
 
==Detailed Design==
 
==Detailed Design==
Line 36: Line 36:
  
 
* '''snmp_driver''' - The class of power driver to interface with.  This will identify a vendor-specific MIB interface to use.
 
* '''snmp_driver''' - The class of power driver to interface with.  This will identify a vendor-specific MIB interface to use.
* '''snmp_address''' - The IP address of the power driver.
+
* '''snmp_address''' - The hostname or IP address of the power driver.
 
* '''snmp_community''' - The write community to use for changing power state.
 
* '''snmp_community''' - The write community to use for changing power state.
* '''snmp_outlet''' - The power outlet number (1-based) on the power device.
+
* '''snmp_outlet''' - The power outlet number on the power device.
  
 
===Requirements===
 
===Requirements===
This project would have a dependency on [http://pysnmp.sourceforge.net/ the PySNMP module]
+
This project would have a dependency on [http://pysnmp.sourceforge.net/ the PySNMP module].  The dependency could be relaxed to a dynamic runtime dependency that only applied if the configuration was enabled.  This would also enable unit testing without importing <nowiki>PySNMP</nowiki>.
  
 
===Assumptions===
 
===Assumptions===

Revision as of 13:48, 28 April 2014

[ DRAFT ]

Summary

Ironic's ability to control power to physical hardware is limited to server hardware that embeds an implementation of power management.

This is limiting in two ways:

  • Commodity motherboards do not integrate a baseboard management controller, particularly cost-sensitive ones.
  • Other classes of physical equipment (network switches and middleboxes for example) do not offer integrated power management.

This blueprint proposes a new power driver. Ironic's capabilities would be widened by adding support for a class of power controllers that implement SNMP interfaces, including smart PDUs with network connectivity. For example, remote control of node power can be achieved by enabling or disabling sockets on a rack power strip.

SNMP appears to be a good choice for the following reasons:

  1. As an interface it cannot change between device firmware versions, whereas human-readable interfaces (HTTP, CLI) could.
  2. It appears to be the protocol with widest deployment.

The proposal would use data definitions to support SNMP power control interfaces from multiple vendors. Power usage monitoring is also possible with smart PDUs, but is beyond the scope of this proposal.

Use Case Scenarios

A cost-conscious user may want to use bare metal compute without the additional expense of server equipment that supports integrated power management.

A power-conscious user may want to power off sections of network while attached server hardware is also out of service. Note that this blueprint only proposes power management for baremetal compute node instances, although a sufficiently general mechanism could be extended to arbitrary physical devices.

Detailed Design

The proposed design would use PySNMP to interface with power control devices.

For compute servers, power control addressing data would be attached as additional attributes to Ironic node driver info:

  • snmp_driver - The class of power driver to interface with. This will identify a vendor-specific MIB interface to use.
  • snmp_address - The hostname or IP address of the power driver.
  • snmp_community - The write community to use for changing power state.
  • snmp_outlet - The power outlet number on the power device.

Requirements

This project would have a dependency on the PySNMP module. The dependency could be relaxed to a dynamic runtime dependency that only applied if the configuration was enabled. This would also enable unit testing without importing PySNMP.

Assumptions

  • All network addresses and outlet numberings for power control devices would be maintained as a statically-mapped data.
  • The management interfaces of power control devices would be reachable from Ironic services.

Test Plan

A set of unit tests is required:

  • Validation that all parameters are supplied and (where appropriate) in a valid data format.
  • Mocking of the PySNMP interface to ensure that the correct outputs are generated for a given stimulus.
  • Validation that any exceptions generated by the PySNMP interface are handled appropriately.

Hardware Qualification

Every vendor defines a different vendor-specific MIB to implement SNMP-based power control. Qualification of a new product requires details on the MIB layout (which is published information), and access to test equipment.

It may be useful to maintain a list of supported vendors and devices.