Open Service Broker for Exoscale - Onboarding #37

New issue

Closed

opened 2025-04-07 14:48:04 +00:00 by tobru · 1 comment

tobru commented

2025-04-07 14:48:04 +00:00

Owner

Stories

As an Exoscale user, I want to enable service access from the Exoscale Portal.

Implementation Notes

All specs are here: https://docs.servala.com/exoscale-osb.html

Scope of this issue:

Implement OSB API endpoint for onboarding flow https://docs.servala.com/exoscale-osb.html#_onboarding
OSB API endpoint must be username/password protected - HTTP Basic Authentication. Configurable via environment variables
Creation of organization in Servala Portal should it not exist yet - set the origin to "exoscale-marketplace"
Send invitation via email to organization should it have been created. Afaik we don't have an invitation system yet, I think this will need to be implemented now.
Send service welcome email with direct link to service creation. Example: https://staging.portal.servala.com/org/acme-corp-vshn-6/services/redis/offering/4/

This is all for this phase. Other parts will be implemented in follow-up issues.

Links:

## Stories _As an Exoscale user, I want to enable service access from the Exoscale Portal._ ## Implementation Notes All specs are here: https://docs.servala.com/exoscale-osb.html Scope of this issue: - Implement OSB API endpoint for onboarding flow https://docs.servala.com/exoscale-osb.html#_onboarding - OSB API endpoint must be username/password protected - HTTP Basic Authentication. Configurable via environment variables - Creation of organization in Servala Portal should it not exist yet - set the origin to "exoscale-marketplace" - Send invitation via email to organization should it have been created. Afaik we don't have an invitation system yet, I think this will need to be implemented now. - Send service welcome email with direct link to service creation. Example: https://staging.portal.servala.com/org/acme-corp-vshn-6/services/redis/offering/4/ This is all for this phase. Other parts will be implemented in follow-up issues. Links: - https://gist.github.com/exogmi/9a91aacfb3906301eb610a41e19ac7a2 - https://pypi.org/project/openbrokerapi/ - https://github.com/eruvanos/openbrokerapi - https://community.exoscale.com/vendor/marketplace-managed-svc-prov/ - https://servala.app.codey.ch/servala/website/src/branch/main/hub/broker

tobru added the

enhancement

label 2025-04-07 14:48:04 +00:00

tobru added this to the Exoscale Integration milestone 2025-04-07 14:48:24 +00:00

tobru added this to the Development Planning project 2025-07-04 08:36:10 +00:00

tobru changed title from ~~Open Service Broker for Exoscale~~ to Open Service Broker for Exoscale - Onboarding

2025-09-12 07:42:30 +00:00

tobru commented

2025-09-26 06:29:07 +00:00

Author

Owner

Die Onboarding-Doku nennt als Endpunkt http://exo-osbapi.vshn.net/v2/service_instances/:instance_id – die OSB-Doku sagt ":instance_id MUST be a globally unique non-empty string. This ID will be used for future requests (bind and deprovision), so the Service Broker will use it to correlate the resource it creates.". Bislang haben unsere Das ist mir an unserem Datenmodell nicht ganz klar – wir legen ja in diesem Schritt noch gar keine Instanz an, sondern nur (optional) die Organisation + eine Einladung. Wo speichern wir das? Erstellen wir da schon eine Instanz, aber in einem (neuen?) pending state, oder speichern wir das an der Einladung, o.ä.? Die OSB-API sagt ja, dass man gegen diese Instanz-ID prüfen soll, ob das ein duplicate request ist und ggf. mit 409 Conflict zurückweisen soll …

For this stage of implementation we can ignore the instance_id. We will make use of it when we implement #38 - which still needs refinement.

Die OSB-Doku sagt auch, dass wenn kein Parameter "accepts_incomplete=true" im PUT ist, wir mit 422 Unprocessable Entity rejecten müssen, soll ich das so umsetzen / wird das so korrekt gesendet werden?

I think we can ignore that for now - the Exoscale integration is not so sophisticated.

Wie sehr validieren wir die Input-Daten? Also z.B. soll die Exoscale-UUID ja viermal geschickt werden (zweimal verpflichtend) – gucken wir da auf mismatch, falls die nicht übereinstimmen?

We should validate them, because there could be bugs on the Exoscale side.

Wenn eine Liste von Usern mitgeschickt wird, aber nicht alle davon valide sind, schicken wir einen Fehler zurück oder nicht? (Oder ist es eh immer nur ein User?)

As far as I understand we only get one user because we intend to not enable user sync. The doc on Exoscale says "When user sync is disabled, only the information of the user that made the product purchase will be provided. The information will never be updated."

In dem PUT sind ja direkt Service-ID und Plan-ID drin, die wir wiederum in die Invite-ID packen. Laut OSB-Spec können aber noch weitere Daten dabei sein – parameters enthält laut https://docs.servala.com/exoscale-osb.html#_onboarding nur die User, aber die OSB-Spec sagt, dass dort und in maintenance_info auch weitere Daten zur Instanzerstellung sein können. Müssen wir da noch zusätzliche Daten speichern?

No, Exoscale will only send the bare minimum. All the parametrization happens on the Servala Portal. Actually we will never directly instantiate something via OSB, it's solely used to enable and configure access to the portal and enabling access to a service offering (see #38).

Jetzt mappe ich erst mal "owner" zu "owner" und "tech" zu "member", in Sachen Zugriffsrechten, das passt so?

I think we can directly map the one user which is sent to "owner". Because we have user sync disabled, we won't get any other users.

Wenn die Organisation schon existiert, prüfen wir dann, dass sie Exoscale-managed ist? Exoscale kann ja über die API z.B. frei Owner von Organisationen ändern …

This OSB integration only ever managed organizations where origin=exoscale. With that it should not be possible to touch any organization which isn't originating from Exoscale.

Die Exoscale-GUID wird einfach ein neues Feld an der Organisation? Muss die für sonst etwas (namespace oder so) berücksichtigt werden?

Exactly, we store this in the organization. I'd call this field osb_guid because this isn't an Exoscale specific field.

BTW: I fixed the links to the Exoscale documentation site in https://docs.servala.com/exoscale-osb.html because they were 404ing. The Exoscale documentation could be helpful to understand a few things about how they're done on their side.

> Die Onboarding-Doku nennt als Endpunkt `http://exo-osbapi.vshn.net/v2/service_instances/:instance_id` – die OSB-Doku sagt ":instance_id MUST be a globally unique non-empty string. This ID will be used for future requests (bind and deprovision), so the Service Broker will use it to correlate the resource it creates.". Bislang haben unsere Das ist mir an unserem Datenmodell nicht ganz klar – wir legen ja in diesem Schritt noch gar keine Instanz an, sondern nur (optional) die Organisation + eine Einladung. Wo speichern wir das? Erstellen wir da schon eine Instanz, aber in einem (neuen?) pending state, oder speichern wir das an der Einladung, o.ä.? Die OSB-API sagt ja, dass man gegen diese Instanz-ID prüfen soll, ob das ein duplicate request ist und ggf. mit `409 Conflict` zurückweisen soll … For this stage of implementation we can ignore the `instance_id`. We will make use of it when we implement #38 - which still needs refinement. > Die OSB-Doku sagt auch, dass wenn kein Parameter "accepts_incomplete=true" im PUT ist, wir mit `422 Unprocessable Entity` rejecten müssen, soll ich das so umsetzen / wird das so korrekt gesendet werden? I think we can ignore that for now - the Exoscale integration is not so sophisticated. > Wie sehr validieren wir die Input-Daten? Also z.B. soll die Exoscale-UUID ja viermal geschickt werden (zweimal verpflichtend) – gucken wir da auf mismatch, falls die nicht übereinstimmen? We should validate them, because there could be bugs on the Exoscale side. > Wenn eine Liste von Usern mitgeschickt wird, aber nicht alle davon valide sind, schicken wir einen Fehler zurück oder nicht? (Oder ist es eh immer nur ein User?) As far as I understand we only get one user because we intend to not enable user sync. The doc on Exoscale says "When user sync is disabled, only the information of the user that made the product purchase will be provided. The information will never be updated." > In dem PUT sind ja direkt Service-ID und Plan-ID drin, die wir wiederum in die Invite-ID packen. Laut OSB-Spec können aber noch weitere Daten dabei sein – `parameters` enthält laut [https://docs.servala.com/exoscale-osb.html#_onboarding](https://docs.servala.com/exoscale-osb.html#_onboarding "https://docs.servala.com/exoscale-osb.html#_onboarding") nur die User, aber die OSB-Spec sagt, dass dort und in `maintenance_info` auch weitere Daten zur Instanzerstellung sein können. Müssen wir da noch zusätzliche Daten speichern? No, Exoscale will only send the bare minimum. All the parametrization happens on the Servala Portal. Actually we will never directly instantiate something via OSB, it's solely used to enable and configure access to the portal and enabling access to a service offering (see #38). > Jetzt mappe ich erst mal "owner" zu "owner" und "tech" zu "member", in Sachen Zugriffsrechten, das passt so? I think we can directly map the one user which is sent to "owner". Because we have user sync disabled, we won't get any other users. > Wenn die Organisation schon existiert, prüfen wir dann, dass sie Exoscale-managed ist? Exoscale kann ja über die API z.B. frei Owner von Organisationen ändern … This OSB integration only ever managed organizations where `origin=exoscale`. With that it should not be possible to touch any organization which isn't originating from Exoscale. > Die Exoscale-GUID wird einfach ein neues Feld an der Organisation? Muss die für sonst etwas (namespace oder so) berücksichtigt werden? Exactly, we store this in the organization. I'd call this field `osb_guid` because this isn't an Exoscale specific field. BTW: I fixed the links to the Exoscale documentation site in https://docs.servala.com/exoscale-osb.html because they were 404ing. The Exoscale documentation could be helpful to understand a few things about how they're done on their side.

tobru referenced this issue

2025-09-26 08:15:32 +00:00

Filtering of Services and Control-Planes with Organization Origins #38