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