[Provision alignment] Replace current syncs with the new API endpoint

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.

Proposal

With the addition of the new sync request service to the new API endpoint for the single provisioning workflow, we could replace the current sync for namespace, subscription and add-ons to use this new endpoint (via a feature flag switch). The current params generation could be moved to a new service to combine the params for the new sync request service. This way we can start creating the sync records and see if everything is working piece by piece instead of replacing the whole workflow at once.

The provisioning for the compute minutes packs remains untouched for this since it's not support by the new endpoint. See [Provision alignment] Extend the SyncComputeMin... (gitlab#517504) for more information around this decision.

Result

Usage of the new provision sync API endpoint within the current provision workflow. Ensuring pieces of the new workflow will work as expected by placing them into the current workflow.

Assignee Loading
Time tracking Loading