[cdwg] Lustre Maintenance Release Plan

Thu Aug 2 00:07:06 PDT 2012

On 2012-08-01, at 7:43, Diego Moreno <Diego.Moreno-Lazaro at bull.net> wrote:
> 
> First of all, thanks for this very interesting point you are dealing with. I think that this release plan really fits in with what Lustre community expects from Lustre and the resources available for testing new releases. But there's still one point which is not totally clear for me: rolling upgrades between releases. I suppose this plan means that a proper transition between maintenance releases is guaranteed but what about feature releases? If I take the example of 1.6, 1.8 and 2.1 I guess it'd be something like:
> 
> - From 2.1, upgrade to 2.2, 2.3 and 2.4 would be possible.
> 
> - It wouldn't be possible to upgrade from 2.1 to 2.5, 2.6 or 2.7 without going through the next maintenance release (2.4).

It isn't yet clear what the policy is for such upgrades. Using 1.6 and 1.8 may be bad examples in this case, because they were in use for such a long time, and were both feature and maintenance releases at the same time. 

There are two issues here - what versions of Lustre will have interoperable wire protocols, and which betsions will have compatible disk formats?

The wire protocol is much more difficult to maintain, because it involves all of the state of the clients and servers, and is visible across all of them. This means that keeping Lustre wire protocol interoperable across many releases would need a huge amount of testing effort, though of course we do our best. With the increasing frequency of major releases, we will likely have to do testing only between the latest feature releases, and maintenance releases, and drop testing with old feature releases older than the most recent maintenance release. 

On the other hand, the disk format is an internal implementation of the server, and is isolated from other servers and clients. We very rarely change the disk format in an incompatible way going forward.  In the past, the main issue has been the config records are not forward compatible.

New features like DNE will not create incompatible on disk changes until they are enabled, and we've still worked to allow old 1.8-formatted filesystems to be able to upgrade to DNE.

Of course, this effort all has a cost, and that cost can be reduced by limiting the number of different releases we have to support. One of the ways we limit the interoperability testing is to not allow formatting a new filesystem, then running it with an old version of Lustre. This allows enabling new features aitomatically at format time, without worrying about how they can be made to work with older versions of Lustre. 

 So far, I'm not aware of anything that prevents 1.8 from being upgraded to 2.3, but there are definitely features in every release that would prevent new filesystems from being downgraded beyond the version they were formatted on.

> So, in consequence, and with regard to maintenance releases:
> 
> - At the end of life of a maintenance release (for instance, September 2014 for Lustre 2.1), even if a new maintenance release is available (Lustre 2.7) upgrading would not be possible without going though the previous maintenance release (lustre 2.4).

The 
Aim question is whether anyone actually does this in practice?  If someone has stuck with an old version of Lustre for 3 years, will they want to upgrade immediately to the brand new version, or would they prefer to move to the next maintenance release that has been tested for almost two years?

Cheers, Andreas

> What do you think?
> 
> Diego
> 
> On 07/31/2012 03:46 AM, Christopher J. Morrone wrote:
>> Lustre Maintenance Release Plan
>> -------------------------------
>> 
>> Lustre maintenance branches host the releases of lustre that we shall
>> advertise to the general public as "stable" releases.  The goal of a
>> maintenance branch is to include only bug fixes, to ensure a stable
>> releases for a significant period of time.
>> 
>> We currently have a development cadence that puts out a "feature"
>> release of Lustre every 6 months.  This is going reasonably well, and we plan to continue that process.  However, we do not have the resources to ensure that every six month release is entirely bug-free, nor do we have the resources to add a new branch every six months that will receive only bug, and be maintained for years.  We are not able to reasonably support and test that many branches in parallel at our current level of investment, nor would we wish to, as the testing requirements rise exponentially as the number of supported branches increases.
>> 
>> We have decided that every third feature release, occurring every 18
>> months, will also be the beginning of a maintenance branch.  Tagged
>> maintenance releases along the maintenance branch will occur on an
>> as-needed basis, according to the demands of discovered bugs and their
>> severity.  It is likely that tags will occur more frequently early in
>> the branch's lifetime, and taper off in the later months and years.
>> 
>> We plan to make the initially advertised lifetime of a maintenance
>> branch three years.
>> 
>> We agreed that Lustre 2.4 will begin the next maintenance branch, which
>> has a targeted release date of the end of March, 2013.
>> 
>> None of this precludes ad-hoc maintenance releases on other branches. For instance, there was discussion in the CDWG that some institutions plan to run Lustre 2.3, and may need a "mini-maintenance" release to hold them over until Lustre 2.4.  We just note that those "mini-maintenance" releases will be made as the participants have the time and desire to work on them, and that they will be made on an as-needed, and ad-hoc manner.
>> 
>> We will continue to refine our terminology to help avoid confusion.
>> 
>> To reiterate, out basic plan of record is:
>> 
>> - Next official maintenance branch will be 2.4 (end of March 2013)
>> - Official maintenance branches will start every 18 months
>> - Official maintenance branches will be supported for 3 years
>> 
>> Chris
>> _______________________________________________
>> cdwg mailing list
>> cdwg at lists.opensfs.org
>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
> 
> 
> _______________________________________________
> cdwg mailing list
> cdwg at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org