Re: [openstack-dev] [Manila] Question to driver maintainers
Hi Igor, The 3PAR can extend a share without loss of connectivity. Regards, markstur From: yang, xing [mailto:xing.y...@emc.com] Sent: Friday, May 22, 2015 3:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Question to driver maintainers Hi Igor, We can support extending a share without loss of connectivity, but we don’t support shrinking. Thanks, Xing From: Jason Bishop [mailto:jason.bis...@gmail.com] Sent: Thursday, May 21, 2015 8:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Question to driver maintainers Hi Igor, Hitachi SOP drive can support share extending online without disruption. cheers jason On Mon, May 18, 2015 at 1:15 AM, Igor Malinovskiy imalinovs...@mirantis.commailto:imalinovs...@mirantis.com wrote: Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
Re: [openstack-dev] [Manila] Question to driver maintainers
Hi Igor, We can support extending a share without loss of connectivity, but we don’t support shrinking. Thanks, Xing From: Jason Bishop [mailto:jason.bis...@gmail.com] Sent: Thursday, May 21, 2015 8:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Question to driver maintainers Hi Igor, Hitachi SOP drive can support share extending online without disruption. cheers jason On Mon, May 18, 2015 at 1:15 AM, Igor Malinovskiy imalinovs...@mirantis.commailto:imalinovs...@mirantis.com wrote: Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
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 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 lpa...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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 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 __ 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
Re: [openstack-dev] [Manila] Question to driver maintainers
Small correction follows, Csaba - Original Message - From: Csaba Henk ch...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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 lpa...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@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 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
Re: [openstack-dev] [Manila] Question to driver maintainers
Hi Igor, Hitachi SOP drive can support share extending online without disruption. cheers jason On Mon, May 18, 2015 at 1:15 AM, Igor Malinovskiy imalinovs...@mirantis.com wrote: Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ 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
Re: [openstack-dev] [Manila] Question to driver maintainers
Hello Igor, share extending works without interruption in Quobyte storage. Best regards Silvan 2015-05-18 10:15 GMT+02:00 Igor Malinovskiy imalinovs...@mirantis.com: Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ 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 -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- -- *Quobyte* GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ 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
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 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
Re: [openstack-dev] [Manila] Question to driver maintainers
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) (*) 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
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-dev] [Manila] Question to driver maintainers
Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ 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
Re: [openstack-dev] [Manila] Question to driver maintainers
Hi, Igor. The NetApp cDOT driver can handle share extend/shrink without disruption. Clinton From: Igor Malinovskiy imalinovs...@mirantis.commailto:imalinovs...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, May 18, 2015 at 4:15 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Manila] Question to driver maintainers Hello, everyone! My letter is mainly addressed to driver maintainers, but could be interesting to everybody. As you probably know, on Kilo midcycle meetup we discussed share resize functionality (extend and shrink) and I already have implemented 'extend' API in Generic driver (https://review.openstack.org/182383/). After implementation review we noticed that some backends are able to resize a share without causing disruptions, but others might only be able to do it disruptively (Generic driver case). So I want to ask driver maintainers here: Will your driver be able to do share extending without loss of connectivity? Depending on your answers, we will handle this situation differently. Best regards, Igor Malinovskiy (IRC: u_glide) Manila Core Team __ 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
