Open Stack

Small correction follows, 

Csaba

----- Original Message -----
> From: "Csaba Henk" <chenk at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> 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" <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
> > 
> 
> __________________________________________________________________________
> 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
>