Exoscale OSB Offboarding and Suspension MVP

tobru commented

2025-10-30 10:17:23 +00:00

Owner

Stories

As the Exoscale Portal, I want to offboard or suspend a service instance.

Implementation Notes

To complete the Exoscale implementation API-wise, we implement an MVP for Offboarding and Suspension so that we can continue the testing and rollout without having to wait for the full feature sets in #235, #236 and #245 to be finished.

This means we need to handle the following OSB API requests:

DELETE v2/service_instances/:instance_id?service_id=service-test-guid&plan_id=plan1-test-guid
PATCH v2/service_instances/:instance_id

Both API requests must get accepted and validated, and as an action, have an Odoo helpdesk issue created with the information about the action (Suspend, Offboard) and the organization and service name.

This allows us to move forward a bit faster and buys us time to properly implement the flow.

## Stories _As the Exoscale Portal, I want to offboard or suspend a service instance._ ## Implementation Notes To complete the Exoscale implementation API-wise, we implement an MVP for [Offboarding](https://docs.servala.com/exoscale-osb.html#_offboarding) and [Suspension](https://docs.servala.com/exoscale-osb.html#_suspension) so that we can continue the testing and rollout without having to wait for the full feature sets in #235, #236 and #245 to be finished. This means we need to handle the following OSB API requests: * `DELETE v2/service_instances/:instance_id?service_id=service-test-guid&plan_id=plan1-test-guid` * `PATCH v2/service_instances/:instance_id` Both API requests must get accepted and validated, and as an action, have an Odoo helpdesk issue created with the information about the action (Suspend, Offboard) and the organization and service name. This allows us to move forward a bit faster and buys us time to properly implement the flow.

tobru added this to the Exoscale Integration milestone 2025-10-30 10:17:23 +00:00

tobru added the

enhancement

label 2025-10-30 10:17:23 +00:00

tobru added this to the Development Planning project 2025-10-30 10:17:24 +00:00

tobru added the

API

label 2025-10-30 10:19:44 +00:00

rixx commented

2025-11-12 10:35:09 +00:00

Member

My biggest question here relates to the service instance ID that is passed: Does that refer to an actual instance ID? Or to an instance name? Because we currently do not use/save the instance ID that exoscale passes on its provisioning request anywhere, so we have no mapping to know what to do with the DELETE/PATCH calls. (This also means that we cannot match the incoming Exoscale call to an Organization/Odoo helpdesk ID).

That aside, some less urgent questions: Should the following parts of the documentation be part of this issue or as a separate issue?

When all services are deleted (none exists anymore), an email is sent to customer@vshn.ch for the final closure of the organization.

Also, there is a monitoring check which triggers when no service is available, but service instances are still there and the deletion grace period is over. This means something failed in cleaning up.

Do we want to defined the suspension plan right away, or is that a thing for later implementation and we really just send the helpdesk issue for now?

My biggest question here relates to the service instance ID that is passed: Does that refer to an actual instance ID? Or to an instance name? Because we currently do not use/save the instance ID that exoscale passes on its provisioning request anywhere, so we have no mapping to know what to do with the DELETE/PATCH calls. (This also means that we cannot match the incoming Exoscale call to an Organization/Odoo helpdesk ID). That aside, some less urgent questions: Should the following parts of the documentation be part of this issue or as a separate issue? > When all services are deleted (none exists anymore), an email is sent to customer@vshn.ch for the final closure of the organization. > Also, there is a monitoring check which triggers when no service is available, but service instances are still there and the deletion grace period is over. This means something failed in cleaning up. Do we want to defined the suspension plan right away, or is that a thing for later implementation and we really just send the helpdesk issue for now?

rixx referenced this issue from a commit

2025-11-12 10:42:32 +00:00

Start work on implementing Exoscale offboarding

rixx referenced this issue

2025-11-12 10:42:46 +00:00

Exoscale offboarding MVP #282

tobru commented

2025-11-12 11:12:51 +00:00

Author

Owner

Let's do the simplest possible thing for this MVP: Get the information passed in the OSB API calls and create a helpdesk issue with all this information. This is the first step to have these endpoints available. Further processes will be implemented at a later stage. For now, we just need to make sure we have these endpoints available.

tobru commented

2025-11-13 15:14:53 +00:00

Author

Owner

My biggest question here relates to the service instance ID that is passed: Does that refer to an actual instance ID? Or to an instance name? Because we currently do not use/save the instance ID that exoscale passes on its provisioning request anywhere, so we have no mapping to know what to do with the DELETE/PATCH calls. (This also means that we cannot match the incoming Exoscale call to an Organization/Odoo helpdesk ID).

I thought about this again and again. For now, I'm pretty sure we can ignore the OSB instance ID because of how the Exoscale OSB API works. In https://docs.servala.com/exoscale-osb.html#_exoscale_organizations the screenshot shows the example of MongoDB; there is only an "Enable" button. This button triggers the already implemented onboarding flow, which in this case makes MongoDB available to this organization. The OSB API call includes an instance ID, but we have no use for it because the user creates the service instance directly in the Servala portal. When the user triggers the offboarding by pressing the "Disable" button, we will just revoke access to the MongoDB service offering and have no need to correlate a instance ID. In this issue, we don't care yet about revoking access or so; this will then be properly handled in #235.

With that, I think we can really safely ignore the OSB instance ID and just use it as an informational parameter.

> My biggest question here relates to the service instance ID that is passed: Does that refer to an actual instance ID? Or to an instance name? Because we currently do not use/save the instance ID that exoscale passes on its provisioning request anywhere, so we have no mapping to know what to do with the DELETE/PATCH calls. (This also means that we cannot match the incoming Exoscale call to an Organization/Odoo helpdesk ID). I thought about this again and again. For now, I'm pretty sure we can ignore the OSB instance ID because of how the Exoscale OSB API works. In https://docs.servala.com/exoscale-osb.html#_exoscale_organizations the screenshot shows the example of MongoDB; there is only an "Enable" button. This button triggers the already implemented onboarding flow, which in this case makes MongoDB available to this organization. The OSB API call includes an instance ID, but we have no use for it because the user creates the service instance directly in the Servala portal. When the user triggers the offboarding by pressing the "Disable" button, we will just revoke access to the MongoDB service offering and have no need to correlate a instance ID. In this issue, we don't care yet about revoking access or so; this will then be properly handled in #235. With that, I think we can really safely ignore the OSB instance ID and just use it as an informational parameter.

tobru referenced this issue from a commit

2025-11-17 08:45:07 +00:00

Start work on implementing Exoscale offboarding

tobru closed this issue

2025-11-17 10:49:32 +00:00

Rows
Columns

Exoscale OSB Offboarding and Suspension MVP #262

Stories

Implementation Notes