Small correction follows, Csaba
----- Original Message ----- > From: "Csaba Henk" <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Sent: Thursday, May 21, 2015 3:28:04 PM > Subject: Re: [openstack-dev] [Manila] Question to driver maintainers > > 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 ... that would of course be a binary command like "gluster volume resize <volume> <size>" > 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" <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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" <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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" <[email protected]> > > >> To: "OpenStack Development Mailing List (not for usage questions)" > > >> <[email protected]> > > >> 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: > > > [email protected]?subject:unsubscribe > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
