[Gluster-devel] Rolling upgrades from glusterfs 3.4 to 3.5

[Anand Avati]

On Thu, Jun 12, 2014 at 10:47 AM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
> On 06/12/2014 11:16 PM, Anand Avati wrote:
>
>
>
>
> On Thu, Jun 12, 2014 at 10:39 AM, Ravishankar N <ravishankar at redhat.com>
> wrote:
>
>> On 06/12/2014 08:19 PM, Justin Clift wrote:
>>
>>> On 12/06/2014, at 2:22 PM, Ravishankar N wrote:
>>> <snip>
>>>
>>>> But we will still hit the problem when rolling upgrade is performed
>>>> from 3.4 to 3.5,  unless the clients are also upgraded to 3.5
>>>>
>>>
>>> Could we introduce a client side patch into (say) 3.4.5 that helps
>>> with this?
>>>
>>  But the client side patch is needed only if Avati's server (posix) fix
>> is present. And that is present only in 3.5 and not 3.4 .
>
>
>
>  The client can actually be fixed to be compatible with both old and new
> servers. We can change the errno from ESTALE to ENOENT before doing the
> GFID mismatch check in client_lookup_cbk.
>
> But this will require a two hop upgrade. Is that normal/acceptable?
>

One hop is always better than two hops. But at least we have a way out. It
is not at all unreasonable to have clients be of a minimum version for
rolling upgrades to work (upgrade still works no matter what the client
versions are if they are doing read-only access).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140612/b7091b12/attachment.html>