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

Luis Pabon lpabon at redhat.com
Wed May 20 19:13:16 UTC 2015


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



More information about the OpenStack-dev mailing list