[cdwg] Make Lustre 2.5 a maintenance release?

Christopher J. Morrone morrone2 at llnl.gov
Tue Jun 4 11:51:21 PDT 2013


Nic,

See the other thread where we're scoping 2.5.  I would love to see some 
Xyratex input there.  :)

All,

LLNL would like to see 2.5 scoped much more carefully than past 
releases.  To that end, you'll see that LLNL's proposed list of work for 
2.5 mostly fits into these categories:

   - Technical debt (unfinished OSD work, build system, etc.)
   - Long standing, ignored bugs
   - Client performance issues

I believe that we're already on the path to scoping 2.5 more 
conservatively than previous release, for instance DNE2 has been pushed 
back to 2.6 at the earliest.

But I think we have so much cleanup, bug fixing, and performance work to 
do that we'll need a full 6 months when you factor in HSM and anything 
else we need to get done.

In summary: I agree that we need to descope features for 2.5.  I think 
"as soon as possible" should be 6 months, but _really_ 6 months, not 1-2 
months late (depending on how you count) like 2.4.  Hitting the target 
this time will require much better scoping than we've done in the past.

With 2.4, there were pretty major code changes, including incompatible 
on-disk-format changes, very late in the development cycle.  I would 
like to see us avoid that in 2.5.

I would further propose that we adjust the 2.5 development cycle to be 4 
months for "feature" landing (including major technical debt code 
changes), and 2 months for RC testing, where we are really only landing 
bug fixes.  But features really, _really_ need to be fully landed at the 
end of the 4 month cycle.  We can't repeat what happened with DNE1 and 
NRS.  Allowing things like that to slip past the feature landing window 
deadline creates a domino effect of delays that result in a late release.

Chris

On 06/04/2013 11:29 AM, Nic Henke wrote:
> Sorry for the delay - but Xyratex would endorse this approach.
>
>   I think there is a discussion to have with Intel for how to handle 2.4
> -> 2.5 transition process and what we'd like to see therein. For
> instance (and this is not a Xyratex requirement!), do we greatly descope
> 2.5 in order to get a release with HSM server out as soon as possible ?
>
> Cheers,
> Nic
> *Nicholas Henke* • *Senior Filesystem Developer*
> *Xyratex*
> *office:**+1 (651)842 8471* • *mobile:**+1 (651)895 5795*
> www.xyratex.com <http://www.xyratex.com/>
> Connect with Xyratex <http://blog.xyratex.com/>
>
> On Jun 4, 2013, at 1:22 PM, "Christopher J. Morrone" <morrone2 at llnl.gov
> <mailto:morrone2 at llnl.gov>> wrote:
>
>> Folks,
>>
>> Since there have been no responses, this will not be discussed in
>> tomorrow's meeting.  This is an important decision, and one that we
>> need to make soon, and advertise well.  If this is what your
>> organization wants, please speak up.
>>
>> Chris
>>
>> On 05/22/2013 10:53 AM, Christopher J. Morrone wrote:
>>> Lustre community:
>>>
>>> As we all know, HSM is a Lustre feature that is desired by many, but was
>>> not fully completed in time for the Lustre 2.4 release.  As a result,
>>> many folks are wondering if Lustre 2.4 is really the best branch to
>>> support for a long period of time (18 or more months).
>>>
>>> HSM is very likely to be completed for 2.5, and multiple vendors and
>>> organizations are planning to move to that version, and desire long term
>>> support for that branch.
>>>
>>> On the other hand, we have for some time been advertising quite widely
>>> that Lustre 2.4 will begin the next significant maintenance branch, and
>>> some organizations have built there plans around that guidance.
>>>
>>> I would like to officially propose the following action:
>>>
>>> 1) Announce that Lustre 2.4 will have maintenance releases as planned,
>>> but the maintenance window has been shortened to just 6 months.  In
>>> other words, we will only expect to see maintenance releases on Lustre
>>> 2.4 branch for roughly 6 months.
>>>
>>> 2) Announce that the Lustre 2.5 branch will be long term maintenance
>>> branch.
>>>
>>> Are there any objections?  Any adjustments that should be made to that
>>> statement?
>>>
>>> Chris
>>> .
>>>
>>
>> _______________________________________________
>> cdwg mailing list
>> cdwg at lists.opensfs.org <mailto:cdwg at lists.opensfs.org>
>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org
>




More information about the cdwg mailing list