Release 2.9.0

Current Schedule

 * May 31 2016 - Feature Freeze
 * July 31 2016 - Code Freeze
 * August 31 2016 - Release 2.9.0

Test Matrix

 * Servers: RHEL 7.2
 * Clients RHEL 7.2, SLES 12 SP1
 * OFED: inkernel
 * E2FSProgs: v1.42.13.wc4
 * Interoperability: 2.8 Servers/Clients

Features
The following features are under active development and could be possible for landing during the 2.9 release cycle

General Work and Maintenance
From the Lustre project page in the Lustre issue tracker, we can see a dashboard for the project. On that page under the "Versions: Unreleased" section, there are links to future releases and all of the issues that are either targeted to be addressed in that release, or are already addressed for the release. Here is a shortcut to Lustre 2.9.0's issue summary page:

Lustre 2.9.0 Issues

Any issue that contains "Lustre 2.9.0" in the "Fix Version/s" field of a ticket is intended to be fixed for version 2.9.0. The Lustre 2.9.0 Issues list is fluid, and will be updated on a continual basis as man power and perceived priorities change.

If you would like to own one or more tasks for the release but are not currently listed in the drop-down list of developers in JIRA then please email [mailto:peter.a.jones@intel.com Peter Jones] to get that setup

A convenience search filter is supplied for anyone looking for work that needs to be done for 2.9.0:

Lustre 2.9.0 Unassigned Issues

Major improvments to Lustre's RPM packaging
There are some major problems with Lustre's current RPM packing. There are a number of organizations in the Lustre development community that are contributing significant manpower to fix Lustre's build and packaging, and good progress has been made. One crucial piece of work is the support the %kernel_module_package work in LU-5614. The work in that ticket is either complete or very close to complete.

Unfortunately, Intel's build farm is not currently capable of supporting a normal packaging work flow, so we will not be able to land this patch. We will likely need to make fixing the buildfarm problem the primary task of one or more persons to get this resolved in the 2.9 time frame. Non-Intel community members are not granted adequate access to Intel's infrastructure to reasonably address these problems on its own.

It may even been that Intel does not yet understand the problems we are facing. If that is the case we need to take immediate steps to get Intel to engage in sufficient dialogue with the broader Lustre development community to understand the flaws in their build system and develop a plan to overcome those obstacles.

There are a number of other build system and packaging improvements that can be completed in the 2.9 time frame that will have fewer obstacles to success once the LU-5614 work is landed. Some are:


 * LU-7518
 * LU-7642
 * LU-7643
 * LU-6862
 * LU-6788

Also we should really support a patchless kernel in the 2.9 release using either James's suggestion in LU-20, or the more difficult fix in LU-684. LU-684 is probably achievable, but we have been discussing that change for literally years. If LU-684 remains a side project, it again will likely fail to be complete in time for the 2.9 release. Likely it will require LU-684 being someone's firm assignment for 2.9 in order to resolve the debate about approach and implementation in time for 2.9.


 * LU-20
 * LU-684

And lastly, as a stretch goal, it would be nice to finish the following ticket. However, in all likelyhood the build farm issues that are blocking LU-5614 are going to be the long pole in the tent, and not terribly likely to be addressed soon enough to allow the following work before 2.9. But if those issues are addressed quickly, that would make the following much more likely.


 * LU-3957

Overhaul Lustre Versioning
There are a number of problems with the way that Lustre is currently versioned. LU-7699 contains a series of patches that overhaul how the lustre version string is generated and embedded in the correct places.

NOTE: This will eliminate the "--downstream-release" configure option!