ironic-specs/specs/juno-implemented/new-management-interface.rst
Devananda van der Veen d6caa9a083 Reorganize specs tree
* Move liberty -> approved
* Move completed liberty specs to liberty-implemented
* Move kilo -> kilo-implemented
* Move juno -> juno-implemented
* Move kilo-archive -> backlog (moving these to approved causes test
  failures because the template changed since kilo)
* Reword the header for the index page
* Update unit tests to look at the new "approved" folder

** NOTE **

This patch does not create placeholders in the previous locations
for each spec. This will be done in the following patch so that the
history is preserved. Both patches must be landed together so that web
links are not broken for long.

Change-Id: I61f02731150ea944eafaa8c6ea702210364b3478
Implements: blueprint feature-based-releases
2015-08-05 06:57:53 -07:00

5.9 KiB

New driver ManagementInterface

https://blueprints.launchpad.net/ironic/+spec/new-management-interface

This blueprint consolidates the work needed for the creation of a new driver interface for management-like operations and a new REST API resource to expose those methods.

Problem description

Almost all Power Interfaces (except the SSH Power Interface) expose a method to set the boot device on their Vendor Passthru interface, this blueprint intends to promote this method to an official interface.

Setting the boot device doesn't fit into the current driver interfaces, even if right now it's part of the Vendor Passthru of the Power Interfaces it's not actually a power operation, so this blueprint will also include the creation of a new interface called Management Interface where such management operations can be exposed.

As noted in the first paragraph the SSH Power Interface doesn't expose any method to set the boot device, so this is going to be implemented as part of this blueprint. We need all drivers to adhere to the new interface so that it's consistent.

As for the API changes, a new 'management' subresource will be added to nodes resource of the REST API and will expose ways to get the supported boot devices and set/get the boot device of a given node. In the future more operations could be added to the management interface, for example: get_sensor_data()[1], update_firmware(), get_firmware_list(), etc...

Proposed change

  • Create a new ManagementInterface which expose the methods:
    • validate() - To validate driver-specific management information. (E.g if the node has the right credentials already set)
    • set_boot_device() - To set the boot device for a specific node.
    • get_boot_device() - To get the current boot device of a specific node.
    • get_supported_boot_devices() - To get a list of the supported boot devices by that driver.
  • Port the set_boot_device() method from the Vendor Passthru interface to the new interface.
  • Add a ManagementInterface for ssh, and implement the set_boot_device() for it
  • Create a new /nodes/<uuid>/management/boot_device subresource in the REST API to expose ways to the client to {set,get} the boot device for a node.
    • To set the boot device:

      PUT {'boot_device': 'pxe'}

      /nodes/<uuid>/management/boot_device[?persistent=<bool>]

      If the request was completed successfully HTTP 204 (No Content) is returned.

      If an invalid or not supported boot device parameter is passed it should return 400 (Bad Request).

      The "persistent" flag can be set to indicate whether the boot device changes should be applied for the next boot only or to all future boots. By default persistent will be False.

    • To get the current boot device:

      GET /nodes/<uuid>/management/boot_device

      Returns a dictionary with the boot device and if it's persistent or not. E.g:

      {'boot_device': 'pxe', 'persistent': True}

      If 'boot_device' is unknown the value of it will be None (The seamicro python library doesn't seem to expose a way to get the current boot device, only set it[3]).

      If 'persistent' is unknown the value of it will be None (The pyghmi method to get the current boot device and doesn't indicate whether it's persistent or not[3]. For setting the boot device, it's possible to indicate whether it's persistent or not).

    • To get the supported boot devices:

      GET /nodes/<uuid>/management/boot_device/supported

      This will return a list of all supported boot devices (not the boot order).

  • Update the Ironic client and library to support the new API resource.

Alternatives

Continue to use the Vendor Passthru interface.

Data model impact

None

REST API impact

  • A new /nodes/<uuid>/management/boot_device subresource will be added to the API, requests to set or get the boot device for a node should go there so that methods like set_boot_device won't be exposed via the vendor_passthru anymore.
  • The nodes/<uuid>/validate will include the management interface.

Driver API impact

  • The new ManagementInterface will be included in the standardized interfaces group.
  • The ipmitool, ipminative, seamicro and ssh drivers are going to be updated to use this new interface.

Nova driver impact

None

Security impact

None

Other end user impact

None

Scalability impact

None

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

lucasagomes

Other contributors:

None

Work Items

  • Create the new ManagementInterface base class.
  • Port the set_boot_device() method from the Vendor Passthru interface of the ipmitool, ipminative, seamicro drivers to the new interface.
  • Implement the missing methods on the ssh, ipmitool, ipminative, seamicro drivers.
  • Implement the REST API to expose the new interface.

Dependencies

None

Testing

  • Unit tests will be added/updated to cover the changes.
  • Tempest tests will be added to Ironic to ensure that the new /nodes/<uuid>/management/boot_device is working properly.

Documentation Impact

The Architecture documentation should be updated to include the new Management Interface.

References

[1] http://specs.openstack.org/openstack/ironic-specs/specs/juno/send-data-to-ceilometer.html [2] https://github.com/seamicro/python-seamicroclient/blob/master/seamicroclient/v2/servers.py#L24 [3] https://github.com/stackforge/pyghmi/blob/master/pyghmi/ipmi/command.py#L123