OST Pool Quota Test Plan

From Lustre Wiki
Revision as of 05:54, 17 March 2020 by Sergey (talk | contribs) (items from 1 to 4.2)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

The document is intended to describe the test plan for the Quota Pools(QP) Lustre feature.

QP are based on already existed OST pools and targeted to set limit per pool of OSTs instead of the whole FS.

More details could be found at OST Pool Quotas HLD and at OST Pool Quotas.

Feature Installation and Set-UP

The Quota Pools feature is new to Lustre 2.14 and does not require any commands to enable the feature. Quota limits could be set to already existed pool for user/group/project with command lfs setquota with only one new key "-o". This should point to a pool, example: lfs setquota -o "qpool1" -u "quota_user1" -B 10M.

Test Items

  1. Regression testing - acceptance testing need to be passed without regressions
  2. New feature testing - new tests should be implemented to verify all functionality provided by Quota Pools
  3. Performance testing - estimate workload added by Quota Pools
  4. Stress testing - check that user's granted space per each Quota Pool is correct despite of "stress" load
  5. Failover testing
  6. Interoperability testing
  7. Compatibility testing - check QP together with other features(DoM, PFL, DNE ethc.)

Testing Tasks with Pass/Fail Criteria

Regression testing

No new failures should be faced during t-f testing started automatically via Jenkins build.

Pass criteria: No new failed tests / regressions.

Fail criteria: Any new failing found.

New feature testing

Extra tests should be added to check that new feature works as expected. Tests should be able to create files with different striping.

Quota pools tests are introduced in sanity-quota.sh test suite.

number name description exists
1b Quota pools: Block hard limit (normal use and out of quota) Create 1 pool, add all OSTs there.

Set 2 hard limits for a user - 20M at global pool and 10M at quota pool. Check that user gets EDQUOT when reaches limit set for quota pool. Check the same for group and project.

yes
1c Quota pools: check 3 pools with hardlimit only for global Create 2 pools, add all OSTs there.

Set hard limit only for global. Set limit 0M for each pool. Check that user gets EDQUOT when reaches global limit (2 pools with zero limit don't affect global pool).

yes
1d Quota pools: check block hardlimit on different pools Create 2 pools, add all OSTs there.

Set 3 hard limits for a user: 10M - pool1, 12M - pool2 and 20 for global pool. Check that user gets EDQUOT when reaches less limit(10M).

yes
1e Quota pools: global pool with high block limit vs quota pool with small Create a pool that includes only OST1.

Set hard limit for a user: 10M - pool, 200M - global pool. Create file with a stripe only at OST1 and write there to hit limit for the pool. Then create a file with stripe only at OST0 and write there over qpool1 limit - write shouldn't fail.

yes
3b Quota pools: block soft limit (start timer, timer goes off, stop timer) Create 1 pool, add OSTs 0,1.

Set grace time - 20 s for pool and 20*3 for global pool. Set soft limit for user: (soft_least_qunit/1024)M(4M) for pool and (soft_least_qunit*2/1024)M for global pool. Check that user gets EDQUOT after pool grace time when reaches (soft_least_qunit/1024)M. Check the same for group and project.

yes
3c Quota pools: check block soft limit on different pools Create 2 pools, add OSTs 0,1.

Limits per pool for user: Limit1 = (soft_least_qunit/1024)M, limit2 = (limit1 + 4)M, global_limit = (limit1 + 8)M. Set grace per pool: pool2_grace = 20s, pool1_grace = pool2_grace + 10s, global_grace = pool2_grace + 20s. Write up to limit2. After pool2_grace seconds write should fail with EDQUOT.

yes
67 quota pools recalculation Check that granted space is correct after each pool change(create/destroy pool, add/rem OST). yes
68 slave number in quota pool changed after each add/remove OST Add and remove OSTs to the pool and check that slave number for this pool proceeds to be correct. yes
69 EDQUOT at one of pools shouldn't affect DOM Check that DOM files are not affected when user hits hard limit in a quota pool -

write up to limit in a pool to get EDQUOT, write to DOM files shouldn't fail.

yes