[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