Add volume driver concept to xenapi driver

Registered by Mate Lakat on 2012-10-09

A volume driver is a piece of code that could use a connection_info structure to attach a block device to the instance.

At the moment xenapi supports raw iscsi and xenapinfs cinder backends. One codeblock supports connecting both types.

The issue with the actual implementation is that the volume related code is spread across different places.

This blueprint is about to introduce a plugin model in the xenapi driver, so that it is extensible. Separate the xenapinfs, and raw iscsi drivers to distinct plugins. Having a driver model will help in maintenance, and make it easier to connect to new protocols.

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Low
Drafter:
Citrix OpenStack development team
Direction:
Approved
Assignee:
Mate Lakat
Definition:
Superseded
Series goal:
None
Implementation:
Good progress
Milestone target:
None
Started by
Vish Ishaya on 2012-11-01
Completed by
John Garbutt on 2013-05-01

Related branches

Sprints

Whiteboard

Killing this off, there is some new work that will cover the remaining tasks here, moving things to oslo:
https://blueprints.launchpad.net/nova/+spec/xenapi-move-driver-to-oslo

-----

I'm removing blueprints from grizzly where the code is not up for review. It looks like there is still more work needed here and the code is not up for review, so I'm taking it off the grizzly list. If this happens to make it in anyway, let me know and I'll add it back. --Russell

Look at:
nova/virt/libvirt/volume.py

We need a XenAPI equivalent to provide:
attach, detach volumes

The aim is to allow any 3rd party vendor should easily add its volume driver.
It is likely you may also need to include changes to XenServer, packaged as a supplemental pack

Likely steps:
Refactor xapi driver nova/virt/xenapi/volumeops.py [attach_volume]
according to nova/virt/libvirt/driver.py (plugin pattern)

At the moment, two implementations exist: ['iscsi', 'xensm']
Need to document the XenSM case much better, so it can be used by third parties.

Consider adding a file based SR attach for XCP-XenAPI and gluster/ceph as an example.

The LibVirtVolumeDriver's connect_volume method returns a struct, that could be digested by libvirt, a sort of configuration, that could be passed to an instance's attachDeviceFlags method, see:

http://libvirt.org/html/libvirt-libvirt.html#virDomainAttachDeviceFlags

It needs to be decided what should be the interface with xenapi.
a VDI ref seems reasonable.

Look at: nova/virt/xenapi/volume_utils.py / introduce_sr

The libvirt "interface":

class LibvirtVolumeDriver(object):
    def __init__(self, connection):
        pass

    def connect_volume(self, connection_info, mount_device):
        pass

    def disconnect_volume(self, connection_info, mount_device):
        pass

connection is actually a reference to the compute driver.

The dependency for a volume driver in XenAPI case:
- An initialised XenAPI connection

The parameters could be the same as in the libvirt case:
- connection_info: the data structure, returned from volume_api.initialize_connection
- mount_device: the mount_device, that identifies the device, converted to device number by: nova/virt/xenapi/volume_utils.py:mountpoint_to_number

I am not sure, if the whole connection_info needs to be passed to the driver implementation. I guess, only connection_info[data] needs to be passed down.

Gerrit topic: https://review.openstack.org/#q,topic:bp/xenapi-volume-drivers,n,z

Addressed by: https://review.openstack.org/14521
    Do not call directly vmops.attach_volume

Addressed by: https://review.openstack.org/14524
    Introduce volume manager, and drivers

Addressed by: https://review.openstack.org/14527
    limit the usage of connection_info

The volume_connect must support a rollback, so using a context manager should be considered. No. Context managers are not reflecting the same thing, so a separate rollback method on the driver makes more sense.

Addressed by: https://review.openstack.org/14563
    Remove mountpoint from parse_volume_info

Addressed by: https://review.openstack.org/14570
    Restructure attach_volume

Addressed by: https://review.openstack.org/14959
    refactor: extract method vm_ref_or_raise

Addressed by: https://review.openstack.org/14963
    refactor: extract method: connect_volume

Addressed by: https://review.openstack.org/15028
    refactor: extract class XenAPISessionBase

This seems to have stalled, so I'm going to untarget it from Grizzly for now. Please ping me or Vish if this is picked back up.

Sorry guys, this has been a bit blocked by some Cinder work. We should have that all in place, and the local CI to test both configurations, so should get back going very soon.

Addressed by: https://review.openstack.org/19108
    Refactor: extract method: to_driver_registry

Addressed by: https://review.openstack.org/19219
    xenapi: Remove dead code, moves, tests

(?)

Work Items

Work items:
Refactor the volume attach and detach calls: INPROGRESS
Remove last traces of old nova-volume SM code: TODO
Pull volume driver related code from libvirt/driver to driver: INPROGRESS

This blueprint contains Public information 
Everyone can see this information.