Re: [openstack-dev] [Manila] FFE Request: glusterfs_native: negotiate volumes with glusterd
On 03/31/2015 10:54 AM, Csaba Henk wrote: Hi Ben, please find my answer inline. - Original Message - From: Ben Swartzlander b...@swartzlander.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, March 30, 2015 7:44:25 PM Subject: Re: [openstack-dev] [Manila] FFE Request: glusterfs_native: negotiate volumes with glusterd Thanks for going through the formal request process with this change. One question I have that's not answered here is: what is the risk of delaying this fix to Liberty? Clearly it needs to be fixed eventually, but if we hold off and allow Kilo to ship as-is, will anything bad happen? From the description above it sounds like the driver is functional, and a somewhat awkward workaround (restarting the backend) is required to deal with bug 1437176. The risk is usability of the driver. To put it like that, driver is architecturally broken -- storing all possible share backend instances in a config parameter is not something should be seen in release code. Will users be subjected to any upgrade problems going from Kilo to Liberty if we don't fix this in Kilo? Will there be any significant maintenance problems in the Kilo code if we don't change it? OpenStack distributions might be tempted to backport the fix (to arrive at a usable driver) in which case they take up a maintenance burden. Csaba Approved -Ben Swartzlander __ 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] FFE Request: glusterfs_native: negotiate volumes with glusterd
Hi Ben, please find my answer inline. - Original Message - From: Ben Swartzlander b...@swartzlander.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, March 30, 2015 7:44:25 PM Subject: Re: [openstack-dev] [Manila] FFE Request: glusterfs_native: negotiate volumes with glusterd Thanks for going through the formal request process with this change. One question I have that's not answered here is: what is the risk of delaying this fix to Liberty? Clearly it needs to be fixed eventually, but if we hold off and allow Kilo to ship as-is, will anything bad happen? From the description above it sounds like the driver is functional, and a somewhat awkward workaround (restarting the backend) is required to deal with bug 1437176. The risk is usability of the driver. To put it like that, driver is architecturally broken -- storing all possible share backend instances in a config parameter is not something should be seen in release code. Will users be subjected to any upgrade problems going from Kilo to Liberty if we don't fix this in Kilo? Will there be any significant maintenance problems in the Kilo code if we don't change it? OpenStack distributions might be tempted to backport the fix (to arrive at a usable driver) in which case they take up a maintenance burden. 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] FFE Request: glusterfs_native: negotiate volumes with glusterd
On 03/30/2015 12:21 PM, Csaba Henk wrote: Hi, I'm applying for an FFE for change https://review.openstack.org/162542 , glusterfs_native: negotiate volumes with glusterd. The change in question is in the grey zone between a bugfix and a feature. So, having it discussed with the Manila community and our PTL, Ben Swartzlander, we decided to defeat ambiguity by putting it forward as an FFE. While there is no explicit errant behavior with the current glusterfs_native driver code that would be addressed by this change, the situation is that the current version of the driver is conceptually buggy -- it does not meet consensual expectations what one has against a driver. (It would be an overstatement to call current create_share implementation a stub, but the issue is something similar.) One aspect of the limitation of create_share is captured by this bug: https://bugs.launchpad.net/manila/+bug/1437176 , glusterfs_native: Unable to create shares using newly available GlusterFS volumes without restarting manila share service We are submitting the change as a fix for this. Impact: the code adds a new, more general mechanism for picking GlusterFS volumes for backing shares. The new code is basically contained in one function, _pop_gluster_vol(); the rest of the diff is refactor to adjust the driver to the new internal API. The impact is isolated and limited to the glusterfs_native driver. The operation logic of the driver is not affected beyond backing resource allocation of in create_share. Unit test coverage is good. Csaba Henk Red Hat, Inc. Thanks for going through the formal request process with this change. One question I have that's not answered here is: what is the risk of delaying this fix to Liberty? Clearly it needs to be fixed eventually, but if we hold off and allow Kilo to ship as-is, will anything bad happen? From the description above it sounds like the driver is functional, and a somewhat awkward workaround (restarting the backend) is required to deal with bug 1437176. Will users be subjected to any upgrade problems going from Kilo to Liberty if we don't fix this in Kilo? Will there be any significant maintenance problems in the Kilo code if we don't change it? __ 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
