Skip to content

Update storage limit alert title

Sheldon Led requested to merge led/421668-amend-project-over-paid-limit-alert into master

What does this MR do and why?

This MR makes some adjustments to the Storage Limit Alert so we can solve some confusion that's described in https://gitlab.com/gitlab-org/gitlab/-/issues/421668

Before we jump to what's changed, it's important to understand the context. We have two types of limits:

To navigate the screenshots we need to understand the scenarios through the user journey:

  1. Scenario 1: A brand new group, with no storage overage
  2. Scenario 2: The group is approaching (>75%) their free tier limit (each limit type is applied differently, check steps to validate)
  3. Scenario 3: The group is over their free tier limit
  4. Scenario 4: The owner of the group buys storage, and has no overage
  5. Scenario 5: The group is approaching (>75%) their limit again, The owner might need to purchase more storage
  6. Scenario 6: The group is over their total (free+purchased) storage

In an attempt to simplify this MR description I'll refer to the scenarios number from now on.

What's changed

All the scenarios are described for completeness and understanding, as this is a complex feature 😅 but here's the summary of what's changed:

  1. Project Storage Limits alerts:

    1. Scenario 5: Changed the wording in the title from storage quota to purchased storage

      Screenshoot
      before after
      131932_project-limits_scenario5_before 131932_project-limits_scenario5_after

    2. Scenario 6: The title now has a different phrase and does not include the percentage

      Screenshoot
      before after
      131932_project-limits_scenario6_before 131932_project-limits_scenario6_after

Screenshots or screen recordings

Screenshots for a group in Project Storage Limits

Scenario 1: No Screenshots as there should be no alert

Scenario 2: We don't show an alert for this scenario in groups on Project Storage Limits

Scenario 3

No change here, it should be the same as in master branch (or in production).

131932_project-limits_scenario3

Scenario 4: No Screenshots as there should be no alert

Scenario 5

Changed the wording in the title from storage quota to purchased storage

before after
131932_project-limits_scenario5_before 131932_project-limits_scenario5_after
Scenario 6

The title now has a different phrase and does not include the percentage

before after
131932_project-limits_scenario6_before 131932_project-limits_scenario6_after

Screenshots for a group in Namespace Storage Limits

Scenario 1: No Screenshots as there should be no alert

Scenario 2

No change here, it should be the same as in master branch (or in production).

131932_namespace-limits_scenario2

Scenario 3

No change here, it should be the same as in master branch (or in production).

131932_namespace-limits_scenario3

Scenario 4: No Screenshots as there should be no alert

Scenario 5

No change here, it should be the same as in master branch (or in production).

131932_namespace-limits_scenario5_after

Scenario 6

131932_namespace-limits_scenario6_after

How to set up and validate locally

Since these apply to SaaS only, make sure you're simulating SaaS in your GDK.

Reproducing steps for a group in Project Storage Limits

Click to expand

To make it similar to the screenshots, I'll call this group project-limits-group

  1. Go to https://gdk.test:3443/groups/new and create a new group called project-limits-group. Make note of its id (e.g. 96)
  2. Create a project under this group. For this example I'll use 96-project1. Make note of its id (e.g. 26)
  3. From now on we can leave the browser in the Namespace Usage Quotas Page: https://gdk.test:3443/groups/project-limits-group/-/usage_quotas#storage-quota-tab
  4. You're now in Scenario 1
  5. Scenario 2 (the instructions below are in rails console)
    1. Enable the setting that tells your GitLab instance that it has the purchase storage feature
      1. Gitlab::CurrentSettings.update!(automatic_purchased_storage_allocation: true)
    2. Add a repository size limit:
      1. Gitlab::CurrentSettings.update!(repository_size_limit: 10.gigabytes)
    3. Add a storage usage to your project that goes over 75% of this limit:
      1. Project.find(26).statistics.update(repository_size: 9.gigabytes)
    4. Aggregate this storage to the namespace:
      1. Sidekiq.redis(&:flushdb)
      2. Namespaces::ScheduleAggregationWorker.perform_sync(96)
      3. Namespaces::RootStatisticsWorker.perform_sync(96)
      4. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    5. In the browser, make sure no banner appears
  6. Scenario 3 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 100% of this limit:
      1. Project.find(26).statistics.update(repository_size: 15.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 5.4.1 to 5.4.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.
  7. Scenario 4 (the instructions below are in rails console)
    1. Add purchased storage enough to go over the excess storage:
      1. Group.find(96).update(additional_purchased_storage_size: 10*1024)
    2. Make sure the banner disappeared
  8. Scenario 5 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 75% of the total limit (free+purchased):
      1. Project.find(26).statistics.update(repository_size: 18.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 5.4.1 to 5.4.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.
  9. Scenario 6 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 100% of the total limit (free+purchased):
      1. Project.find(26).statistics.update(repository_size: 25.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 5.4.1 to 5.4.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.

Reproducing steps for a group in Namespace Storage Limits

Click to expand

To make it similar to the screenshots, I'll call this group namespace-limits-group

  1. Go to https://gdk.test:3443/groups/new and create a new group called namespace-limits-group. Make note of its id (e.g. 97)
  2. Create a project under this group. For this example I'll use 97-project1. Make note of its id (e.g. 27)
  3. From now on we can leave the browser in the Namespace Usage Quotas Page: https://gdk.test:3443/groups/project-limits-group/-/usage_quotas#storage-quota-tab
  4. Enable Namespace limits for this group:
    1. Enable the setting that tells your GitLab instance that it has the purchase storage feature
      1. Gitlab::CurrentSettings.update!(automatic_purchased_storage_allocation: true)
    2. Enable the setting that tells your GitLab instance that it is enforcing namespace limits
      1. Gitlab::CurrentSettings.update!(enforce_namespace_storage_limit: true)
    3. Enable the namespace limits for this group (replace the command below by your group id)
      1. Feature.enable(:namespace_storage_limit, Group.find(97))
  5. You're now in Scenario 1
    1. Make sure (in the browser) that the cards in Usage Quotas are different from the cards in project-limits-group
  6. Scenario 2 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 75% of this limit:
      1. Project.find(27).statistics.update(repository_size: 4.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Sidekiq.redis(&:flushdb)
      2. Namespaces::ScheduleAggregationWorker.perform_sync(97)
      3. Namespaces::RootStatisticsWorker.perform_sync(97)
      4. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears
  7. Scenario 3 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 100% of this limit:
      1. Project.find(27).statistics.update(repository_size: 7.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 6.2.1 to 6.2.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.
  8. Scenario 4 (the instructions below are in rails console)
    1. Add purchased storage enough to go over the excess storage:
      1. Group.find(97).update(additional_purchased_storage_size: 10*1024)
    2. Leave rails console and execute the following in your terminal: rails cache:clear
    3. Make sure the banner disappeared
  9. Scenario 5 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 75% of the total limit (free+purchased):
      1. Project.find(27).statistics.update(repository_size: 12.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 6.2.1 to 6.2.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.
  10. Scenario 6 (the instructions below are in rails console)
    1. Add a storage usage to your project that goes over 100% of the total limit (free+purchased):
      1. Project.find(27).statistics.update(repository_size: 20.gigabytes)
    2. Aggregate this storage to the namespace:
      1. Repeat the steps 6.2.1 to 6.2.3
      2. If the Namespace storage used card (in the browser) has not been updated, repeat all the steps again.
    3. In the browser, make sure the correct banner appears.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Sheldon Led

Merge request reports