Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev