Naohiro Tamura 6c5847be1d Update Ironic spec URL refs to specs.openstack.org

This patch updates spec URL references from [1] to [2].
[1] https://github.com/openstack/ironic-specs
[2] http://specs.openstack.org/openstack/ironic-specs

Change-Id: I9be53452d77d41183a98ab06bfd537905044ff44

2015-05-07 09:53:01 +09:00

25 KiB

Raw Blame History

New driver interface for RAID configuration

https://blueprints.launchpad.net/ironic/+spec/ironic-generic-raid-interface

The proposal presents the work required to create a new driver interface for RAID configuration. It also proposes a method to make RAID configuration available as part of zapping.

Problem description

There is no support in Ironic currently to do RAID configuration.
A specific set of tasks for this requires a separate interface on the drivers. The new RAID interface will allow operators to specify RAID configuration for a node. Different drivers may provide the same interface to the operator for RAID configuration.

Proposed change

After a node is enrolled and the basic hardware information is available, the operator can define a RAID configuration. This configuration will be applied in two steps during zapping: creating the root device and creating the rest of the RAID disks. This is required because certain drivers might not be able to propagate any root device hint. With an optional step between the zapping steps, the root device can be investigated with other methods (eg. using discoverd).
The operator can convey the RAID configuration information to the Ironic driver through REST APIs or CLI as JSON data. The RAID configuration information will contain the properties for each logical disk and optionally hints to Ironic to find the desired backing physical disks for them.

The properties can be split into 4 different types:
1. Mandatory properties - These properties must be specified for each logical disk and have no default values.
  - size_gb - Size (Integer) of the logical disk to be created in GiB. MAX may be specified if the logical disk should use all of the space available on the backing physical disks. This can be used only when backing physical disks are specified (see below).
  - raid_level - RAID level for the logical disk. Ironic will define the supported RAID levels as 0, 1, 2, 5, 6, 1+0, 5+0, 6+0. Drivers may override the values in the get_logical_disk_properties method in RAIDInterface.
2. Optional properties - These properties have default values and they may be overridden in the specification of any logical disk.
  - volume_name - Name of the volume. Should be unique within the Node. If not specified, volume name will be auto-generated.
  - is_root_volume - Set to true if this is the root volume. Can be used for only one of logical disk. The root device hint will be saved, if the driver is capable of retrieving it. This is false by default.
3. Backing physical disk hints - These hints are specified for each logical disk to let Ironic find the desired disks for RAID configuration. This is machine-independent information. This serves the use-case where the operator doesn't want to provide individual details for each bare metal node.
  - share_physical_disks - Set to true if this logical disk can share physical disks with other logical disks. It has default value of CONF.raid.share_physical_disks. The default value of this config variable will be false.
  - disk_type - hdd or ssd. It has a default value of CONF.raid.default_disk_type. The default value of this config variable will be hdd.
  - interface_type - sata or scsi or sas. It has a default value of CONF.raid.default_interface_type. The default value of this config variable will be sas.
  - number_of_physical_disks - Integer, number of disks to use for the logical disk. Defaulted to minimum number of disks required for the particular RAID level.
  The above mentioned backing physical disk hints are defined by Ironic and every driver has to implement them. The supported values and the default values for the above hints may be overridden the driver using the get_logical_disk_properties method.
  
  In addition to the above hints, drivers may define their own hints in the get_logical_disk_properties method. For more details, refer the Driver API impact section. The possible use-cases for them might be:
  - Filter disks by particular vendors
  - Filter disks by models
  - Filter disks by firmware versions.
4. Backing physical disks - These are the actual machine-dependent information. This is suitable for environments where the operator wants to automate the selection of physical disks with a 3rd-party tool based on a wider range of attributes (eg. S.M.A.R.T. status, physical location).
  - controller - The name of the controller as read by the driver.
  - physical_disks - A list of physical disks to use as read by the driver.
  Note
  
  The values for these properties are hardware dependent.
Note

Only one of "Backing physical disk hints" or "Backing physical disks" need to be specified. If both are specified, they need to be consistent with each other. If they are not consistent, then the raid configuration will fail (because the appropriate backing physical disks could not be found).
Some examples:
Example 1:
```
{
  'logical_disks':
    [
      {
        'size_gb': 50,
        'raid_level': '1+0',
        'disk_type': 'hdd',
        'interface_type': 'sas',
        'volume_name': 'root_volume',
        'is_root_volume': 'true'
      },
      {
        'size_gb': 100,
        'number_of_physical_disks': 3,
        'raid_level': '5',
        'disk_type': 'hdd',
        'interface_type': 'sas'
        'volume_name': 'data_volume'
      }
    ]
}
```
Example 2:
```
{
  'logical_disks':
    [
      {
        'size_gb': 50,
        'raid_level': '1+0',
        'controller': 'RAID.Integrated.1-1',
        'volume_name': 'root_volume',
        'is_root_volume': 'true'
        'physical_disks': [
                           'Disk.Bay.0:Encl.Int.0-1:RAID.Integrated.1-1',
                           'Disk.Bay.1:Encl.Int.0-1:RAID.Integrated.1-1'
                          ]
      },
      {
        'size_gb': 100,
        'raid_level': '5',
        'controller': 'RAID.Integrated.1-1',
        'volume_name': 'data_volume'
        'physical_disks': [
                           'Disk.Bay.2:Encl.Int.0-1:RAID.Integrated.1-1',
                           'Disk.Bay.3:Encl.Int.0-1:RAID.Integrated.1-1',
                           'Disk.Bay.4:Encl.Int.0-1:RAID.Integrated.1-1'
                          ]
      }
    ]
}
```
New driver interface called RAIDInterface will be provided for RAID configuration for drivers. For more details, refer the Driver API impact section.
New methods create_configuration and delete_configuration in RAIDInterface will be available as part of zapping. The operator can choose to call them as part of zap steps. The corresponding zap steps will be node.raid.create_configuration and node.raid.delete_configuration.
A new method update_raid_info will be available in the base class RAIDInterface. This method may be used by the driver implementation of create_configuration and delete_configuration to update the RAID information in the Node database. This will facilitate drivers to do the RAID configuration asynchronously. This method will do the following:
- Set node.driver_internal_info.current_raid_configuration to the value returned by the driver.
- Set the respective part (root/non-root devices) of node.driver_internal_info.target_raid_configuration to None. Update the last_updated_at timestamp in current_raid_configuration.
- The root device hint for the root volume will be updated in node.properties as per the root device hint root device hint and the size of root volume will be updated in node.properties.local_gb. It's up to the driver to choose which root device hint it wants to specify.
- The RAID level of the root volume will be updated as raid_level in node.properties.capabilities.
New REST APIs will be created for RAID configuration. For more details, refer to the REST API impact section.
Four new options will be available in Ironic CLI for doing the RAID configuration.

To set a new RAID configuration:
```
$ ironic node-set-raid-configuration <node-uuid> --from-file raid_conf.json
```
To get the RAID configuration:
```
$ ironic node-get-raid-configuration <node-uuid>
```
To get the physical disks available in RAID controllers:
```
$ ironic node-get-raid-physical-disks <node-uuid>
```
To get the properties that can be defined for each logical disk and their possible values:
```
$ ironic node-get-raid-logical-disk-properties <node-uuid>
```

Alternatives

Operator can change the RAID configuration manually whenever required after putting the node to MANAGEABLE state. But this has to be done for each node.
There needs to be only one API PUT /nodes/<uuid>/raid/configuration which can be used for both creating and deleting the configuration. For deletion, delete=True may be passed to the API.

Data model impact

The following fields in the Node object will be updated:

node.driver_internal_info.target_raid_configuration will store the pending RAID configuration to be applied during zapping.
node.driver_internal_info.current_raid_configuration will store the last applied RAID configuration. This will also contain the timestamp of when this configuration was applied.
node.properties.local_gb will be updated after applying RAID configuration to the size of the root volume.
node.properties.root_device will be updated with the root device hint returned by the driver as prescribed in the root device hint spec.

REST API impact

Four new REST APIs will be introduced as part of this change.

To create the RAID configuration for a node, run:
```
PUT /nodes/<uuid>/raid/configuration
```
This operation is idempotent. The operation will write the configuration to the node.driver_internal_info.target_raid_configuration and will be applied during the zapping step. The JSON data of the RAID configuration as mentioned above needs to be passed as data to this request. Updating the RAID configuration will be prevented if RAID configuration is in progress from the driver. This will also validate the target RAID configuration by calling validate_configuration method on the RAIDInterface.

Note

This API doesn't actually do the RAID configuration. It just stores the input for RAID configuration in the Ironic database. The RAID configuration will be done as part of zapping.

If the operation is success, then the API will return HTTP 202 (Accepted). If the operation failed, either because the driver doesn't support RAID configuration or validation of input failed, then the API will return HTTP 400 (Bad Request).

To GET the current RAID configuration:

GET /nodes/<uuid>/raid/configuration

This operation will return the current and target RAID configuration.

Example 1: After putting a RAID configuration using PUT:

{
  'current': None
  'target':
    {
      'logical_disks':
        [
          {
            'size_gb': 50,
            'raid_level': '1',
            'volume_name': 'root_volume',
            'is_root_volume': 'true'
            'disk_type': 'hdd',
            'interface_type': 'sas',
          },
          {
            'size_gb': 100,
            'number_of_physical_disks': 3,
            'volume_name': 'data_volume'
            'raid_level': '5',
            'disk_type': 'hdd',
            'interface_type': 'sas'
          }
        ]
    }
}

Example 2: After the RAID configuration is applied as part of zapping:

{
  'current':
    {
      'logical_disks':
        [
          {
            'size_gb': 50,
            'raid_level': '1',
            'share_physical_disks': False,
            'disk_type': 'hdd',
            'interface_type': 'sas',
            'number_of_physical_disks': 2,
            'volume_name': 'root_volume',
            'is_root_volume': 'true',
            'controller': 'Smart Array P822 in Slot 2',
            'physical_disks': [
                               '5I:1:2',
                               '5I:1:3'
                              ]
            'root_device_hint': {
                                 'wwn': 600508B1001CE4ACF473EE9C826230FF'
                                }
          },
          {
            'size_gb': 100,
            'number_of_physical_disks': 3,
            'raid_level': '5',
            'disk_type': 'hdd',
            'interface_type': 'sas',
            'number_of_physical_disks': 3,
            'volume_name': 'data_volume',
            'controller': 'Smart Array P822 in Slot 2',
            'physical_disks': [
                               '5I:1:4',
                               '5I:1:5',
                               '5I:1:6'
                              ]
          }
        ],
    }
    'target': None
}

If driver doesn't support RAID configuration, then the API will return HTTP 400 (Bad Request). Otherwise the API will return HTTP 200 (OK).

To GET the physical disks in various RAID controllers:

GET /nodes/<uuid>/raid/physical_disks

  {
      'physical_disks':
        [
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:2',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'active',
         },
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:3',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'active',
         },
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:4',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'active',
         },
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:5',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'active',
         },
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:6',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'active',
         },
         {
          'controller': 'Smart Array P822 in Slot 2',
          'id': '5I:1:7',
          'disk_type': 'hdd',
          'interface_type': 'sas',
          'size_gb': 600,
          'vendor': 'HP',
          'model': 'EF0600FARNA',
          'firmware_version': 'HPD6',
          'state': 'failed',
         },
        ]
      'last_updated': '2013-06-14 23:30:59'
  }

If the driver doesn't support RAID configuration, then the API will return HTTP 400 (Bad Request). Otherwise the API will return HTTP 200 (OK).

To GET the RAID properties that can be defined and their possible values:

GET /drivers/<driver>/raid/logical_disk_properties

The operation will return the properties and a textual description of the possible values for each property:

{
 'raid_level': 'RAID level for the logical disk. Supported values are
                0, 1, 2, 5, 6, 1+0, 5+0, 6+0. Required.',
 'size_gb': 'Size of the logical disk in GiB. Required.',
 'disk_type': 'Disk Type. Supported values are `hdd` or `sdd`. Optional',
 .
 .
 .
 .
}

If the driver doesn't support RAID configuration, then the API will return HTTP 400 (Bad Request). Otherwise the API will return HTTP 200 (OK).

RPC API impact

Three new RPC APIs will be created. They will have the corresponding methods defined in the conductor for handling their functionalities.

create_raid_configuration - This method will be called in PUT /nodes/<uuid>/raid/configuration.
get_raid_configuration - This method will be called in GET /nodes/<uuid>/raid/configuration and GET /nodes/<uuid>/raid/physical_disks.
get_raid_logical_disk_properties - This method will be called in GET /drivers/<driver>/raid/logical_disk_properties.

Driver API impact

A new RAIDInterface will be available for the drivers to allow them to implement RAID configuration. There will be two methods in the interface:

create_configuration() - The driver implementation of the method has to read the request RAID configuration from node.driver_internal_info.target_raid_configuration and create to RAID configuration on the bare metal. The driver must ensure update_raid_info is called at the end of the process updating the current_raid_configuration. The implementation detail is up to the driver depending on the synchronicity/asynchronicity of the operation.

The current_raid_configuration will include the following:

For each logical disk (on top of the input passed):

controller - The name of the controller used for the logical disk as read by the driver.

physical_disks - A list containing the identifier for the physical disks used for the logical disk as read by the driver.

root_device_hint - A dictionary containing the root device hint to be used by Ironic to find the disk to which image is to be deployed. It's up to the driver to determine which root device hint it wants to provide.

A list of all the physical disks on the system with the following details:

controller - RAID controller for the physical disk.

id - ID for the physical disk as read the driver

disk_type - hdd or ssd

interface_type - sas or sata or scsi

size_gb

state - State field states the current status of the physical disk. It can be one of:

active if disk is part of an array

ready if disk is ready to be part of a volume

failed if disk has encountered some error

hotspare if disk is hotspare and part of some array

offline if disk is not available for raid due to some other reason, but not failed

non_raid if disk is not part of raid and is directly visible

The above details may be used for backing physical disk hints for later raid configurations.

Note

For a newly enrolled node or a node in which raid configuration was never done, the information about physical disks and controllers can be populated by hardware introspection. This is not in the scope of this spec.

The function definition will be as follows:
def create_configuration(task,
                         create_only_root_volume=False,
                         create_only_nonroot_volumes=False):
    """Create RAID configuration on the node.

    This method creates the RAID configuration as read from
    node.driver_internal_info.target_raid_configuration.  This method
    by default will create all logical disks.

    :param task: TaskManager object containing the node.
    :param create_only_root_volume: This specifies whether to create
        only the root volume.
    :param create_only_nonroot_volumes: This specifies to create only
        non-root volumes.
    """
delete_configuration - To delete the RAID configuration. This method doesn't have an input and doesn't return anything.

The function definition will be as follows:
def delete_configuration(task):
    """Delete RAID configuration on the node.

    :param task: TaskManager object containing the node.
    """
validate_configuration - To validate a RAID configuration. This is called during the PUT operation in the API.

The function definition will be as follows:
def validate_configuration(task, raid_config):
    """Validates the given RAID configuration.

    :param task: TaskManager object containing the node.
    :param raid_config: The RAID configuration to be validated.
    :raises: InvalidParameterValue, if RAID configuration is invalid.
    :raises: MissingParameterValue, if RAID configuration has some
        missing parameters.
    """
get_logical_disk_properties - To get the RAID properties that are defined by the driver.

The function definition will be as follows:
def get_logical_disk_properties(task):
    """Gets the RAID properties defined by the driver.

    :param task: TaskManager object containing the node.
    :returns: A dictionary of properties and a textual description.
    """

After performing the RAID configuration (create or delete), the drivers may call update_raid_info with the current_raid_configuration. The details about the method has been described above.

Nova driver impact

None.

Security impact

None.

Other end user impact

Users from Nova may choose the desired RAID level for the root volume by using compute capabilities. For example:

nova flavor-key ironic-test set capabilities:raid_level="1+0"

Scalability impact

None.

Performance Impact

RAID configuration may extend the time required for zapping on the nodes, but this is important for performance and reliability reasons.

Other deployer impact

Operator can make use of node.raid.create_configuration and node.raid.delete_configuration as zap tasks for doing RAID management.

Developer impact

Developers may implement the RAIDInterface for respective drivers.

Implementation

Assignee(s)

Primary assignee:: rameshg87
Other contributors:: ifarkas

Work Items

Create REST API endpoints for RAID configuration.
Create RAIDInterface and create a fake implementation of RAIDInterface.
Implement update_raid_info in RAIDInterface.
Implement Ironic CLI changes.
Write unit tests.

Dependencies

Root device hints - http://specs.openstack.org/openstack/ironic-specs/specs/kilo/root-device-hints.html
Zapping of nodes - https://review.openstack.org/#/c/140826/

Testing

Unit tests will be added for the code. A fake implementation of the RAIDInterface will be provided for testing purpose and this can be run as part of zapping.
Each driver is responsible for providing the third party CI for testing the RAID configuration.

Upgrades and Backwards Compatibility

None.

Documentation Impact

Documentation will be provided on how to configure a node for RAID.

References

Other references:

New Ironic provisioner state machine: http://specs.openstack.org/openstack/ironic-specs/specs/kilo/new-ironic-state-machine.html
Support Zapping of Nodes: https://review.openstack.org/#/c/140826/

25 KiB Raw Blame History

New driver interface for RAID configuration

Problem description

Proposed change

Alternatives

Data model impact

REST API impact

RPC API impact

Driver API impact

Nova driver impact

Security impact

Other end user impact

Scalability impact

Performance Impact

Other deployer impact

Developer impact

Implementation

Assignee(s)

Work Items

Dependencies

Testing

Upgrades and Backwards Compatibility

Documentation Impact

References

25 KiB

Raw Blame History