Lustre Test Plans
Test plans for upcoming Lustre releases are now available for review and comment. As an open-source product, we invite the Lustre user community to contribute to our efforts to develop and test a more robust, feature-rich Lustre.
If you would like to comment on the posted test plans, click the Discussion tab at the top of the page and enter:
- Your name and email address
- Date of your comment
- Test plan you are commenting on (e.g., 1.6.6, 1.8, 2.0) and page number, if applicable
- Comment or suggestion. If you have a proposed test case, paste it into your comment.
The Lustre Test group will review these comments, update test plans as needed, and post updated plans to this page.
Test plans are available for upcoming Lustre releases.
Lustre 1.8 Test Plan
Lustre 2.0 Test Plan (coming soon)
This section lists the feature test plans used by the Lustre QE team.
This is the Test Plan for OST Pools. The objective is to test OST Pools on a large-scale cluster to make sure the feature is scalable, and verify that file creation performance is the same (with or without OST Pools).
This is the Test Plan for Lustre Quotas. The test plan's objective is to:
- Thoroughly test the quotas feature (block and inode quotas for users and groups) for each new Lustre release (during pre-release testing)
- Focus on quotas hard limits
- Find and document problems with quotas (and add them as release blockers).
- Deliver working quotas feature code to Cray, Inc. with each new Lustre release and avoid bugs (especially regressions)
The components to be tested are:
- lustre quotas feature code
This is the Test Plan for Security Features. The test plan's objective is to find defects in the Lustre 2.0 security features and drive the security source code to a stable, production-ready state. The test plan contains:
- Complete acceptance-small (acc-sm) run that shifts among different security flavors (null, krb5i and krb5p) between tests.
- Complete I/O benchmark (IOR and mdsrate), to run against all Lustre-supported security flavors (null, plain, krb5n, krb5a, krb5i and krb5p), gather and analyze performance data.
This is the Test Plan for Version-Based Recovery. The test plan's objective is to verify that Version-Based Recovery works with a large system.