[lustre-discuss] 2.10 <-> 2.12 interoperability?

[Hans Henrik Happe]

On 03/05/2019 22.41, Andreas Dilger wrote:
> On May 3, 2019, at 14:33, Patrick Farrell <pfarrell at whamcloud.com> wrote:
>>
>> Thomas,
>>
>> As a general rule, Lustre only supports mixing versions on servers for rolling upgrades.
>>
>> - Patrick
> 
> And only then between maintenance versions of the same release (e.g. 2.10.6
> and 2.10.7).  If you are upgrading, say, 2.7.21 to 2.10.6 then you would need
> to fail over half of the targets, upgrade half of the servers, fail back (at
> which point all targets would be running on the same new version), upgrade the
> other half of the servers, and then restore normal operation.
> 
> There is also a backport of the LU-11507 patch for 2.10 that could be used
> instead of upgrading just one server to 2.12.
> 
> Cheers, Andreas

I think the documentation is quite clear:

http://doc.lustre.org/lustre_manual.xhtml#upgradinglustre

An upgrade path for major releases on the servers would be nice, though.
Wonder if this could be done with a mode where clients flush all they
got and are put into a blocking mode. I guess the hard part would be to
re-negotiate all the state after the upgrade, which is hard enough for
regular replays.

Cheers,
Hans Henrik

>> On Wednesday, April 24, 2019 3:54:09 AM, Thomas Roth <t.roth at gsi.de> wrote:
>>>  
>>> Hi all,
>>>
>>> OS=CentOS 7.5
>>> Lustre 2.10.6
>>>
>>> One of the OSS (one OST only) was upgraded to zfs 0.7.13, and LU-11507 forced an upgrade of Lustre to 2.12
>>>
>>> Mounts, reconnects, recovers, but then is unusable, and the MDS reports:
>>>
>>> Lustre: 13650:0:(mdt_handler.c:5350:mdt_connect_internal()) test-MDT0000: client
>>> test-MDT0000-lwp-OST0002_UUID does not support ibits lock, either very old or an invalid client: flags
>>> 0x2041401043000020
>>>
>>>
>>> So far I have not found any hints that these versions would not cooperate, or that I should have set a
>>> certain parameter.
>>> LU-10175 indicates that the ibits have some connection to data-on-mdt which we don't use.
>>>
>>> Any suggestions?
>>>
>>>
>>> Regards,
>>> Thomas
> --
> Andreas Dilger
> Principal Lustre Architect
> Whamcloud
> 
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>