design-proposal(compute-plane): deliver as kind: Kubernetes presets, not a new kind (per #26 / #17 review)#27
Conversation
…not a new kind Adopt the surface proposed in #26 and the #17 review (converge): ComputePlane becomes a configuration of kind: Kubernetes via two orthogonal presets (isolationProfile x componentProfile), placement generalized to a named cluster, plus a cozystack-api visibility/mutation control as the sandbox enforcement substrate. Mechanism (remote Flux apply, per-VM boundary, single-tenant) unchanged. Refs #26, #17. Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
📝 WalkthroughWalkthroughThe ComputePlane Design Revision
🎯 2 (Simple) | ⏱️ ~10 minutes Possibly Related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the ComputePlane design proposal, shifting the implementation from a new top-level CRD to composable presets (isolationProfile and componentProfile) on the existing kind: Kubernetes. It also generalizes application placement to target named clusters and introduces tenant-side visibility and mutation controls in cozystack-api. Feedback on the proposal points out a minor grammatical error in the rollout phase description where 'placement' is incorrectly used as a verb.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| 2. **Phase 2 — first consumer (`cozyllm`).** Set `placement: ComputePlane` on the code-executing apps (JupyterHub, n8n, ComfyUI, Langflow, code-exec features of Open WebUI); keep vLLM/LiteLLM at the default `placement: ManagementPlane` (inference-only, no code execution). See the cozyllm-specific technical design. | ||
| 3. **Phase 3 — extensions (deferred).** Tenant-facing scoped read/observability view of the ComputePlane; additional consumers (WordPress / application-platform); billing/metering hooks; secret delivery of managed-service connection strings into ComputePlane workloads. | ||
| 1. **Phase 1 — core primitive.** `placement` (named cluster) + `isolationProfile`/`componentProfile` presets on `kind: Kubernetes` (`sandbox` posture: managedDataplane + hardening + scoped per-service egress) + the per-kind visibility/mutation control. | ||
| 2. **Phase 2 — first consumer (`cozyllm`).** `placement` the code-executing apps (JupyterHub, n8n, ComfyUI, Langflow, code-exec Open WebUI) onto a `sandbox` cluster; keep vLLM/LiteLLM on `ManagementPlane`. |
There was a problem hiding this comment.
In the Phase 2 rollout description, the word placement is used as a verb in an ungrammatical way: "placement the code-executing apps...". It should be changed to "Place the code-executing apps" or "Route the code-executing apps" to maintain grammatical correctness and professional style.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
design-proposals/compute-plane/README.md (1)
216-222: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueClarify finalizer ownership for cluster deletion ordering.
Line 222 states "a finalizer on the cluster blocks teardown until they're cleaned up" but doesn't specify which controller sets this finalizer. Consider clarifying whether the
kubernetesapp controller, the cluster lifecycle controller, or Flux itself enforces this ordering, as this affects operational runbooks.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@design-proposals/compute-plane/README.md` around lines 216 - 222, Clarify who owns the cluster-deletion finalizer in the failure-and-edge-cases section so the teardown ordering is unambiguous. Update the wording around the Tenant deletion bullet to explicitly name the controller responsible for adding and removing the finalizer (for example, the cluster lifecycle controller or the kubernetes app controller) and how it blocks deprovisioning until remote HelmRelease cleanup completes. Keep the reference aligned with the existing Tenant deletion / HelmRelease deletion flow described in this section.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@design-proposals/compute-plane/README.md`:
- Around line 216-222: Clarify who owns the cluster-deletion finalizer in the
failure-and-edge-cases section so the teardown ordering is unambiguous. Update
the wording around the Tenant deletion bullet to explicitly name the controller
responsible for adding and removing the finalizer (for example, the cluster
lifecycle controller or the kubernetes app controller) and how it blocks
deprovisioning until remote HelmRelease cleanup completes. Keep the reference
aligned with the existing Tenant deletion / HelmRelease deletion flow described
in this section.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5aab362a-9428-4f00-8ae6-4bf1894fc369
📒 Files selected for processing (1)
design-proposals/compute-plane/README.md
1 participant
Revises the merged ComputePlane design (
design-proposals/compute-plane) to adopt the surface proposed in #26 (myasnikovdaniil) and the #17 review (Timofei Larkin), which converge.kind: Kubernetes— two orthogonal presets:isolationProfile(standard|sandbox|cluster-meshed) ×componentProfile(minimal|standard-addons|gpu| bundles). A "ComputePlane" is justkind: Kubernetes+isolationProfile: sandbox. Avoids a parallel CRD / reconcile / RBAC surface and the combinatorial explosion of kinds.placement→ named cluster.ApplicationDefinition.placement=ManagementPlane|<cluster name>, routing a catalog app onto any of the tenant's named clusters (the generic target the design-proposal: compute plane for untrusted-code workloads #17 review asked for) — not hard-coded to "ComputePlane". Allows N sandbox clusters per tenant (drops the single-string module's cap).sandbox=managedDataplane(withheld kubeconfig) + hardening + scoped per-service egress;cluster-meshed= the PR design-proposal: cross-cluster mesh for tenant access to host services #7 mesh for trusted clusters. Encodes the broad-mesh-for-trusted vs narrow-egress-for-untrusted distinction as named presets.cozystack-api— the enforcement substrate forsandbox(hide the cluster/app from a tenant's regular users; withhold admin), and a standalone intra-tenant privilege-separation feature. v1 is per-kind (plain RBAC); per-instance/label filtering is deferred.The mechanism settled in the merged first revision (remote Flux apply via
kubeConfig.secretRef, per-VM kernel boundary, single-tenant, connectivity §6) is unchanged — this is a surface revision. The distinct-kind framing and the single-stringcomputePlane:module are moved to Alternatives (rejected).Closes #26. Refs #17.
Summary by CodeRabbit