Redesign Kubernetes vs. compute/memory/storage app placement (#75) - #81
Open
DLondonoD wants to merge 7 commits into
Open
Redesign Kubernetes vs. compute/memory/storage app placement (#75)#81DLondonoD wants to merge 7 commits into
DLondonoD wants to merge 7 commits into
Conversation
Brings in the resolution of PR camaraproject#79's conflicts (issue camaraproject#72's fix merged into fix/issue-73): repo-wide 500/503 removal and local Generic400/403/404 response objects for all operations, including the four deployment action endpoints introduced by camaraproject#74 (add/removeEdgeCloudZone, add/removeKubernetesCluster), which previously still had 500/503 and did not yet benefit from camaraproject#72's fix since they were added on fix/issue-74 independently of fix/issue-73's main-merge. Resolved 9 conflicts in edge-application-management.yaml: - 7 identical 500/503-removal conflicts across various operations: kept fix/issue-73's side (500/503 removed). - deleteAppDeployment's trailing 500/503 vs the start of the new add-edge-cloud-zone path: removed the 500/503, kept the new path. - The large conflict spanning the four new deployment action endpoints vs the old patch-based updateAppDeployment operation: kept HEAD's four endpoints (the old PATCH operation is superseded by camaraproject#74's redesign), stripping their own 500/503 blocks for consistency with camaraproject#72's fix. The two .feature files that merged cleanly (getAppDeployments, getApps) carry over camaraproject#72's removal of phantom 404 scenarios on collection-list operations.
…oject#75) Per issue camaraproject#75, applications requiring Kubernetes resources (requiredResources.infraKind: kubernetes) must specify Kubernetes cluster(s) rather than Edge Cloud Zone(s) directly - the zone is implied by the cluster. Previously edgeCloudZoneId/edgeCloudZones was always mandatory and kubernetesClusterRef(s) merely optional, with no enforcement preventing both or neither from being specified, and no documented behavior for the conflict. - createAppInstance/createAppDeployment request bodies now use a oneOf of two new schemas each (AppInstanceZoneRequest / AppInstanceClusterRequest, AppDeploymentZoneRequest / AppDeploymentClusterRequest), making the zone-based and cluster-based placement mutually exclusive at the schema level. Specifying both, neither, or the wrong one for the app's infraKind results in 400 INVALID_ARGUMENT. - Documented this behavior in both operations' description and in a new 'Kubernetes vs. compute/memory/storage applications' section of the API description. - The addEdgeCloudZone/removeEdgeCloudZone and addKubernetesCluster/removeKubernetesCluster operations (camaraproject#74) are now documented as mutually exclusive per deployment: using the pair that doesn't match the deployment's infraKind returns 409 INCOMPATIBLE_STATE. - Updated createAppInstance.feature/createAppDeployment.feature: the old success scenario mixing both zone and cluster params (now invalid) was replaced with a Kubernetes-only success scenario, plus 4 new error scenarios covering both-specified/neither-specified/ wrong-type-for-infraKind. - Added 409 INCOMPATIBLE_STATE scenarios to addEdgeCloudZone.feature/removeEdgeCloudZone.feature.
…r.feature Completes the mutual-exclusivity error coverage for the four deployment action endpoints (camaraproject#74) added for camaraproject#75: removeKubernetesCluster was the only one of the four still missing its 409 scenario for being called on a deployment of the wrong infraKind.
Brings in the resolution of PR camaraproject#80's conflicts (fix/issue-74 merged with upstream/main, which already carries camaraproject#72/camaraproject#73's fixes repo-wide). Kept fix/issue-75's 409 INCOMPATIBLE_STATE examples on the four deployment action endpoints, since fix/issue-74's freshly-merged version had them without the 500/503 blocks removed for camaraproject#72 consistency - identical to what was already resolved for camaraproject#79/camaraproject#80.
Following camaraproject#73's redesign, ClusterInfo no longer carries edgeCloudZoneId (removed as redundant when nested under EdgeCloudZone.clusters), but this left no way to discover which Edge Cloud Zone contains a given Kubernetes cluster when the API consumer only has a bare kubernetesClusterRef - e.g. one returned earlier by createAppInstance/createAppDeployment's AppInstanceClusterRequest/ AppDeploymentClusterRequest path introduced for camaraproject#75. Added a clusterRef query parameter to getEdgeCloudZones: when specified, only the Edge Cloud Zone containing that cluster is returned (with the cluster included in its clusters property). This avoids reintroducing the edgeCloudZoneId redundancy in ClusterInfo while still making a cluster's zone discoverable via the standard list-with-filters pattern, consistent with the other query params (countryCode, edgeCloudProvider, edgeCloudRegion, status). Updated getEdgeCloudZones.feature with a new filtered-by-clusterRef scenario and renumbered the subsequent scenario tags.
ClusterInfo is only ever returned nested inside EdgeCloudZone.clusters[], so its edgeCloudProvider always duplicates the enclosing zone's value. A cluster cannot belong to a different provider than its containing zone, so the field is dropped and the schema description clarified.
DLondonoD
requested review from
FabrizioMoggio,
JoseMConde,
Kevsy,
gainsley,
maheshc01 and
seralogar
as code owners
September 3, 2026 08:34
PR camaraproject#80 (issue camaraproject#74) merged to main with an additional commit applying @seralogar's review suggestion to simplify removeEdgeCloudZone's 404 response to $ref: Generic404, which conflicted with fix/issue-75's addition of the 409 INCOMPATIBLE_STATE response right after it. Resolved by keeping main's Generic404 simplification alongside fix/issue-75's 409 block. Also applied the same simplification to removeKubernetesCluster's 404, which had the same custom-message pattern but wasn't touched by the original suggestion, for consistency with the rest of the spec (addEdgeCloudZone/addKubernetesCluster already used Generic404).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
correction
What this PR does / why we need it:
Applications requiring Kubernetes resources (
requiredResources.infraKind: kubernetes) must beplaced via one or more Kubernetes clusters rather than Edge Cloud Zone(s) directly — the zone is
implied by the cluster. Previously
edgeCloudZoneId/edgeCloudZoneswas always mandatory andkubernetesClusterRef(s)merely optional, with no enforcement preventing both or neither frombeing specified, and no documented behavior for the conflict.
createAppInstance/createAppDeploymentrequest bodies now use aoneOfof two newschemas each (
AppInstanceZoneRequest/AppInstanceClusterRequest,AppDeploymentZoneRequest/AppDeploymentClusterRequest), making zone-based and cluster-based placement mutually exclusiveat the schema level. Specifying both, neither, or the wrong one for the app's
infraKindresultsin
400 INVALID_ARGUMENT.compute/memory/storage applications" section of the API description.
addEdgeCloudZone/removeEdgeCloudZoneandaddKubernetesCluster/removeKubernetesClusteraction endpoints (Allowing PATCHing of deployments obscures functionality required by API design #74) are now documented asmutually exclusive per deployment: using the pair that doesn't match the deployment's
infraKindreturns
409 INCOMPATIBLE_STATE. All four endpoints now carry this scenario.clusterRefquery parameter togetEdgeCloudZones: when specified, only the EdgeCloud Zone containing that cluster is returned. This lets an API consumer discover which zone
contains a given
kubernetesClusterRef(e.g. one returned by the newAppInstanceClusterRequest/AppDeploymentClusterRequestpath) without reintroducing anedgeCloudZoneIdback ontoClusterInfo.edgeCloudProviderfromClusterInfo: it is only ever returned nested insideEdgeCloudZone.clusters[], so the value always duplicated the enclosing zone'sedgeCloudProvider— a cluster cannot belong to a different provider than its containing zone.Test definitions updated/added accordingly:
createAppInstance.feature/createAppDeployment.feature: replaced the now-invalid mixedzone+cluster success scenario with a Kubernetes-only success scenario, plus new error scenarios
for both-specified / neither-specified / wrong-type-for-
infraKind.addEdgeCloudZone.feature/removeEdgeCloudZone.feature/addKubernetesCluster.feature/removeKubernetesCluster.feature: added409 INCOMPATIBLE_STATEscenario.getEdgeCloudZones.feature: added filtered-by-clusterRefscenario, renumbered subsequentscenario tags.
Which issue(s) this PR fixes:
Fixes #75
Special notes for reviewers:
Depends on #74 (the four add/remove action endpoints this PR extends with
409 INCOMPATIBLE_STATE) — please merge/review that one first if still pending.Changelog input
release-note Redesigned Kubernetes vs. compute/memory/storage application placement:
createAppInstance/createAppDeployment now require a mutually-exclusive Edge-Cloud-Zone-based or
Kubernetes-cluster-based request; the four cluster/zone action endpoints return 409
INCOMPATIBLE_STATE on infraKind mismatch; getEdgeCloudZones gained a clusterRef filter; removed
redundant edgeCloudProvider from ClusterInfo.
Additional documentation
docs