Jump to: navigation, search

Difference between revisions of "Ironic/blueprints/cinder-integration"

(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
=[ DRAFT ]=
+
[ DRAFT ]
 
                                                                                                                                                                                                        
 
                                                                                                                                                                                                        
* Blueprints:  
+
* Blueprints / Etherpad:  
 
** Ironic:
 
** Ironic:
*** https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume
+
*** https://blueprints.launchpad.net/ironic/+spec/cinder-integration
 +
*** https://etherpad.openstack.org/p/IronicCinderIntegration
 
** Cinder:
 
** Cinder:
 
*** TBD
 
*** TBD
Line 11: Line 12:
 
=Summary=
 
=Summary=
 
                                                                                    
 
                                                                                    
Currently, Ironic has no integration with OpenStack's block storage project called Cinder.  Ironic assumes that the bare metal (BM) host 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.   
+
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=
 
=User Story=
A user wants to deploy a Bare Metal box 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 Bare Metal host using the newly created Cinder bootable volume.   
+
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=
 
=Detailed Design=
High level overview of what is needed to integrate with Cinder. The idea is to have Ironic orchestrate with Cinder, like Nova orchestrates with Cinder, to boot a bare metal machine from a Cinder provisioned bootable volume.
+
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==
 
==Requirements==
Line 25: Line 27:
 
* Ironic has been deployed, configured and is running.
 
* Ironic has been deployed, configured and is running.
 
* Ironic has been setup with nodes that can be deployed.
 
* Ironic has been setup with nodes that can be deployed.
* '''Ironic can ask the BM BIOS to configure itself to boot from SAN (iSCSI/FC)'''
+
* 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==
 
==Assumptions==
* The BM node can have it's BIOS configured remotely
+
* The node can have it's BIOS configured remotely
 
* Ironic has an abstracted BIOS communication layer.
 
* 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.
 
* 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=
 
=Work Flow for Boot from Cinder Volume=
* User asks Ironic to boot a node from a cinder volume (uuid)
+
* User asks nova to boot a node from a cinder volume (--boot-from-volume <uuid>)
* Ironic gathers the BM connection information
+
* Nova calls ironic to collect iSCSI/FC initiator information.  (iscsi iqn, FC WWNS/WWPNS)
 
** iSCSI
 
** iSCSI
*** Ironic creates a new iSCSI initiator name (iqn) for the BM BIOS
+
*** Ironic creates a new iSCSI initiator name (iqn) for the node BIOS
 
** Fibre Channel
 
** Fibre Channel
*** Ironic calls the BIOS layer to fetch the BM's FibreChannel HBA WWN (world wide names)
+
*** Ironic calls the BIOS layer to fetch the node's FibreChannel HBA WWN (world wide names)
* Ironic calls Cinder to attach the volume to the host, passing in the connection information
+
* 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()
 
* Cinder calls the volume driver associated with the volume, initialize_connection()
** This informs the cinder backend array to export the volume to the BM host.
+
** This informs the cinder backend array to export the volume to the node.
** Cinder returns the target connection information to Ironic
+
** Cinder returns the target connection information to Nova
 
*** driver_volume_type ('fibre_channel', 'iscsi')
 
*** driver_volume_type ('fibre_channel', 'iscsi')
 
*** iSCSI
 
*** iSCSI
Line 59: Line 62:
 
* Ironic calls the BIOS layer to configure the BIOS to boot from SAN
 
* 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)
 
** passing the connection information based upon the volume protocol type (iSCSI/FC)
*** for iSCSI volumes, the BIOS will also need the BM connection information
+
*** for iSCSI volumes, the BIOS will also need the node connection information
 
**** initiator isci name (iqn)
 
**** initiator isci name (iqn)
* Ironic powers on the BM
+
* 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.
 +
<pre><nowiki>
 +
{'ip': '10.50.129.1', 'host': 'walt-stack1',
 +
'wwnns': ['200010604b010459', '200010604b01045d'],
 +
'initiator': 'iqn.1993-08.org.debian:01:fc9284aaa6f7',
 +
'wwpns': ['100010604b010459', '100010604b01045d']}
 +
</nowiki></pre>
 +
 
 +
==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 ====
 +
<pre><nowiki>
 +
{'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}
 +
}</nowiki></pre>
 +
====Fibre Channel====
 +
<pre><nowiki>
 +
{'driver_volume_type': 'fibre_channel',
 +
'data': {'target_lun': 0, 'target_wwn': ['20210002AC00383D', '20240002AC00383D',
 +
                                          '21210002AC00383D', '21240002AC00383D'],
 +
          'target_discovered': True}
 +
}
 +
</nowiki></pre>
  
 
==Issues==
 
==Issues==
* The BM BIOS needs an iSCSI initiator name (iqn) for iSCSI boot from SAN
+
* 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
 
** 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 BM, it may get it's own iSCSI initiator iqn for volume attaches, which will be different, that the entry in the BIOS.
+
*** 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.   
 
*** 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 BM BIOS for a few things
+
* Ironic needs to talk to the node BIOS for a few things
 
** List of Fibre Channel HBA World wide names, if any
 
** List of Fibre Channel HBA World wide names, if any
 
** configure BIOS to boot from SAN for iSCSI/FC remotely.
 
** configure BIOS to boot from SAN for iSCSI/FC remotely.
 
  
 
=Implementation Details=
 
=Implementation Details=
* Implement a new Ironic deploy driver that does the Cinder orchestration
+
* Implement a new Ironic deploy driver that creates an iscsi initiator and fetches BIOS FC WWN information
* driver.deploy would implement the workflow as described above
 
 
* driver would use the BIOS abstraction layer to query and configure the BIOS
 
* driver would use the BIOS abstraction layer to query and configure the BIOS

Revision as of 18:55, 23 January 2014

[ DRAFT ]

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 <uuid>)
  • 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