[cdwg] [wc-discuss] Lustre 2.2.0 released

[Peter Jones]

Just getting back to this now and I think that Andreas has covered most 
of the points I would have made below.

I would like to emphasize though that - contrary to James's definition 
of a feature release - we _do_ support feature releases for production 
usage (we have customers running 2.2 in production) and we do land 
bugfixes throughout the release cycle (Lustre 2.2 contained a superset 
of the bugfixes in 2.1.1 and more, for example)

I can certainly sympathize with Chris's viewpoint that it would be 
helpful to have a fixed pre-announced cycle for which branches will end 
up as maintenance release streams.

When we announced this scheme over a year ago there were so many 
variables  - the rate of Lustre 2.x adoption, what features would be in 
which releases, how would Lustre 2.x compare to Lustre 1.8.x in 
production - that it seemed prudent to make a more informed decision 
nearer the time.

The other aspect not touched upon is that we may not need to stick to 
this model in the longer-term. We introduced this approach as a way of 
directing scarce engineering/testing resources where they would have 
maximum benefit, but as we increase the amount of test automation we 
have in place, it may become more practical to revisit this decision and 
provide maintenance releases for a fixed timeline rather than for a 
targeted release stream.

As usual, everything boils down to how much of a priority this is 
compared to other things we could be spending time on.

On 12-06-18 10:44 AM, Andreas Dilger wrote:
> On 2012-06-18, at 10:19 AM, Christopher J. Morrone wrote:
>> Our "maintenance" releases are currently something like an LTS, but they are not well advertised, poorly understood by the community, and currently evolve rather organically.
>>
>> No large site can change major lustre versions every six months.  No major vendors will be willing to do that either.  I think we all know and agree about that.
>>
>> But if we don't have a clear plan for which releases with be LTS and advertise that AHEAD of time, we'll never sync up on releases, and our limited resources will continue to be divided.  Vendors and large sites just can't turn on a dime.  We need clear guidance well in advance of a maintenance/LTS release if we are going to plan to move to it in a reasonable time frame.
> I agree, but we can't make that decision in isolation.  I agree that advance discussion and notification is important, but there has to be buy-in from the users about this.  I'm not totally against someone using e.g. 2.2, since it does provide valuable production feedback for the changes from 2.1 to 2.2, but I think this needs to be done with the understanding that the "maintenance" stream for 2.2 will be 2.3 and then 2.4, and finally 2.4.1, 2.4.2 (assuming that is the next maintenance release).
>
>> My suggestion:
>>
>> Every 18 months, the release will be designated an LTS release.
>>
>> If we consider 2.1 an LTS release, that would make the release at the end of March 2013 the next LTS release.
>>
>> I don't care too much about the numbering.  It could be called 2.4, it could be called 3.0, whatever.  What is important is that we plan for it and advertise it well in advance.
>>
>> I think that the March 2013 release will have a combination of many features that people are interested in, including the OSD rework, DNE1, imperative recovery, network request scheduled, just to name a few off the top of my head.
> I tend to agree.  This will be the release that contains a majority of the first round of OpenSFS features (except DNE2 and LFSCK3/4).
>
>> I know that LLNL has been testing master for a while now as part of our orion-branch testing, and we will continue to test and hammer it on Sequoia.  If we are planning to make that release the next LTS, we will migrate ALL of our testing resources to exercise that work as soon as 2.1 is reasonably stable on our production systems.  So my sincere hope is that by the time the March 2013 release happens it will be in much better shape than the 2.1 release was.
>
> Cheers, Andreas
> --
> Andreas Dilger                       Whamcloud, Inc.
> Principal Lustre Engineer            http://www.whamcloud.com/
>
>
>
>
>
>

-- 
Peter Jones
Whamcloud, Inc.
www.whamcloud.com