Skip to content

Handle permanently available deprovision parameters

Lukas Wanko requested to merge lw/498062-handle-permanently-existing-deprovision-parameters-for-bulk-provision-for-saas into master

What does this MR do and why?

While working on the issue https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/9874, we discovered that CDot is sending for non-purchased add-ons to permanently de-provision parameters. See also here.

With code change of this merge request, the bulk provision service for SaaS would now be able to handle permanently sent de-provision parameters and ensure that de-provision parameters are only de-provision the correct add-on purchase (Duo Pro can not longer de-provision a Duo Enterprise add-on purchase) and also the provision service returns now a success response, then it got de-provision parameters although no add-on purchase any longer exists.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Feature flag

  1. Add your own suffixed environment to this activated feature flag here
  2. Start your CDot with your own unleash app name, for example export UNLEASH_APP_NAME=lwanko

Patch

  1. Apply the following patch to CDot. This patch is only needed till https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/11005+ is live.

    diff --git a/app/services/gitlab/namespaces/update_plan_info_service.rb b/app/services/gitlab/namespaces/update_plan_info_service.rb
index 1fe5f9e18d..356eb2488e 100644
--- a/app/services/gitlab/namespaces/update_plan_info_service.rb
+++ b/app/services/gitlab/namespaces/update_plan_info_service.rb
@@ -280,14 +280,11 @@ def legacy_update_add_on_purchases(namespace_id, reset: false)
       end

       def add_on_purchases_data(reset:)
-        add_on_purchases_data = AddOns::ParamsGenerator::GitlabCom::AddOns.generate(
+        AddOns::ParamsGenerator::GitlabCom::AddOns.generate(
           order: order,
           reset: reset,
           namespace_changed: namespace_changed?
         )
-
-        # ATM Gitlab API endpoint only accept the legacy name `code_suggestions` for add_on_type `duo_pro`
-        add_on_purchases_data.transform_keys! { |key| key == :duo_pro ? :code_suggestions : key }
       end
 
       def add_on_purchase_service_class(deprovision:)

Verification

  1. Check the GitLab logs with gdk tail -f gitlab-workhorse | grep add_on_purchases

  2. Purchase an Ultimate subscription for a group with Duo Pro via GitLab and CDot or execute the following command with an order with Duo Pro on the Rails console (don't forget about setting the Unleash env variable): Gitlab::Namespaces::UpdatePlanInfoService.new(order, event_type: :sync, force_sync: true).execute

  3. Verify that the endpoint /api/v4/internal/gitlab_subscriptions/namespaces/1145/subscription_add_on_purchases got called, for example

    {"backend_id":"rails","content_type":"application/json","correlation_id":"01J9KNTYKER8KHZS5K0686WBVT","duration_ms":80,"host":"localhost:3333","level":"info","method":"POST","msg":"access","proto":"HTTP/1.1","referrer":"","remote_addr":"127.0.0.1:41378","remote_ip":"127.0.0.1","route":"^/api/","route_id":"api","status":201,"system":"http","time":"2024-10-07T16:23:52+02:00","ttfb_ms":79,"uri":"/api/v4/internal/gitlab_subscriptions/namespaces/1145/subscription_add_on_purchases","user_agent":"Ruby","written_bytes":188}

  4. Verify that the Duo Pro add-on was provisioned for the target group. For example, under http://localhost:3000/groups/duo-group/-/usage_quotas

Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/498062

Edited by Lukas Wanko

Merge request reports