On 03/31/2015 10:54 AM, Csaba Henk wrote:
Hi Ben,
please find my answer inline.
----- Original Message -----
From: "Ben Swartzlander" <[email protected]>
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]>
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev