Customer was opted into cloud licensing because of a bug and their instance activated cloud licensing, an entity change happened and the new subscription was not on cloud licensing
l = License.find 123
and then l.destroy
. You need to provide the license number for the first command. You can find this number in the URL of the cloud license in the customersdot license menu (example: https://customers.gitlab.com/admin/license/123123123)l = License.find 123
and then l.destroy
. You need to provide the license number for the first command. You can find this number in the URL of the cloud license in the customersdot license menu (example: https://customers.gitlab.com/admin/license/123123123)Zuora Subscriptions
tab in customersdot (URL example: https://customers.gitlab.com/admin/customer/123123/zuora_subscriptions)Cloud Licensing
checkbox. Click the Update
button.Cloud Activations
tab. Ensure that the code was generated for the correct subscription.Cloud Licensing
checkbox from step 2 should now be checked.Cloud Activations
tab.As part of embracing the GitLab value of iteration, we plan on monitoring the impact that Strict Cloud Licensing will have on the GitLab customer base. With this in mind, moving forward we request that L&R support engineers add the applicable tags listed below to every Zendesk ticket whenever a customer contacts support requesting an offline/legacy license file.
Tag | Reason |
---|---|
cloud-could-selfserve | Customer has access to Customer Portal and could have self-served, for example customers who have an EoA, multi-year or a ramp-up subscription |
cloud-could-not-selfserve | Customer does not have access to the Customer Portal and therefore support had to provide a legacy/offline license file |
cloud-pre-14.1 | Customer requires legacy/offline license because they are not able to upgrade to 14.1+ |
cloud-airgapped | Customer needs legacy/offline license because they must keep their instance offline |