Problem
POST /api/v1/app-deployments requires a region_id ("a cluster there with capacity is chosen"), but there's no customer-facing way to discover which regions can actually host a given app. The customer App (ApiApp) exposes no region/cluster info, and there's no GET for app clusters/regions on the public API. App clusters are admin-configured per region, so the client can't assume the VM regions apply.
Impact
The web app is building the deploy form (compose config: → inputs + a region picker). Everything else is in place, but the region picker has no valid source — we'd have to guess, which risks a 400 ("no cluster in the region has enough capacity") or offering regions with no app cluster at all.
Proposal
Expose the deployable regions per app, e.g. either:
- add
regions: { id, name }[] (regions with an app cluster that has free capacity) to the customer App response, or
- a new
GET /api/v1/apps/{id}/regions returning the admissible regions (optionally with a capacity/availability hint).
Region name + id is enough to render the picker; a capacity/availability flag would let us disable full regions up-front instead of failing at order time.
Follows the same "surface the id the client needs" pattern as #210 (host CPU arch) and #216 (subscription company_id).
Problem
POST /api/v1/app-deploymentsrequires aregion_id("a cluster there with capacity is chosen"), but there's no customer-facing way to discover which regions can actually host a given app. The customerApp(ApiApp) exposes no region/cluster info, and there's noGETfor app clusters/regions on the public API. App clusters are admin-configured per region, so the client can't assume the VM regions apply.Impact
The web app is building the deploy form (compose
config:→ inputs + a region picker). Everything else is in place, but the region picker has no valid source — we'd have to guess, which risks a400("no cluster in the region has enough capacity") or offering regions with no app cluster at all.Proposal
Expose the deployable regions per app, e.g. either:
regions: { id, name }[](regions with an app cluster that has free capacity) to the customerAppresponse, orGET /api/v1/apps/{id}/regionsreturning the admissible regions (optionally with a capacity/availability hint).Region name + id is enough to render the picker; a capacity/availability flag would let us disable full regions up-front instead of failing at order time.
Follows the same "surface the id the client needs" pattern as #210 (host CPU arch) and #216 (subscription company_id).