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" <b...@swartzlander.org> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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" <imalinovs...@mirantis.com> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev