[openstack-dev] [nova] Plan to consolidate FS-style libvirt volume drivers under a common base class

Duncan Thomas duncan.thomas at gmail.com
Wed Jun 17 13:14:02 UTC 2015


On 17 June 2015 at 15:36, Dmitry Guryanov <dguryanov at parallels.com> wrote:

> On 06/17/2015 02:14 PM, Duncan Thomas wrote:
>
>> On 17 June 2015 at 00:21, Matt Riedemann <mriedem at linux.vnet.ibm.com
>> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>>
>>     The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are
>>     all very similar.
>>
>>     I want to extract a common base class that abstracts some of the
>>     common code and then let the sub-classes provide overrides where
>>     necessary.
>>
>>     As part of this, I'm wondering if we could just have a single
>>     'mount_point_base' config option rather than one per backend like
>>     we have today:
>>
>>     nfs_mount_point_base
>>     glusterfs_mount_point_base
>>     smbfs_mount_point_base
>>     quobyte_mount_point_base
>>
>>     With libvirt you can only have one of these drivers configured per
>>     compute host right?  So it seems to make sense that we could have
>>     one option used for all 4 different driver implementations and
>>     reduce some of the config option noise.
>>
>>
>> I can't claim to have tried it, but from a cinder PoV there is nothing
>> stopping you having both e.g. an NFS and a gluster backend at the same
>> time, and I'd expect nova to work with it. If it doesn't, I'd consider
>> it a bug.
>>
>
> I agree, if 2 volume backends will use the same share definition, like
> "10.10.2.3:/public" you'll get the same mountpoint for them.
>

I meant that you should be able to have two complete separate backends,
with two different mount points (e.g. /mnt/nfs, /mnt/gluster) and use both
simultaneously, e.g. two different volume types.

-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150617/eb859911/attachment.html>


More information about the OpenStack-dev mailing list