Merge branch 'w/2.8/improvement/ZENKO-4941' into tmp/octopus/w/2.9/im…

…provement/ZENKO-4941
scality · Dec 2, 2024 · b8dcd8f · b8dcd8f
2 parents ef1e1b9 + 584dbef
commit b8dcd8f
Show file tree

Hide file tree

Showing 2 changed files with 116 additions and 1 deletion.
diff --git a/solution/deps.yaml b/solution/deps.yaml
@@ -106,7 +106,7 @@ scuba:
   sourceRegistry: ghcr.io/scality
   dashboard: scuba/scuba-dashboards
   image: scuba
-  tag: 1.0.8
+  tag: 1.0.9
   envsubst: SCUBA_TAG
 sorbet:
   sourceRegistry: ghcr.io/scality

diff --git a/tests/ctst/features/quotas/Quotas.feature b/tests/ctst/features/quotas/Quotas.feature
@@ -97,6 +97,90 @@ Feature: Quota Management for APIs
             | 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 1000 B
+        And an account quota set to 1000 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
+        # Wait for inflights to be read by SCUBA
+        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"
+        # Wait for inflights to be read by SCUBA
+        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.6.0
+    @PreMerge
+    @Quotas
+    @CronJob
+    @DataDeletion
+    @NonVersioned
+    Scenario Outline: Negative inflights do not allow to bypass the quota
+        Given an action "DeleteObject"
+        And a permission to perform the "PutObject" action
+        And a STORAGE_MANAGER type
+        And a bucket quota set to 1000 B
+        And an account quota set to 1000 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
+        # Wait for inflights to be read by SCUBA
+        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"
+        # Wait for inflights to be read by SCUBA
+        And I wait 3 seconds
+        And I PUT an object with size 1000
+        Then the API should "fail" with "QuotaExceeded"
+
+        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.6.0
     @PreMerge
     @Quotas
@@ -129,3 +213,34 @@ Feature: Quota Management for APIs
             | RestoreObject | 100        | 0           | 99           | IAM_USER | fail    | QuotaExceeded | 3           |
             | RestoreObject | 100        | 99          | 99           | IAM_USER | fail    | QuotaExceeded | 3           |
             | RestoreObject | 100        | 101         | 101          | IAM_USER | succeed |               | 3           |
+
+    @2.6.0
+    @PreMerge
+    @Quotas
+    @Restore
+    @Dmf
+    @ColdStorage
+    @Only
+    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 be "restored" and have the storage class "e2e-cold"
+        Given a STORAGE_MANAGER type
+        Then 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  |