Add volume driver concept to xenapi driver
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
- Completed by
- John Garbutt
Related branches
Related bugs
Sprints
Whiteboard
Killing this off, there is some new work that will cover the remaining tasks here, moving things to oslo:
https:/
-----
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/
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/
according to nova/virt/
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 LibVirtVolumeDr
http://
It needs to be decided what should be the interface with xenapi.
a VDI ref seems reasonable.
Look at: nova/virt/
The libvirt "interface":
class LibvirtVolumeDr
def __init__(self, connection):
pass
def connect_
pass
def disconnect_
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_
- mount_device: the mount_device, that identifies the device, converted to device number by: nova/virt/
I am not sure, if the whole connection_info needs to be passed to the driver implementation. I guess, only connection_
Gerrit topic: https:/
Addressed by: https:/
Do not call directly vmops.attach_volume
Addressed by: https:/
Introduce volume manager, and drivers
Addressed by: https:/
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:/
Remove mountpoint from parse_volume_info
Addressed by: https:/
Restructure attach_volume
Addressed by: https:/
refactor: extract method vm_ref_or_raise
Addressed by: https:/
refactor: extract method: connect_volume
Addressed by: https:/
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:/
Refactor: extract method: to_driver_registry
Addressed by: https:/
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
