Problem description
Support for applications that require Kubernetes clusters feels like a "bolt on", and requires at least better documentation, and possibly an API re-design.
Applications can be defined through the requiredResources property to require either Kubernetes resources, or compute / memory / storage resources (VM, container or Docker).
When instantiating a single application or application deployment, property edgeCloudZoneId or edgeCloudZones is mandatory, but kubernetesClusterRef or kubernetesClusterRefs is optional. But kubernetesClusterRef or kubernetesClusterRefs should be mandatory for applications that require Kubernetes resources, and edgeCloudZoneId or edgeCloudZones become redundant in that case, and should not be required to be specified.
The GET /clusters endpoint also feels like a "bolt on" for Kubernetes applications when this information could be returned by GET /edge-cloud-zones.
The API documentation does not at all describe this different handling of Kubernetes applications compared to compute / memory / storage applications, nor explain how conflicts or missing information are handled.
Expected action
Consider re-designing the API so that either edge cloud zone(s) or Kubernetes cluster(s) can be specified by the API consumer, but not both (e.g. using the oneOf construct).
Document what happens when the API consumer does not specify the deployment resources properly. What error is returned or how does the API implementation behave?
For example:
- Kubernetes clusters are specified for a compute / memory / storage application
- Kubernetes clusters are not specified for a Kubernetes application
- There is a conflict between the specified edge cloud zone(s) and Kubernetes cluster(s) for a Kubernetes application - i.e. the edge cloud zone(s) associated with the Kubernetes clusters do not coincide with the specified edge cloud zone(s)
Additional context
None
Problem description
Support for applications that require Kubernetes clusters feels like a "bolt on", and requires at least better documentation, and possibly an API re-design.
Applications can be defined through the
requiredResourcesproperty to require either Kubernetes resources, or compute / memory / storage resources (VM, container or Docker).When instantiating a single application or application deployment, property
edgeCloudZoneIdoredgeCloudZonesis mandatory, butkubernetesClusterReforkubernetesClusterRefsis optional. ButkubernetesClusterReforkubernetesClusterRefsshould be mandatory for applications that require Kubernetes resources, andedgeCloudZoneIdoredgeCloudZonesbecome redundant in that case, and should not be required to be specified.The GET /clusters endpoint also feels like a "bolt on" for Kubernetes applications when this information could be returned by GET /edge-cloud-zones.
The API documentation does not at all describe this different handling of Kubernetes applications compared to compute / memory / storage applications, nor explain how conflicts or missing information are handled.
Expected action
Consider re-designing the API so that either edge cloud zone(s) or Kubernetes cluster(s) can be specified by the API consumer, but not both (e.g. using the oneOf construct).
Document what happens when the API consumer does not specify the deployment resources properly. What error is returned or how does the API implementation behave?
For example:
Additional context
None