Dynamic Service Ordering Form #14

New issue

Closed

opened 2025-03-18 17:12:29 +00:00 by tobru · 1 comment

tobru commented

2025-03-18 17:12:29 +00:00

Owner

Stories

As a user, I want to see the service configuration form so that I can configure the service parameters for ordering

This story only concerns the dynamic creation of the service configuration form, not the actual creation of the service (this will be in another story).

Implementation Notes

The actual service implementation is defined in a new model called "Service Definition", it contains the information which CompositeResourceDefinition (aka XRD) implements the service on a control plane, and to query the OpenAPI spec for
Infos:
- A service definition can later contain further configuration about the service implementation, for example addition field configurations
- Service definitions can be reused between multiple service offerings
The OpenAPI v3 Specification of a XRD is available under https://kubernetesapi/apis/apiextensions.k8s.io/v1/customresourcedefinitions/$name, e.g. http://kubernetesapi/apis/apiextensions.k8s.io/v1/customresourcedefinitions/xvshnredis.vshn.appcat.vshn.io
The Service Offering contains a link to a Service Definition, which is then used to show the service form.
See also rough PoC in https://servala-2nkgm.app.codey.ch/servala/kubernetes-ui-poc

## Stories _As a user, I want to see the service configuration form so that I can configure the service parameters for ordering_ This story only concerns the dynamic creation of the service configuration form, not the actual creation of the service (this will be in another story). ## Implementation Notes - The actual service implementation is defined in a new model called "Service Definition", it contains the information which `CompositeResourceDefinition` (aka `XRD`) implements the service on a control plane, and to query the OpenAPI spec for - Infos: - A service definition can later contain further configuration about the service implementation, for example addition field configurations - Service definitions can be reused between multiple service offerings - The OpenAPI v3 Specification of a XRD is available under `https://kubernetesapi/apis/apiextensions.k8s.io/v1/customresourcedefinitions/$name`, e.g. `http://kubernetesapi/apis/apiextensions.k8s.io/v1/customresourcedefinitions/xvshnredis.vshn.appcat.vshn.io` - The Service Offering contains a link to a Service Definition, which is then used to show the service form. - See also rough PoC in https://servala-2nkgm.app.codey.ch/servala/kubernetes-ui-poc

tobru added this to the Servala Portal MVP milestone 2025-03-18 17:12:29 +00:00

tobru added the

enhancement

label 2025-03-18 17:12:29 +00:00

tobru added this to the Development Planning project 2025-03-18 17:12:29 +00:00

tobru referenced this issue

2025-03-24 13:24:32 +00:00

Service Instantiation #24

tobru commented

2025-03-26 07:57:24 +00:00

Author

Owner

In the service definition, we currently have the GVK of the resource we want to create. To now get the OpenAPI spec for it, there are multiple ways:

Use the Discovery API. This can also be shown with kubectl --kubeconfig tmp/kubeconfig-dev-servala-portal api-resources --api-group=vshn.appcat.vshn.io --output=wide. Adding -v=9 shows the http requests and responses to learn what the command actually does.
Get the API spec directly: /openapi/v3/apis/$group/$version, e.g. /openapi/v3/apis/vshn.appcat.vshn.io/v1. Go through the discovery endpoint /openapi/v3 and get the spec URL from .paths."apis/vshn.appcat.vshn.io/v1" This spec contains all resources from the group, so the specific kind will have to be extracted accordingly.
Add another field to "Service Definition" to store the information where to get the spec

In the implementation notes is written "The OpenAPI v3 Specification of a XRD is available under https://kubernetesapi/apis/... - This is not fully accurate, direct access to the OpenAPI v3 specification is under /openapi/v3. See https://kubernetes.io/docs/concepts/overview/kubernetes-api/#openapi-v3. Under /apis/... we do get the Kubernetes resource. In CustomResourceDefinition we do get access to the OpenAPI spec under .spec.versions[0].schema.openAPIV3Schema.

In the service definition, we currently have the GVK of the resource we want to create. To now get the OpenAPI spec for it, there are multiple ways: 1. Use the [Discovery API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#discovery-api). This can also be shown with `kubectl --kubeconfig tmp/kubeconfig-dev-servala-portal api-resources --api-group=vshn.appcat.vshn.io --output=wide`. Adding `-v=9` shows the http requests and responses to learn what the command actually does. 2. Get the API spec directly: `/openapi/v3/apis/$group/$version`, e.g. `/openapi/v3/apis/vshn.appcat.vshn.io/v1`. Go through the discovery endpoint `/openapi/v3` and get the spec URL from `.paths."apis/vshn.appcat.vshn.io/v1"` This spec contains all resources from the group, so the specific kind will have to be extracted accordingly. 3. Add another field to "Service Definition" to store the information where to get the spec In the implementation notes is written "The OpenAPI v3 Specification of a XRD is available under `https://kubernetesapi/apis/...` - This is not fully accurate, direct access to the OpenAPI v3 specification is under `/openapi/v3`. See https://kubernetes.io/docs/concepts/overview/kubernetes-api/#openapi-v3. Under `/apis/...` we do get the Kubernetes resource. In `CustomResourceDefinition` we do get access to the OpenAPI spec under `.spec.versions[0].schema.openAPIV3Schema`.