[openstack-dev] [Manila] Question to driver maintainers

Csaba Henk chenk at redhat.com
Thu May 21 13:28:04 UTC 2015


Hi Ben and Luis,

TL;DR: it was my misunderstanding and both glusterfs* drivers
will be able to support resize (extension and shrinking) without
disruption.

There was no doubt about that GlusterFS supports a volume resize
operation. What I had a problem with is that the API to it is too
low level -- ATM there is no such high-level unary command as
"gluster volume resize <volume>", but one also has to specify the
resources which are pulled in to facilitate the extension
(or the administrator can do the extension out of band, ie. not
through the gluster command). Specifying such entities would be
problematic if it was to be done from Manila context.

However, what I realized after consulting the gluster folks is
that with our data model(s) we don't have to do a volume resize
to facilitate a share resize, we can rely on the high level
part of the gluster management interface. 

Csaba

----- Original Message -----
> From: "Luis Pabon" <lpabon at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, May 20, 2015 9:13:16 PM
> Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
> 
> Hi guys, I am a little confused and would like to maybe clear some things up.
> GlusterFS (the storage system) does support the ability to resize volumes.
> I will talk to Csaba and see what he means, and we will get back to you
> soon.
> 
> ----- Original Message -----
> From: "Ben Swartzlander" <ben at swartzlander.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Sent: Tuesday, May 19, 2015 12:41:31 PM
> Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
> 
> On 05/19/2015 10:42 AM, Csaba Henk wrote:
> > Hi Igor,
> >
> >> From: "Igor Malinovskiy" <imalinovskiy at mirantis.com>
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> <openstack-dev at lists.openstack.org>
> >> Sent: Monday, May 18, 2015 10:15:25 AM
> >> Subject: [openstack-dev] [Manila] Question to driver maintainers
> > ...
> >> So I want to ask driver maintainers here:
> >> Will your driver be able to do share extending without loss of
> >> connectivity?
> > Currenty:
> >
> > - glusterfs driver can
> > - glusterfs-native won't support share extension (*)
> >
> > in Liberty timeframe, we are to unify the glusterfs* drivers' backend
> > management logic, so both glusterfs driver style and glusterfs-native
> > driver style backend management will be available for both drivers
> > (actual choice made in configuration). So when this will be in place,
> > the answer modifies as follows:
> >
> > - glusterfs and glusterfs-native will either support non-disruptive
> >    share extension, or won't support share resize at all (*) (depending
> >    on configuration)
> 
> Csaba, this is a truly interesting set of limitations! I'm trying to
> understand what's going on down in the storage system to prevent the
> extension. Is it a case of not having enough free space? Or can you
> support creating new (larger) shares on the same backend while
> simultaneously not being able to resize an existing share? Is there some
> mapping to physical resources that's immutable once configured? What is
> your recommendation to customers who run out of space in a glusterfs
> share today (independent of Manila)?
> 
> If your system can't support this case then I'm worried others may have
> similar problems and we could end up having to choose between making
> extend an optional operation (a choice I don't like) or making the
> glusterfs-native driver and possibly other drivers unsupported (also an
> option I don't like).
> 
> -Ben
> 
> > (*) There are efforts to remove this limitation in GlusterFS, but too
> > vague at this point to make a statement on it.
> >
> > Csaba
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list