Release 2.9.0: Difference between revisions

From Lustre Wiki
Jump to navigation Jump to search
m (→‎Features: fix intel URLs)
m (Fix Intel URLs)
 
Line 36: Line 36:
=== General Work and Maintenance ===
=== General Work and Maintenance ===


From the [https://jira.hpdd.intel.com/browse/LU Lustre project page] in the [https://jira.hpdd.intel.com 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:
From the [https://jira.whamcloud.com/browse/LU Lustre project page] in the [https://jira.whamcloud.com 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:


   [https://jira.hpdd.intel.com/browse/LU/fixforversion/11891 Lustre 2.9.0 Issues]
   [https://jira.whamcloud.com/browse/LU/fixforversion/11891 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.
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
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:pjones@whamcloud.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:
A convenience search filter is supplied for anyone looking for work that needs to be done for 2.9.0:
Line 53: Line 53:
in the Lustre development community that are contributing significant manpower to fix Lustre's build and
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
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
work in [https://jira.whamcloud.com/browse/LU-5614 LU-5614].  The work in that ticket is either complete
or very close to complete.
or very close to complete.


Unfortunately, Intel's build farm is not currently capable of supporting a normal packaging work flow, so we
Unfortunately, the 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.
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-community members are not granted adequate access to the build 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:
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.whamcloud.com/browse/LU-7518 LU-7518]
* [https://jira.hpdd.intel.com/browse/LU-7642 LU-7642]
* [https://jira.whamcloud.com/browse/LU-7642 LU-7642]
* [https://jira.hpdd.intel.com/browse/LU-7643 LU-7643]
* [https://jira.whamcloud.com/browse/LU-7643 LU-7643]
* [https://jira.hpdd.intel.com/browse/LU-6862 LU-6862]
* [https://jira.whamcloud.com/browse/LU-6862 LU-6862]
* [https://jira.hpdd.intel.com/browse/LU-6788 LU-6788]
* [https://jira.whamcloud.com/browse/LU-6788 LU-6788]


Also we should really support a patchless kernel in the 2.9 release using either James's suggestion in LU-20, or
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.
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.whamcloud.com/browse/LU-20 LU-20]
* [https://jira.hpdd.intel.com/browse/LU-684 LU-684]
* [https://jira.whamcloud.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.
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]
* [https://jira.whamcloud.com/browse/LU-3957 LU-3957]


=== Overhaul Lustre Versioning ===
=== Overhaul Lustre Versioning ===


There are a number of problems with the way that Lustre is currently versioned.
There are a number of problems with the way that Lustre is currently versioned.
[https://jira.hpdd.intel.com/browse/LU-7699 LU-7699] contains a series of patches that overhaul how the lustre version string is generated and embedded in the correct places.
[https://jira.whamcloud.com/browse/LU-7699 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!
NOTE: This will eliminate the "--downstream-release" configure option!


[[Category: Releases]]
[[Category: Releases]]

Latest revision as of 11:56, 1 July 2019

Current Schedule

  • May 31 2016 - Feature Freeze
  • Q4 2016 - Code Freeze
  • Q4 2016 - Release 2.9.0

Scope

Test Matrix

  • Servers: RHEL 7.3
  • Clients RHEL 7.3, SLES 12 SP1
  • OFED: inkernel
  • E2FSProgs: v1.42.13.wc5
  • 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

Feature Developers Reviewers Testers Docs Confirmed in 2.9
UID/GID Mapping Kit Westneat John Hammond Sébastien Buisson Nathan Lavender Nathan Lavender Yes
Shared Key Crypto Jeremy Filizetti John Hammond Sébastien Buisson Nathan Lavender Nathan Lavender Yes
Subdirectory Mounts Wang Shilong Andreas Dilger Niu Yawei Shuichi Ihara Wang Shilong Yes
Server Side Advise and Hinting Li Xi Wang Shilong Andreas Dilger Shuichi Ihara Li Xi Yes
Large Bulk IO Gu Zheng Jinshan Xiong Zhenyu Xu Shuichi Ihara Li Xi Yes

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

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, the 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-community members are not granted adequate access to the build infrastructure to reasonably address these problems on its own.

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

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.

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!