Complete quota tests

- Test that we properly account for deletions between count items runs. - Test that we can expire objects when a bucket has a quota enabled. Issue: ZENKO-4941
scality · Nov 28, 2024 · b11a2e2 · b11a2e2
1 parent 85ef4ed
commit b11a2e2
Showing 1 changed file with 70 additions and 0 deletions.
diff --git a/tests/ctst/features/quotas/Quotas.feature b/tests/ctst/features/quotas/Quotas.feature
@@ -96,3 +96,73 @@ Feature: Quota Management for APIs
             | 100        | 200         | 0            | IAM_USER |
             | 100        | 0           | 200          | IAM_USER |
             | 100        | 200         | 200          | IAM_USER |
+
+    @2.6.0
+    @PreMerge
+    @Quotas
+    @CronJob
+    @DataDeletion
+    @NonVersioned
+    Scenario Outline: Quotas are affected by deletion operations between count items runs
+        Given an action "DeleteObject"
+        And a permission to perform the "PutObject" action
+        And a STORAGE_MANAGER type
+        And a bucket quota set to 10000 B
+        And an account quota set to 10000 B
+        And an upload size of 1000 B for the object "obj-1"
+        And a bucket quota set to <bucketQuota> B
+        And an account quota set to <accountQuota> B
+        And a <userType> type
+        And an environment setup for the API
+        And an "existing" IAM Policy that "applies" with "ALLOW" effect for the current API
+        When I wait 3 seconds
+        And I PUT an object with size <uploadSize>
+        Then the API should "fail" with "QuotaExceeded"
+        When the "count-items" cronjobs completes without error
+        When I wait 3 seconds
+        # At this point if negative inflights are not supported, write should
+        # not be possible, as the previous inflights are now part of the current
+        # metrics.
+        And i delete object "obj-1"
+        And I wait 3 seconds
+        And I PUT an object with size <uploadSize>
+        Then the API should "succeed" with ""
+
+        Examples:
+            | uploadSize | bucketQuota | accountQuota | userType |
+            | 100        | 200         | 0            | ACCOUNT  |
+            | 100        | 0           | 200          | ACCOUNT  |
+            | 100        | 200         | 200          | ACCOUNT  |
+            | 100        | 200         | 0            | IAM_USER |
+            | 100        | 0           | 200          | IAM_USER |
+            | 100        | 200         | 200          | IAM_USER |
+
+    @2.8.0
+    @PreMerge
+    @Quotas
+    @Restore
+    @Dmf
+    @ColdStorage
+    Scenario Outline: Restored object expiration updates quotas
+        Given an action "<action>"
+        And a STORAGE_MANAGER type
+        And a transition workflow to "e2e-cold" location
+        And an upload size of <uploadSize> B for the object "obj-1"
+        Then object "obj-1" should be "transitioned" and have the storage class "e2e-cold"
+        Given a bucket quota set to <bucketQuota> B
+        And an account quota set to <accountQuota> B
+        And a <userType> type
+        And an environment setup for the API
+        And an "existing" IAM Policy that "applies" with "ALLOW" effect for the current API
+        When i restore object "" for 5 days
+        Then the API should "succeed" with ""
+        And object "obj-1" should expire in 5 days
+        When i wait for 5 days
+        Then object "obj-1" should be "cold" and have the storage class "e2e-cold"
+
+        Examples:
+            | action        | uploadSize | bucketQuota | accountQuota | userType |
+            | RestoreObject | 100        | 0           | 0            | ACCOUNT  |
+            | RestoreObject | 100        | 101         | 101          | ACCOUNT  |
+            | RestoreObject | 100        | 0           | 0            | IAM_USER |
+            | RestoreObject | 100        | 101         | 101          | IAM_USER |