Open Stack

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