Volumes Support in the Deltacloud Openstack Driver

Adding a new feature to a deltacloud driver means first checking that this feature is supported in the cloud provider client being used by that driver. For the Deltacloud Openstack driver, the client is the openstack rubygem. The following are some notes about how/why I implemented the Volumes support on both the rubygem side and the deltacloud side.

Many thanks to HPCloud for granting me access to the private beta of their Block Storage service which I used to implement this functionality - fwiw I didn’t come across any issues with any of the API calls as documented.

Note: I haven’t yet implemented the storage snapshot support - this will follow soon.


Volumes support in the Openstack rubygem:

The main issue that I had to resolve here was quite simply… which API. Basically there is the bona fide, stand-alone Volume service (aka Cinder?) which is exposed @ v1/{tenant_id}/volumes. This volume service is returned in the serviceCatalog after authentication against the Keystone service, together with all the other deployed services (compute/nova, object-store/swift etc). Right now (mid November 2012) the full specification for the Volume API 1.0 is not yet available; at the Openstack API specs page the text reads: “Check back for the specification for the Volume API 1.0, all calls are shown on api.openstack.org.”.

There is however another Volume service which exists as an extension to the compute/nova service. This extension volume service is exposed @ v1/{tenant_id}/os-volumes. Mercifully, the actual API calls are the same for both exposed endpoints, although the ‘bona-fide’ Volume service does not expose operations for attach/detach volume from server.

To get around this I put some code in the definition of Openstack::Volume::Connection to determine which of the two is deployed and so set the endpoint accordingly.

Another detail point is that since the attach/detach operations aren’t yet exposed for the ‘full’ Volume service but only for the extension, I added the attach/detach functions in the definition of Openstack::Compute. Partly because this is where the other extensions live but mainly since the attach/detach operations are called against a given server, that is, against the compute service and not the volume service, e.g.

POST v2/{tenant_id}/servers/{server_id}/os-volume_attachments
{
  'volumeAttachment': {
    'volumeId': volume_id,
    'device': device
  }
}

The result of this is that in order to fully work with storage volumes and servers you need both a handle to the compute service and a handle to the volume service:

#get volume service, create a volume:
vs = OpenStack::Connection.create({:username => "username", :api_key=>"pass",
  :auth_url => "https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/",
  :authtenant=>"username-default-tenant", :service_type=>"volume"})

volume = vs.create_volume({:display_name=>"marios volume", :size=>1,
                      :display_description=>"some new volume bla"})

#get the compute service and attach volume to a running server:
os = OpenStack::Connection.create(:username => USERNAME, :api_key => API_KEY,
      :authtenant => TENANT, :auth_url => API_URL, :service_type => "compute")
os.attach_volume(704289, 90805, "/dev/sde") #svr_id, vol_id, device

The latest version of the Openstack rubygem, 1.0.7 (at time of writing) contains the new Volume functionality.


Volumes support in the Deltacloud Openstack driver:

Storage Volumes support for Openstack on the Deltacloud side is pretty ‘standard’ - the StorageVolumes collection already exists and is implemented for those cloud provider drivers that support it - rhevm, fgcp, aruba, ec2.

After defining the standard operations, the only new addition I made was defining two new features - :volume_name and :volume_description. These signal to clients that the given driver will accept a ‘name’ and a ‘description’ parameter for the ‘create storage volume’ API call:

===> REQUEST:
curl --user "uname+tenant_name:password" -H "Accept: application/xml"
        http://localhost:3001/api

===> RESPONSE:
<api driver='openstack' provider='https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/'
        version='1.0.5'>

...

<link href='http://localhost:3001/api/storage_volumes' rel='storage_volumes'>
  <feature name='volume_name' rel='create'>
    <param name='name' />
  </feature>
  <feature name='volume_description' rel='create'>
    <param name='description' />
  </feature>
</link>

...

</api>


blog comments powered by Disqus
RSS Feed Icon site.xml
RSS Feed Icon tripleo.xml