Skip to content

Include grace period for SM add-on expiration

What does this MR do and why?

Part of https://gitlab.com/gitlab-org/gitlab/-/issues/425010+

When creating or updating a GitlabSubscription::AddOnPurchase for an SM instance its expiration date is set to the expiration date of the current license. While the license itself has a grace period, it is not applied to the add-on purchase. Similar logic for the same add-on on SaaS includes the expiration date of the add-on plus a grace period.

This change updates the creation and update to use a grace period on top of the expiration date. This is achieved by using the current license's block_changes_at attribute which is set to value we are looking for anyway.

How to set up and validate locally

note: You'll need Zuora, CustomersDot and GitLab/GDK for this verification:

  1. Zuora: Create a new self-managed subscription with TurnOnCloudLicensing set to Yes in Zuora.
  2. CustomersDot: Wait for the callout to process.
  3. CustomersDot: Copy the activation code (either from the email in letter opener or by querying for CloudActivation.last.activation_code) and activate your GitLab instance (you'll need this in a later step).
  4. Zuora: Start to create a new self-managed subscription with TurnOnCloudLicensing set to Yes in Zuora.
  5. Zuora: Add code suggestions as an additional product to the same subscription and enter a much smaller quantity than the subscription's seats. Note: There's only one code suggestions product with SaaS in its name due to the upcoming switch to a separate product for SM. The code changes are still pending for it until the new product was created so this product is the one that needs to be used here despite the SaaS part in its name.
  6. Zuora: Activate the subscription.
  7. CustomersDot: Wait for the callout to process.
  8. CustomersDot: Copy the activation code (either from the email in letter opener or by querying for CloudActivation.last.activation_code) and activate your GitLab instance.
  9. GitLab: Open a rails console and verify the last GitlabSubscriptions::AddOnPurchase record has an expiration date that matches the subscription's expiration date plus 14 days.
  10. Repeat steps 4-9 but use a different end date.
  11. GitLab: Remove the license under admin/subscription.
  12. Verify the last GitlabSubscriptions::AddOnPurchase was updated to have an expiration date that matches the subscription's expiration date plus 14 days.
  13. GitLab: Remove the next license too under admin/subscription.
  14. Verify the last GitlabSubscriptions::AddOnPurchase was updated to be expired as of yesterday.

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 Corinna Gogolok

Merge request reports

Loading