Ironic/blueprints/cinder-integration

[ DRAFT ]
 * Blueprints / Etherpad:
 * Ironic:
 * https://blueprints.launchpad.net/ironic/+spec/cinder-integration
 * https://etherpad.openstack.org/p/IronicCinderIntegration
 * Cinder:
 * TBD
 * Created: 12th December 2013
 * Author: Walter Boring

=Summary= Currently, Ironic has no integration with OpenStack's block storage project called Cinder. Ironic assumes that the bare metal node has it's own block storage device that Ironic deploys a bootable image onto. Cinder is the block storage project that knows how to provision volumes and create bootable volumes from images that live in Glance. What we would like is to have Ironic use Cinder bootable volumes as the block storage root device on bare metal.

=User Story= A user wants to deploy a bare metal node as a compute instance from a volume that they have provisioned using Cinder. The user creates the bootable volume from Cinder's create volume from image. Then the user asks Ironic to deploy a node using the newly created Cinder bootable volume.

=Detailed Design= High level overview of what is needed to integrate with Cinder. Have Nova continue to orchestrate the communication with Cinder and use the Ironic driver (still in review https://review.openstack.org/#/c/51328).

Requirements

 * Cinder has been deployed, configured and is running.
 * User/Admin creates a Cinder bootable Volume and can get the cinder volume uuid
 * Ironic has been deployed, configured and is running.
 * Ironic has been setup with nodes that can be deployed.
 * Ironic can create an iscsi initiator to set as the iqn on the BIOS
 * For FC support, Ironic can query the BIOS to fetch the FC HBA WWN/WWPN information
 * Ironic can ask the node BIOS to configure itself to boot from SAN (iSCSI/FC)

Assumptions

 * The node can have it's BIOS configured remotely
 * Ironic has an abstracted BIOS communication layer.
 * The volume created in Cinder has a bootable OS on it. It's outside the scope of Ironic to verify this.

=Work Flow for Boot from Cinder Volume=
 * User asks nova to boot a node from a cinder volume (--boot-from-volume )
 * Nova calls ironic to collect iSCSI/FC initiator information. (iscsi iqn, FC WWNS/WWPNS)
 * iSCSI
 * Ironic creates a new iSCSI initiator name (iqn) for the node BIOS
 * Fibre Channel
 * Ironic calls the BIOS layer to fetch the node's FibreChannel HBA WWN (world wide names)
 * Nova calls Cinder to attach the volume to the host, passing in the connection information
 * Cinder calls the volume driver associated with the volume, initialize_connection
 * This informs the cinder backend array to export the volume to the node.
 * Cinder returns the target connection information to Nova
 * driver_volume_type ('fibre_channel', 'iscsi')
 * iSCSI
 * target_iqn
 * target_lun
 * target_portal
 * ip
 * port
 * auth_method (CHAP - optional)
 * auth_username
 * auth_password
 * Fibre Channel
 * target_lun
 * target_wwn (list of world wide names for the target)
 * Ironic calls the BIOS layer to configure the BIOS to boot from SAN
 * passing the connection information based upon the volume protocol type (iSCSI/FC)
 * for iSCSI volumes, the BIOS will also need the node connection information
 * initiator isci name (iqn)
 * Ironic powers on the node

Example node connector info
This is the information that Ironic needs to acquire/build prior to calling Cinder to attach. This is the connector object that Nova currently populates for calls into Cinder's driver initialize_connection. Since Nova doesn't know if the request is for iSCSI or FC, it collects all the information it can prior to calling Cinder. Cinder decides which type of volume protocol to use for the attachment. {'ip': '10.50.129.1', 'host': 'walt-stack1', 'wwnns': ['200010604b010459', '200010604b01045d'], 'initiator': 'iqn.1993-08.org.debian:01:fc9284aaa6f7', 'wwpns': ['100010604b010459', '100010604b01045d']}

Example Cinder attach return value
This is the information that comes back from the Cinder attach call. This needs to be passed to the BIOS layer to configure boot from SAN

iSCSI
{'driver_volume_type': 'iscsi', 'data':  { 'target_lun': 0, 'target_iqn': 'iqn.2000-05.com.3pardata:21810002ac00383d', 'target_portal': '10.10.220.253:3260', 'target_discovered': True} }

Fibre Channel
{'driver_volume_type': 'fibre_channel', 'data': {'target_lun': 0, 'target_wwn': ['20210002AC00383D', '20240002AC00383D', '21210002AC00383D', '21240002AC00383D'], 'target_discovered': True} }

Issues

 * The node BIOS needs an iSCSI initiator name (iqn) for iSCSI boot from SAN
 * The ironic node can create a new initiator iqn using the open-iscsi util iscsi-iname and use that for the initiator
 * Once the host os is up and running on the node, it may get it's own iSCSI initiator iqn for volume attaches, which will be different, that the entry in the BIOS.
 * This shouldn't be a problem. For example, on 3PAR arrays, you have 1 initiator host that can declare it uses multiple initiator iqns.
 * Ironic needs to talk to the node BIOS for a few things
 * List of Fibre Channel HBA World wide names, if any
 * configure BIOS to boot from SAN for iSCSI/FC remotely.

=Implementation Details=
 * Implement a new Ironic deploy driver that creates an iscsi initiator and fetches BIOS FC WWN information
 * driver would use the BIOS abstraction layer to query and configure the BIOS