OneView drivers

Overview

HP OneView [1] is a single integrated platform, packaged as an appliance that implements a software-defined approach to managing physical infrastructure. The appliance supports scenarios such as deploying bare metal servers, for instance. In this context, the HP OneView driver for ironic enables the users of OneView to use ironic as a bare metal provider to their managed physical hardware.

Currently there are two OneView drivers:

  • iscsi_pxe_oneview
  • agent_pxe_oneview

The iscsi_pxe_oneview and agent_pxe_oneview drivers implement the core interfaces of an ironic Driver [2], and use the python-oneviewclient [3] to provide communication between ironic and OneView through OneView’s REST API.

To provide a bare metal instance there are four components involved in the process:

  • The ironic service

  • The ironic-inspector service (if using hardware inspection)

  • The ironic driver for OneView, which can be:
    • iscsi_pxe_oneview or
    • agent_pxe_oneview

  • The python-oneviewclient library

  • The OneView appliance

The role of ironic is to serve as a bare metal provider to OneView’s managed physical hardware and to provide communication with other necessary OpenStack services such as Nova and Glance. When ironic receives a boot request, it works together with the ironic OneView driver to access a machine in OneView, the python-oneviewclient being responsible for the communication with the OneView appliance.

The Mitaka version of the ironic OneView drivers only supported what we call pre-allocation of nodes, meaning that resources in OneView are allocated prior to the node being made available in ironic. This model is deprecated and will be supported until OpenStack’s Pike release. From the Newton release on, OneView drivers enables a new feature called dynamic allocation of nodes [6]. In this model, the driver allocates resources in OneView only at boot time, allowing idle resources in ironic to be used by OneView users, enabling actual resource sharing among ironic and OneView users.

Since OneView can claim nodes in available state at any time, a set of tasks runs periodically to detect nodes in use by OneView. A node in use by OneView is placed in manageable state and has maintenance mode set. Once the node is no longer in use, these tasks will make place them back in available state and clear maintenance mode.

Prerequisites

The following requirements apply for both iscsi_pxe_oneview and agent_pxe_oneview drivers:

  • OneView appliance is the HP physical infrastructure manager to be integrated with the OneView drivers.

    Minimum version supported is 2.0.

  • python-oneviewclient is a python package containing a client to manage the communication between ironic and OneView.

    Install the python-oneviewclient module to enable the communication. Minimum version required is 2.4.0 but it is recommended to install the most up-to-date version:

    $ pip install "python-oneviewclient<3.0.0,>=2.4.0"

  • ironic-inspector if using hardware inspection.

Tested platforms

  • The OneView appliance used for testing was the OneView 2.0.

  • The Enclosure used for testing was the BladeSystem c7000 Enclosure G2.

  • The drivers should work on HP Proliant Gen8 and Gen9 Servers supported by OneView 2.0 and above, or any hardware whose network can be managed by OneView’s ServerProfile. It has been tested with the following servers:

    • Proliant BL460c Gen8
    • Proliant BL460c Gen9
    • Proliant BL465c Gen8
    • Proliant DL360 Gen9 (starting with python-oneviewclient 2.1.0)

    Notice that for the driver to work correctly with Gen8 and Gen9 DL servers in general, the hardware also needs to run version 4.2.3 of iLO, with Redfish enabled.

Drivers

iscsi_pxe_oneview driver

Overview

iscsi_pxe_oneview driver uses PXEBoot for boot and ISCSIDeploy for deploy.

Configuring and enabling the driver

  1. Add iscsi_pxe_oneview to the list of enabled_drivers in your ironic.conf file. For example:

    enabled_drivers = iscsi_pxe_oneview

  2. Update the [oneview] section of your ironic.conf file with your OneView credentials and CA certificate files information.

Note

If you are using the deprecated pre-allocation feature (i.e.: dynamic_allocation is set to False on all nodes), you can disable the driver periodic tasks by setting enable_periodic_tasks=false on the [oneview] section of ironic.conf

Note

An operator can set the periodic_check_interval option in the [oneview] section to set the interval between running the periodic check. The default value is 300 seconds (5 minutes). A lower value will reduce the likelihood of races between ironic and OneView at the cost of being more resource intensive.

  1. Restart the ironic conductor service. For Ubuntu users, do:

    $ sudo service ironic-conductor restart

See [5] for more information.

Deploy process

Here is an overview of the deploy process for this driver:

  1. Admin configures the Proliant baremetal node to use iscsi_pxe_oneview driver.
  2. ironic gets a request to deploy a Glance image on the baremetal node.
  3. Driver sets the boot device to PXE.
  4. Driver powers on the baremetal node.
  5. ironic downloads the deploy and user images from a TFTP server.
  6. Driver reboots the baremetal node.
  7. User image is now deployed.
  8. Driver powers off the machine.
  9. Driver sets boot device to Disk.
  10. Driver powers on the machine.
  11. Baremetal node is active and ready to be used.

agent_pxe_oneview driver

Overview

agent_pxe_oneview driver uses PXEBoot for boot and AgentDeploy for deploy.

Configuring and enabling the driver

  1. Add agent_pxe_oneview to the list of enabled_drivers in your ironic.conf. For example:

    enabled_drivers = fake,pxe_ssh,pxe_ipmitool,agent_pxe_oneview

  2. Update the [oneview] section of your ironic.conf file with your OneView credentials and CA certificate files information.

Note

If you are using the deprecated pre-allocation feature (i.e.: dynamic_allocation is set to False on all nodes), you can disable the driver periodic tasks by setting enable_periodic_tasks=false on the [oneview] section of ironic.conf

Note

An operator can set the periodic_check_interval option in the [oneview] section to set the interval between running the periodic check. The default value is 300 seconds (5 minutes). A lower value will reduce the likelihood of races between ironic and OneView at the cost of being more resource intensive.

  1. Restart the ironic conductor service. For Ubuntu users, do:

    $ service ironic-conductor restart

See [5] for more information.

Deploy process

Here is an overview of the deploy process for this driver:

  1. Admin configures the Proliant baremetal node to use agent_pxe_oneview driver.
  2. ironic gets a request to deploy a Glance image on the baremetal node.
  3. Driver sets the boot device to PXE.
  4. Driver powers on the baremetal node.
  5. Node downloads the agent deploy images.
  6. Agent downloads the user images and writes it to disk.
  7. Driver reboots the baremetal node.
  8. User image is now deployed.
  9. Driver powers off the machine.
  10. Driver sets boot device to Disk.
  11. Driver powers on the machine.
  12. Baremetal node is active and ready to be used.

Hardware inspection

OneView drivers for ironic have the ability to do hardware inspection. Hardware inspection is the process of discovering hardware properties like memory size, CPU cores, processor architecture and disk size, of a given hardware. OneView drivers do in-band inspection, that involves booting a ramdisk on the hardware and fetching information directly from it. For that, your cloud controller needs to have the ironic-inspector component [10] running and properly enabled in ironic’s configuration file.

See [11] for more information on how to install and configure ironic-inspector.

Registering a OneView node in ironic

Nodes configured to use any of the OneView drivers should have the driver property set to iscsi_pxe_oneview or agent_pxe_oneview. Considering our context, a node is the representation of a Server Hardware in OneView, and should be consistent with all its properties and related components, such as Server Hardware Type, Server Profile Template, Enclosure Group, etc. In this case, to be enrolled, the node must have the following parameters:

  • In driver_info
    • server_hardware_uri: URI of the Server Hardware on OneView.
    • dynamic_allocation: Boolean value to enable or disable (True/False) dynamic allocation for the given node. If this parameter is not set, the driver will consider the pre-allocation model to maintain compatibility on ironic upgrade. The support for this key will be dropped in the Pike release, where only dynamic allocation will be used.
  • In properties/capabilities
    • server_hardware_type_uri: URI of the Server Hardware Type of the Server Hardware.
    • server_profile_template_uri: URI of the Server Profile Template used to create the Server Profile of the Server Hardware.
    • enclosure_group_uri (optional): URI of the Enclosure Group of the Server Hardware.

To enroll a node with any of the OneView drivers, do:

$ ironic node-create -d $DRIVER_NAME

To update the driver_info field of a newly enrolled OneView node, do:

$ ironic node-update $NODE_UUID add \
  driver_info/server_hardware_uri=$SH_URI

To update the properties/capabilities namespace of a newly enrolled OneView node, do:

$ ironic node-update $NODE_UUID add \
  properties/capabilities=server_hardware_type_uri:$SHT_URI,enclosure_group_uri:$EG_URI,server_profile_template_uri=$SPT_URI

In order to deploy, ironic will create and apply, at boot time, a Server Profile based on the Server Profile Template specified on the node to the Server Hardware it represents on OneView. The URI of such Server Profile will be stored in driver_info.applied_server_profile_uri field while the Server is allocated to ironic.

The Server Profile Templates and, therefore, the Server Profiles derived from them MUST comply with the following requirements:

  • The option MAC Address in the Advanced section of Server Profile/Server Profile Template should be set to Physical option;
  • Their first Connection interface should be:
    • Connected to ironic’s provisioning network and;
    • The Boot option should be set to primary.

Node ports should be created considering the MAC address of the first Interface of the given Server Hardware.

Note

Old versions of ironic using pre-allocation model (before Newton release) and nodes with dynamic_allocation flag disabled shall have their Server Profiles applied during node enrollment and can have their ports created using the Virtual MAC addresses provided on Server Profile application.

To tell ironic which NIC should be connected to the provisioning network, do:

$ ironic port-create -n $NODE_UUID -a $MAC_ADDRESS

For more information on the enrollment process of an ironic node, see [4].

For more information on the definitions of Server Hardware, Server Profile, Server Profile Template and other OneView entities, refer to [1] or browse Help in your OneView appliance menu.

Note

Ironic manages OneView machines either when they have a Server Profile applied by the driver or when they don’t have any Server Profile. Trying to change the power state of the machine in OneView without first assigning a Server Profile will lead to allowing Ironic to revert the power state change. Ironic will NOT change the power state of machines which the Server Profile was applied by another OneView user.

Migrating from pre-allocation to dynamic allocation

The migration of a node from an ironic deployment using pre-allocation model to the new dynamic allocation model can be done by using ironic-oneview-cli facilities to migrate nodes (further details on [8]). However, the same results can be achieved using the ironic CLI as explained below.

Checking if a node can be migrated

It is recommended to migrate nodes which are in a stable provision state. That means the conductor is not performing an operation with the node, what can impact in the execution of a migration. The possible stable provision_state values [9] are: enroll, manageable, available, active, error, clean failed and inspect failed.

Dynamic allocation mode changes the way a Server Profile is associated with a node. In pre-allocation mode, when a node is registered in ironic, there must be a Server Profile applied to the Server Hardware represented by the given node what means, from the OneView point of view, the hardware is in use. In the dynamic allocation mode a Server Hardware is associated only when the node is in use by the Compute service or the OneView itself. As a result, there are different steps to perform if the node has an instance provisioned, in other words, when the provisioning_state is set to active.

Note

Verify if the node has not already been migrated checking if there is a dynamic_allocation field set to True in the driver_info namespace doing:

$ ironic node-show  --fields driver_info

Migrating nodes in active state

List nodes that are in active state doing:

$ ironic node-list --provision-state active --fields uuid driver_info

Execute the following steps for each node:

  1. Identify the Server Hardware UUID looking at server_hardware_uri property (formatted as /rest/server-hardware/<server-hardware-uuid>) in the node’s driver_info namespace doing:

    $ ironic node-show <node-uuid> --fields driver_info

  2. Log into OneView and find the Server Hardware searching for the Server Hardware UUID identified in step 1. On the overview section, find the applied Server Profile entry, click on it and copy the Server Profile URI. The copied excerpt should look like /rest/server-profiles/<server-profile-uuid>.

  3. Then, set the copied excerpt from the Server Profile URI to the property applied_server_profile_uri in the driver_info namespace doing:

    $ ironic node-update <node-uuid> add driver_info/applied_server_profile_uri=<server_profile_uri>

  4. Finally, set the dynamic_allocation flag in the driver_info namespace to True in order to finish the migration of the node doing:

    $ ironic node-update <node-uuid> add driver_info/dynamic_allocation=True

Other cases for migration

Remember these steps are valid for nodes in the following states: enroll, manageable, available, error, clean failed and inspect failed. So, list the nodes in a given state, then execute the migration following steps for each node:

  1. Place the node in maintenance mode to prevent ironic from working on the node during the migration doing:

    $ ironic node-set-maintenance --reason "Migrating node to dynamic allocation" <node_uuid> true

    Note

    It’s recommended to check if the node’s state has not changed as there is no way of locking the node between these commands.

  2. Identify which Server Profile is associated by checking the property server_hardware_uri in the driver_info namespace. Using the server_hardware_uri, log into OneView and remove the Server Profile.

  3. Set the dynamic_allocation to True in the flag driver_info namespace doing:

    $ ironic node-update $NODE_UUID add driver_info/dynamic_allocation=True

  4. Finally, in order to put the node back into the resource pool, remove the node from maintenance mode doing:

    $ ironic node-set-maintenance <node_uuid> false

3rd Party Tools

In order to ease user manual tasks, which are often time-consuming, we provide useful tools that work nicely with the OneView drivers.

ironic-oneview-cli

The ironic-oneView CLI is a command line interface for management tasks involving OneView nodes. Its features include a facility to create of ironic nodes with all required parameters for OneView nodes, creation of Nova flavors for OneView nodes and, starting from version 0.3.0, the migration of nodes from pre-allocation to the dynamic allocation model.

For more details on how Ironic-OneView CLI works and how to set it up, see [8].

ironic-oneviewd

The ironic-oneviewd daemon monitors the ironic inventory of resources and providing facilities to operators managing OneView driver deployments. The daemon supports both allocation models (dynamic and pre-allocation) as of version 0.1.0.

For more details on how Ironic-OneViewd works and how to set it up, see [7].