Problem description
There are a number of issues with the design of the GET /edge-cloud-zones and GET /clusters endpoints:
Expected behavior
-
Fix:
-
Consider:
- combining GET /clusters with GET /edge-cloud-zones into a single listing endpoint
- including pagination support to avoid the endpoint returning large amounts of data
- adopting geographical region identifiers for region filtering that are independent of the edge cloud provider terminology - for example, ISO 3166-1 alpha-2 country codes ("GB", "DE", "US", etc.)
- allowing filtering by edge cloud provider
- removing the default value of
unknown for status filtering
Alternative solution
None proposed
Additional context
None
Problem description
There are a number of issues with the design of the GET /edge-cloud-zones and GET /clusters endpoints:
Common Issues
regionrequires use of edge cloud provider specific region names, meaning the results will be specific to a given edge cloud providerGET /edge-cloud-zones issues
unknownforstatusfiltering prevents returning a list of edge cloud zones independent of status, thus requiring 3 separate queries to retrieve the full listGET /clusters
provideris defined as the Application Provider (i.e. API consumer), but Kubernetes clusters are not Application Provider specific. This is surely meant to be the edge cloud provider, which is otherwise not a response parameter.Expected behavior
Fix:
providershould beedgeCloudProvider, not Application ProviderConsider:
unknownforstatusfilteringAlternative solution
None proposed
Additional context
None