On 03/16/2016 10:02 AM, Csaba Henk wrote:
Hi,
I'm asking for a Feature Free Exception for the update_access code for
Ganesha library and the two GlusterFS drivers (glusterfs, glusterfs-native).
This benefits the whole project in terms of getting closer to the point
when the backward compatiblitly hooks for the old driver access API can
be retired. There is no change in functionality, except for one thing:
the new code takes advantage of the new semantic feature of
update_access, that is, recovery situation is explicit; thus with
Ganesha, where actually a reset/restore operation can be performed, we
can trigger this mechanism only if really that's what's being asked for
(contrary to the earlier practice where reset/restore was done on each
m-shr startup).
The impact of the change is limited to the GlusterFS drivers (Ganesha
library currently is used only for these drivers).
The following changes are proposed:
https://review.openstack.org/282602 ("ganesha: implement update_access")
https://review.openstack.org/291151 ("glusterfs: Implement
update_access() method")
Sorry for the slow response. I have discussed this with some other cores
and while I have mixed feelings, considering Doug's input I think I must
deny this.
I told a few different driver maintainers that I would grant FFEs for
update_access() changes due to how late the feature went into Mitaka,
but when I made those promises I was imagining the patches would be
available shortly after feature freeze. These patches come when we're
down to just a few bugs before we cut the RC, and risk is the biggest
thing on my mind.
A major factor in this decision is the fact that glusterfs is not the
only driver lacking an implementation for update_access(), so we
couldn't remove the fallback path even if we did merge these changes.
Csaba, thank you for getting these changes done and we will merge them
early in Newton. We need to decide as a community how to get the
remaining drivers updated in Newton so we can remove the fallback path.
-Ben Swartzlander
Thanks,
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
__________________________________________________________________________
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
