Review `Force reassociation` mechanizer function
Summary
Force reassociation is the second most used mechanizer function and supports for multiple use cases.
This function is unique in that it's mostly used when another process has failed to link a subscription to a namespace. Usually a Support Engineer (SE) will follow the proper process, but if their action errors out, they may use this function to get the subscription applied to the namespace so that the customer can receive the product they paid for.
Worth mentioning that errors in customers.gitlab.com can be vague and hard to troubleshoot. It is also sometimes too time-consuming to hunt down exactly why the system failed to perform the requested action and forcing an association is a faster way to force the action.
The goal of this issue is:
- to review the use cases that this function is supporting and getting to the root of why these use cases exist
- next steps: once we have a good understanding of the use cases, we will address each use case separately and form a plan to either reduce mechanizer usage for the use case, or migrate the mechanizer function to customersdot
Outside the scope of this issue, but iterating towards:
- solve for the use cases with reasonable product or process changes, that does not increase the existing burden of effort for any internal team
- deprecate this mechanizer function
Use cases
1. Provisioning for reseller subscriptions
2. Switching the namespace from trial to subscription
3. The subscription and namespace association breaks because of bugs
4.
Analysis of root problem for each use case
Ask the following questions for each use case:
- why does the use case exist?
- are there any workarounds?
- is the function addressing a bug or a missing feature?
1. Provisioning for reseller subscriptions
Why does the use case exist?
When a subscription is purchased via a reseller, the end-user does not have access to customers.gitlab.com to link their cdot account with their gitlab.com account and then link their subscription to their namespace. When there is no link between the subscription and the namespace, the provisioning of the subscription cannot complete.
The restriction on the access of customers.gitlab.com for reseller customers was a reaction to customers changing subscription details, which violates the terms in the contract with the reseller.
Are there any workarounds?
A SE with admin access to gitlab.com can avoid using the function if they follow this workflow whereby they impersonate the user on gitlab.com and on customers.gitlab.com in order to link the accounts and then proceed to link the subscription in customersdot with the namespace in gitlab.com.
If they don't have admin access to gitlab.com or they want to save time, they skip the linking of accounts and use this function to create a link between the subscription and the namespace.
Is the function addressing a bug or a missing feature?
The function is a workaround for the restricted access reseller customers have. If reseller customers' access were restored and they had tools to link their accounts and link their subscription to their namespace, but were restricted from changing their subscription order, it would eliminate the need for the function in this use case.
2. Switching the namespace from trial to subscription
Why does the use case exist?
When a namespace has been manually placed on a trial or the trial was extended with manual intervention, new subscription purchases cannot happen. In this way, manual work causes more manual work as the SE needs to clear the trial and apply the subscription to the namespace.
Are there any workarounds?
Is the function addressing a bug or a missing feature?
3. The subscription and namespace association breaks because of bugs
Why does the use case exist?
There are various bugs in the system that either prevents an association to happen or that unassociates subscriptions and namespaces. These bugs result in manual work for support where a force reassociation is necessary to get the namespace back on their subscription. When a namespace doesn't receive the entitlements of their subscription, this breaks customer trust.
Reference:
- Unable to link subscription due to additional m... (gitlab-com/support/toolbox/console-training-wheels#22 - closed)
- CustomersDot <> GitLab.com Access Token Short E... (customers-gitlab-com#4345 - closed)
Are there any workarounds?
Each bug is unique and their resolution should be addressed separately.