Lustre Quality

In the past Lustre had a reputation for being fast, but unstable. The reason for this was that changes to the code were made with insufficient thought and testing ahead of time.

A lot of work has been put into stabilizing Lustre over the years and we have evolved processes to ensure we maintain the stability that so many sites worldwide now rely on operationally.

The processes below are the same that we follow internally at Whamcloud.

This presentation by Eric Barton (from SC10) elaborates on these themes.

Landing a Patch to a Maintenance Release

Whamcloud produces maintenance releases every 3 months. Check the Whamcloud Lustre Roadmap to find out when the next one is scheduled and which codeline it will be against.

Note that landings for the release will freeze a month prior to GA.

Pre-requisites

Before getting started please read over the background material on Patch Landing Process, Signed Off By, Using Gerrit and Requirements for Patch Submission

Patch Landing Checklist

1. All code conforms to the Coding Guidelines
2. A JIRA ticket has been opened to track the issue
3. The commit comment is well formatted
4. A regression test has been created that fails without the patch and passes with the patch
5. The patch has been uploaded to Gerrit with the appropriate signed off by line

Landing a Patch to a Feature Release

Whamcloud produces feature releases every 6 months. Check the Whamcloud Lustre Roadmap to find out when the next one is scheduled.

First Steps

Before starting to think about the logistics associated with developing your feature it is imperative to share your plans with the Lustre community before you start work.

If you choose not to do this you may find that you are either duplicating work with someone else or that your work needs to be repeated to accommodate some other changes occurring in the same part of Lustre code.

It is also strongly suggested that you gain experience in the Lustre landing process by fixing one or more bugs for a maintenance release before attempting to tackle writing a Lustre feature. Feel free to ask for suggestions on the wc-discuss mailing list for a suitable bug to get started with.

Schedule and Timing

Whamcloud Lustre releases operate to a "train model". The schedule is fixed and will not wait for features that are not ready in time - they are deferred to the next release.

History has shown that a lengthy stabilization period is needed after all features have landed to work through bugs introduced by the new code.

For a feature release scheduled for release in month T the schedule is roughly as follows. For more precise dates, keep up to date on the wc-discuss mailing list .

1. T-7 A call for features is sent out to the wc-discuss mailing list . The amount of change that can be landed for a given release is limited so it is prudent to respond early if you feel that you will have a feature that warrants consideration for inclusion. Expect to be asked to provide the information on the Feature Landing Checklist below - either completed or with estimates as to when any missing portions will be completed.
2. T-6 Initial review of candidate features to define the scope of the release. A test plan is created and the Whamcloud Lustre Roadmap is updated. Landing schedule created so that feature landings are spaced out to make it easier to identify when features introduce regressions. If serious regressions are found when a feature is landed then it will be reverted from master until the problems have been addressed
3. T-3 Feature Freeze - bug fixes only from now on. The Whamcloud Lustre Roadmap is updated.
4. T-1 Code Freeze - critical bug fixes only from now on. A release candidate (RC) is tagged and release testing commences
5. T GA announced and RPMs available for download from the Whamcloud download site

Feature Landing Checklist

1. High level design has been reviewed and signed off by a senior Whamcloud engineer
2. Test plan has been reviewed and signed off by a senior Whamcloud engineer. The test plan should include performance testing
3. Results from executing the test plan uploaded into Maloo
4. Proposed revisions to the manual have been provided
5. The criteria from the Patch Landing Checklist (above) are met

Seeking Guidance

Please alert the Whamcloud team via the wc-discuss mailing list if you need some extra guidance in getting your patch submitted for the release.