[Provision alignment] Extend the SyncComputeMinutesService to provision additional minutes packs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

Problem

The current provisionings for GitLab.com and SM/Dedicated follow markedly distinct approaches. While SM/Dedicated relies on licenses (license key or file) to contain all needed info, GitLab.com relies on multiple syncs for a namespace.

To align the provision between the deployment types, the GitLab.com provisioning will be aligned to be similar to the SM/Dedicated. The current multiple syncs to GitLab.com will be replaced by a single sync for a namespace which includes all needed information at once. Each sync will be stored in the database on the CustomersDot side for easier auditing. These records will follow a similar behavior as the license generation for SM/Dedicated and only create a new entry for a sync if the data/info for the new sync has changed compared to the last sync. Timestamps for each sync will still be stored for a better insight into the sync frequency.

On the GitLab side as much logic as possible will be reused to provision the received info. A future iteration could focus on simplifying the GitLab.com side's provisioning. The provisioning will happen directly when receiving the request due to the async part being on the CDot side.

Proposal

We created a new SyncComputeMnutesService on previous issue: [Provision alignment] Create a new service to d... (#507288 - closed). During the implementation we wanted to make sure that we don't carry on provisioning additional packs which haven't been used for long time. Comment thread: #350617 (comment 2330596328)

If we decide to carry on with minutes packs, and if the minutes packs needs to be provisioned now, we should provision the additional packs.

Result

Additional Packs gets provisioned along with compute minutes.

Edited Sep 29, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading