fixed minor typo
Add IPMI data to the node definition in our database

This is presently hard-coded into the node, and tracks the three critical
details for communicating with the BMC: which host, user, and password to use;
the later two options are permitted to be NULL, if you hate security on
your network. ;)

This simply emplaces the data, and does not yet provide commands to manipulate
or act on that data.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement IPMI credential updates

This adds a command, documentation and tests, to allow users to update the
node IPMI details using the Razor client.  This simply allows updates, making
it practical to associate existing nodes with their BMC/IPMI lan or
lanplus interface.

This, in turn, allows us to start managing power state for the target node.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add BMC GUID queries and IPMI infrastructure

This implements the basic infrastructure for running synchronous IPMI commands
against a remote host, using external command execution.  That is leveraged to
execute the BMC GUID query, as a proof that the concept works correctly.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement power state query, and `on?` helper, for IPMI

This implements the next IPMI operation, testing the remote power state, to
determine if the machine is on or off.  This is a trivial read-only query.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement "boot from this device once" IPMI support

This adds support for setting a (temporary) boot device via IPMI; the most
likely use-case for Razor is to set it to `pxe` on a node as part of a higher
reliability infrastructure.  (eg: boot local by default, override to PXE on
demand only. :)

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Support capturing the "last observed power state" of nodes

This extends the node object to capture the last observed power state -- and
the time it was observed -- as part of the stored data.  This will allow us to
store the results of observing the power state of the node via IPMI.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Wire up node power state update logic via IPMI

This adds a simple logic wrapper that handles errors and updates power state
in a central fashion to the node object.  This is also the entry point that we
can use to trigger background processing by sending that message,
asynchronously, to the node instance.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement the TorqueBox scheduled job class to trigger power polling

This implements the logic behind monitoring power state for nodes: trigger a
regular update in the background for any eligible node.  We implement the Ruby
class that TorqueBox triggers from the scheduled job poller here.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Deploy the scheduled IPMI job into TorqueBox

This wires up the task scheduler and the IPMI power state update job to work
together, so that we kick off a power state check every five minutes.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>