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
