[openstack-dev] [cinder] RemoteFS drivers refactoring: move code, which works with images to separate classes

Eric Harney eharney at redhat.com
Tue Oct 13 19:39:34 UTC 2015

On 10/13/2015 02:57 PM, Dmitry Guryanov wrote:
> Hello,
> RemoteFS drivers combine 2 logical tasks. The first one is how to mount
> a filesystem and select proper share for a new or existing volume. The
> second one: how to deal with an image files in given directory (mount
> point) (create, delete, create snapshot e.t.c.).
> The first part is different for each volume driver. The second - the
> same for all volume drivers, but it depends on selected volume format:
> you can create qcow2 file on NFS or smbfs with the same code.
> Since there are several volume formats (raw, qcow2, vhd and possibly
> some others), I propose to move the code, which works with image to
> separate classes, 'VolumeFormat' handlers.
> This change have 3 advantages:
> 1. Duplicated code from remotefs driver will be removed.
> 2. All drivers will support all volume formats.
> 3. New volume formats could be added easily, including non-qcow2 snapshots.
> Here is a draft version of a patch:
> https://review.openstack.org/#/c/234359/
> Although there are problems in it, most of the operations with volumes
> work and there are only about 10 fails in tempest.
> I'd like to discuss this approach before further work on the patch.

I've only taken a quick look, but, a few comments:

IMO it is not a good idea to work on extending support for volume
formats until we get further on having Cinder manage data in different
formats in a robust and secure manner [1]. We should fix that problem
before making it a worse problem.

Points 2 and 3 above aren't really that straightforward.  For example,
calling delete_snapshot_online only works if Nova/libvirt/etc. support
managing the format you are using.  This is fine for the current uses,
because qcow2 is well-supported.  Adding this to a driver using a
different/new file format will likely not work, so combining all of the
code is questionable, even if it seems more nicely organized.

Point #2 assumes that there's a reason that someone would want to use
currently unsupported combinations such as NFS + VHD or SMB + qcow2.
The specific file format being used is not terribly interesting other
than in the context of what a hypervisor supports, and we don't need
more not-so-well-tested combinations for people to deploy.  So why
enable this?

We've already gone somewhat in the other direction with [2], which
removed the ability to configure the GlusterFS driver to use qcow2
volumes, and instead just lets you choose if you want thick or thinly
provisioned volumes, leaving the format choice as an implementation
detail rather than a deployment choice.  (It still uses qcow2 behind the
scenes.)  I think that's the right direction.

[1] https://review.openstack.org/#/c/165393/
[2] https://review.openstack.org/#/c/164527/

More information about the OpenStack-dev mailing list