It proposes implementing the RAID interface as described by the parent spec
[1] for UCS drivers.

List of changes required:

ucs.raid.RAIDInterface for RAID configuration operations

The following methods will be implemented:

validate

create_configuration

delete_configuration

validate() method validates the required UCS parameters for OOB RAID
configuration. Also calls validate() of the super class to validate json
schema.
create_configuration and delete_configuration operations are implemented
as asynchronous RAID configuration deployment operations by UCS drivers.
UcsSdk/UCS-API asynchronously deploys the RAID configuration on the target
node. UCS driver(s) sends the RAID configuration simultaneously to the
target node when the operation is invoked, but UCS Manager would not deploy
the configuration simultaneously on the target node. UCS Manager accepts
the RAID configuration and deploys it as part of UCS Manager FSM deploy
state. Hence there will be delay between, when the operation is invoked
and when the RAID configuration is deployed. To know the deploy status,
we need to query the FSM status using UcsSdk API. These methods return
states.CLEANWAIT.
New driver periodic task will be added to fetch the UCSM FSM status of
these operations. This periodic task is enabled only if pxe_ucs, agent_ucs
drivers are enabled in the conductor.

RAID management changes:

Controlling the RAID configuration is creating storage-profile ManagedObject
and associating with the Server object in UCS Manager 2.4. Earlier version
of UCSM requires to configure LocalDiskConfigPolicy and associate with
respective service-profile ManagedObject. The service-profile information is
captured as part of node driver_info properties.
UcsSdk provides RAIDHelper interface, which actually creates the required
policies specified above. UCS driver uses this interface and makes
appropriate calls to create_config and delete_config operations.