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

[Andreas Dilger]

On May 3, 2019, at 15:35, Hans Henrik Happe <happe at nbi.dk> wrote:
> 
> 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.

At one time there was some discussion and initial design of a
feature "Simplified Interoperability", which would allow servers to
signal the clients to pause IO operations and go into a "holding state"
while an upgrade is being done.

This has unfortunately not been an implementation priority for anyone
to date, but maybe it can be raised as an issue during the OpenSFS member
survey.

Cheers, Andreas

>>> 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
>> 
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Cheers, Andreas
--
Andreas Dilger
Principal Lustre Architect
Whamcloud