Release 2.9.0: Difference between revisions

From Lustre Wiki
Jump to navigation Jump to search
Line 13: Line 13:
* E2FSProgs: v1.42.13.wc4
* E2FSProgs: v1.42.13.wc4
* Interoperability: 2.8 Servers/Clients
* Interoperability: 2.8 Servers/Clients
=== 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 [https://jira.hpdd.intel.com/browse/LU-5614 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:
* [https://jira.hpdd.intel.com/browse/LU-7518 LU-7518]
* [https://jira.hpdd.intel.com/browse/LU-7642 LU-7642]
* [https://jira.hpdd.intel.com/browse/LU-7643 LU-7643]
* [https://jira.hpdd.intel.com/browse/LU-6862 LU-6862]
* [https://jira.hpdd.intel.com/browse/LU-6788 LU-6788]
Also we should really support a patchless kernel in the 2.9 release using either Jason'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.
* [https://jira.hpdd.intel.com/browse/LU-20 LU-20]
* [https://jira.hpdd.intel.com/browse/LU-684 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.
* [https://jira.hpdd.intel.com/browse/LU-3957 LU-3957]


=== General Work and Maintenance ===
=== General Work and Maintenance ===

Revision as of 15:34, 14 January 2016

Current Schedule

  • March 31 2016 - Feature Freeze
  • May 31 2016 - Code Freeze
  • June 30 2016 - Release 2.9.0

Scope

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

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:

Also we should really support a patchless kernel in the 2.9 release using either Jason'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.

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.

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 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

Features

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

Feature Developers Reviewers Testers Docs Confirmed in 2.9
UID/GID Mapping Kit Westneat John Hammond Sébastien Buisson Nathan Lavender Nathan Lavender Not yet
Shared Key Crypto Jeremy Filizetti John Hammond Sébastien Buisson Nathan Lavender Nathan Lavender Not yet
NRS Delay Policy Chris Horn Henri Doreau Justin Miller Chris Horn Not yet
Lock Ahead Patrick Farrell TBD Justin Miller Patrick Farrell Not yet
Subdirectory Mounts Wang Shilong Andreas Dilger Niu Yawei TBD Wang Shilong Not yet
Server Side Advise and Hinting Li Xi TBD TBD Li Xi Not yet