Service Instantiation #24

New issue

Closed

opened 2025-03-24 10:18:59 +00:00 by tobru · 2 comments

tobru commented

2025-03-24 10:18:59 +00:00

Owner

Stories

As a user, I want to order a service instance via a service offering.

The form implemented in #14 allows filling in parameters for a service instance. When the parameters are filled in, the service can be instantiated.

Implementation Notes

Should there be more than one control-plane available for the service offering (e.g. a cloud provider with multiple control-planes), ask the user on which one the instance should be created. We call the control-plane in the frontend "Service Provider Zone".
A service instance is always instantiated in an organizations' namespace. Therefore, first check if there is a matching organization namespace already available on the target control-plane. If not, create one first. Create the Kubernetes resource of the service instance in this namespace.
The name of the Namespace on the target control-plane must be unique; therefore we should use something unique from the Portal database, e.g. the slug? It cannot be changed afterward on the control-plane. (No object on Kubernetes can be renamed!)
Ask for the name of the instance and use that one to create the resource.
The source of truth of services is the control-plane. We still have to track the instances in the portal, but only the bare minimum. The Kubernetes API might mutate incoming requests, so we should only track metadata. The service spec itself must always be queried from the Kubernetes API. (See below)
When creating a Kubernetes object, the Kubernetes API validates it. Any error returned by the Kubernetes API must be visible to the user in the portal (as-is, no translation required for now).

Tracking instances in the database

When an instance is created, we track the following information in the database:

Organization (immutable)
Name (immutable)
Display Name
ServiceOffering (immutable)
ControlPlane (immutable)
Created by which user (immutable)
Date and Time created (immutable)
Date and Time updated

All other information is retrieved from the service instance on the control-plane.

To be figured out

Namespace labels, see https://docs.appuio.cloud/user/how-to/manage-projects-and-namespaces.html#_creating_namespaces

## Stories _As a user, I want to order a service instance via a service offering_. The form implemented in #14 allows filling in parameters for a service instance. When the parameters are filled in, the service can be instantiated. See also [Servala Portal Docs](https://docs.servala.com/service-instances.html). ## Implementation Notes - Should there be more than one control-plane available for the service offering (e.g. a cloud provider with multiple control-planes), ask the user on which one the instance should be created. We call the control-plane in the frontend "Service Provider Zone". - A service instance is always instantiated in an organizations' namespace. Therefore, first check if there is a matching organization namespace already available on the target control-plane. If not, create one first. Create the Kubernetes resource of the service instance in this namespace. - The name of the Namespace on the target control-plane must be unique; therefore we should use something unique from the Portal database, e.g. the slug? It cannot be changed afterward on the control-plane. (No object on Kubernetes can be renamed!) - Ask for the name of the instance and use that one to create the resource. - The source of truth of services is the control-plane. We still have to track the instances in the portal, but only the bare minimum. The Kubernetes API might mutate incoming requests, so we should only track metadata. The service spec itself must always be queried from the Kubernetes API. (See below) - When creating a Kubernetes object, the Kubernetes API validates it. Any error returned by the Kubernetes API must be visible to the user in the portal (as-is, no translation required for now). ### Tracking instances in the database When an instance is created, we track the following information in the database: - Organization (immutable) - Name (immutable) - Display Name - ServiceOffering (immutable) - ControlPlane (immutable) - Created by which user (immutable) - Date and Time created (immutable) - Date and Time updated All other information is retrieved from the service instance on the control-plane. ### To be figured out - Namespace labels, see https://docs.appuio.cloud/user/how-to/manage-projects-and-namespaces.html#_creating_namespaces

tobru added this to the Servala Portal MVP milestone 2025-03-24 10:18:59 +00:00

tobru added the

enhancement

label 2025-03-24 10:18:59 +00:00

tobru added this to the Servala Portal project 2025-03-24 10:18:59 +00:00

rixx referenced this issue

2025-03-26 15:27:29 +00:00

Service instantiation #31

tobru commented

2025-03-27 07:56:43 +00:00

Author

Owner

Kubernetes name restrictions: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

I propose we restrict the resource name to "RFC 1035 Label Names":

contain at most 63 characters
contain only lowercase alphanumeric characters or '-'
start with an alphabetic character
end with an alphanumeric character

And enforce the uniqueness rules directly in the Django app, before it hits the Kubernetes API (the Kubernetes API enforces it as well):

Names must be unique across all API versions of the same resource. API resources are distinguished by their API group, resource type, namespace (for namespaced resources), and name. In other words, API version is irrelevant in this context.

Kubernetes name restrictions: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/ I propose we restrict the resource name to "RFC 1035 Label Names": * contain at most 63 characters * contain only lowercase alphanumeric characters or '-' * start with an alphabetic character * end with an alphanumeric character And enforce the uniqueness rules directly in the Django app, before it hits the Kubernetes API (the Kubernetes API enforces it as well): > Names must be unique across all API versions of the same resource. API resources are distinguished by their API group, resource type, namespace (for namespaced resources), and name. In other words, API version is irrelevant in this context.

tobru commented

2025-03-28 13:29:48 +00:00

Author

Owner

We need to set the label appcat.vshn.io/provider-config in every instance we create. The value of that label needs to be hardcoded for every control-plane, so this means we need a new field in the control-plane config. Minimum example:

apiVersion: vshn.appcat.vshn.io/v1
kind: VSHNRedis
metadata:
  name: redis-app3-prod
  namespace: acmecorp
  labels:
    appcat.vshn.io/provider-config: kind
spec: {}

We need to set the label `appcat.vshn.io/provider-config` in every instance we create. The value of that label needs to be hardcoded for every control-plane, so this means we need a new field in the control-plane config. Minimum example: ``` apiVersion: vshn.appcat.vshn.io/v1 kind: VSHNRedis metadata: name: redis-app3-prod namespace: acmecorp labels: appcat.vshn.io/provider-config: kind spec: {} ```

rixx closed this issue

2025-04-04 10:57:43 +00:00