[SM] Use term end date for all ramp enabled subscription licenses
Background
Historically, all ramp licenses were generated for term start date + 1 year. With Zuora Ramps, we are establishing automated provisioning of licenses for the entire ramp subscription period, so this shortened term is no longer necessary.
With the Zuora workflow being setup by EntApps, callouts will be sent from Zuora to CDot whenever a new ramp interval starts in order to provision additional seats at the start at each ramp interval.
Problem
As discussed in this thread #4295 (comment 1189876785), ramped subscriptions where cloud licensing is enabled have licenses generated for the full subscription term. For example, if a subscription has a 3 one year ramps, the full subscription term is 3 years, and therefore has a license generated for the full 3 years. If the quantity changes when a new ramp begins, a callout will be sent to CDot to generate a new license with the new quantity for the full term.
The logic for determining the license end date can be found here. Currently, this logic only applies to Subscriptions with cloud licensing enabled, but we need it for Subscriptions with legacy licenses too.
Proposal
Update the LicenseCreation#license_end_date
method to determine the license end date consistently for all ramp enabled subscriptions, using the term end date.
Proposal Summary
Generate the initial license for a ramp subscription for the entire 3 year subscription term (and then send a new license for only the additional users at the start of each year).
Reason for this proposal, rather than generating the initial license for 1 year and sending a new license for the full user amount at the start of each year:
- We are moving towards generating all licenses for the entire subscription term, not just ramps (example), as it requires less manual intervention. Option 2 is consistent with this motion.
- There is no risk of the customer losing access entirely if there is any provision failure at the start of years 2/3 - only not having access to the additional seats. Seems this could result in fewer support escalations.
- This was the plan with cloud license enabled subscriptions, so to me it makes sense to keep both types consistent.
Proposal Details
https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/4879 updated the existing license end date logic to generate ramp enabled licenses for the full subscription term for cloud enabled subscriptions only. We should remove this condition on cloud enabled by updating this line.
I think we want to update this:
# If Subscription is cloud and (reconciliations or ramps enabled), we issue it for the full term
To this:
# If Subscription is (cloud and reconciliations) or ramps enabled, we issue it for the full term
Side note, once #4816 (closed) is implemented, the logic will actually be:
# If Subscription is cloud or ramps enabled, we issue it for the full term
Result
All ramp licenses (whether cloud or not) are created for the full term.