design-proposal(compute-plane): deliver as an operator-owned extra module wrapping apps/kubernetes (supersedes #27)#33
Conversation
…ing apps/kubernetes Revise the ComputePlane proposal: deliver it as an operator-owned Tenant module (extra/computeplane) that wraps the existing apps/kubernetes chart with fixed values, instead of user-facing preset fields on kind: Kubernetes. Keeps the "not a new kind" conclusion from the #17 review and #26; supersedes the preset-field revision (#27). The underlying isolation mechanism (remote Flux apply, per-VM boundary, single-tenant) is unchanged. Assisted-By: Claude Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 design proposal for Cozystack's ComputePlane. Instead of introducing a new top-level kind or user-facing preset fields on kind: Kubernetes, the proposal now delivers ComputePlane as an operator-controlled Tenant module (packages/extra/computeplane) that wraps the ordinary apps/kubernetes chart with operator-fixed values. The reviewer identified an architectural contradiction in the packaging design: the proposal describes ComputePlane as a new Tenant module, but the illustrative HelmRelease points directly to the re-sourced apps/kubernetes chart, which would bypass the packages/extra/computeplane chart entirely. Clarification on whether the module chart acts as a wrapper or if it is redundant is requested.
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.
| Reuse the `kubernetes` app as the substrate, unchanged. A ComputePlane is delivered as a new Tenant module, `packages/extra/computeplane`, of the same shape as `extra/etcd` / `extra/seaweedfs`. When a tenant has the module enabled, the tenant chart renders a `HelmRelease` (in the tenant namespace, on the management cluster) whose `chartRef` points at the **source-only** `apps/kubernetes` `ExternalArtifact`, carrying operator-fixed values: | ||
|
|
||
| ```yaml | ||
| # packages/extra/computeplane — rendered HelmRelease (illustrative) | ||
| apiVersion: helm.toolkit.fluxcd.io/v2 | ||
| kind: HelmRelease | ||
| metadata: | ||
| name: computeplane | ||
| namespace: tenant-<name> # management cluster, tenant namespace | ||
| spec: | ||
| chartRef: | ||
| kind: ExternalArtifact | ||
| name: cozystack-computeplane-application-kubevirt-kubernetes # apps/kubernetes, re-sourced (Design §2) | ||
| namespace: cozy-system | ||
| values: # operator-owned; the tenant cannot edit these | ||
| # hardened posture: restricted PSA + admission, deny egress → management kube-apiserver, | ||
| # scoped per-service egress only, addon set, GPU node groups, autoscaling bounds … | ||
| valuesFrom: | ||
| - kind: Secret # only the curated knobs the module chooses to surface | ||
| name: cozystack-values | ||
| ``` |
There was a problem hiding this comment.
There is an architectural contradiction in how the packages/extra/computeplane module is defined versus how it is deployed:
- The proposal states that "ComputePlane is delivered as a new Tenant module,
packages/extra/computeplane" (line 78). - However, the illustrative
HelmRelease(lines 81-98) has itschartRefpointing directly atcozystack-computeplane-application-kubevirt-kubernetes(which is the re-sourcedapps/kuberneteschart).
If the tenant chart's HelmRelease points directly to the re-sourced apps/kubernetes chart, the packages/extra/computeplane chart itself is bypassed and remains completely unused.
To resolve this, please clarify the packaging structure:
- Option A: The tenant chart renders a
HelmReleasepointing topackages/extra/computeplane, andpackages/extra/computeplaneacts as the wrapper that contains/renders theapps/kubernetesHelmReleaseor templates. - Option B: If the tenant chart directly releases
apps/kuberneteswith overridden values, then thepackages/extra/computeplanechart is redundant and only thecomputeplane-applicationPackageSource andcomputeplane-rdare needed.
…module A Tenant module is registered via an ApplicationDefinition, so ComputePlane does get its own apps.cozystack.io kind and API — the 'not a new top-level kind' claim carried over from #27 is inaccurate for this delivery. Reframe honestly: no new CRD, no new controller/reconcile path, and no fields on kind: Kubernetes; but a thin ComputePlane module-kind is registered like every other managed service. Assisted-By: Claude Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
1 participant
What
Revises the ComputePlane design proposal. ComputePlane is delivered as a Cozystack-owned Tenant module (
packages/extra/computeplane) that provisions a hardenedkind: Kubernetesby wrapping the existingapps/kuberneteschart with operator-fixed values — not user-facing preset fields (isolationProfile×componentProfile) onkind: Kubernetes.Because a Tenant module is registered via an
ApplicationDefinition, ComputePlane does get its ownapps.cozystack.iomodule-kind and API (likeSeaweedFS,Kubernetesand every managed service). The accurate framing is therefore: no new CRD, no new controller/reconcile path, and no new fields onkind: Kubernetes— theComputePlanekind is a thin operator-owned wrapper over the unchangedapps/kubernetes.Why this supersedes #27
#27 put the posture on
kind: Kubernetesas user-facing fields. This revision moves it into an operator-ownedextramodule:appsvsextra(docs(development): explain why packages live in apps vs extra website#594): a ComputePlane is a per-tenant enabler switched on under the hood, not a first-class cluster the tenant orders/configures — exactly anextramodule (likeextra/etcd→apps/kubernetes).kind: Kubernetesuntouched: no fields added to the cluster app; the user still gets the same cluster — they just don't administer it and can change only the curated knobs the module exposes.Mechanism
Reuses the existing PackageSource "source-only chart" pattern (how NATS/SeaweedFS already ship): a
computeplane-applicationPackageSource re-sourcesapps/kubernetesas a source-onlyExternalArtifact, plus acomputeplane-rdresource-definition and theextra/computeplanemodule chart. Apps route in via a newplacement: ManagementPlane | ComputePlanefield onApplicationDefinition, injectingkubeConfig.secretRef → computeplane-admin-kubeconfigfor one-way remote Flux apply (unchanged mechanism from the merged first revision).Relationship to prior proposals
Departs from #26's "no new kind at all" (that is the #27 field model, set aside here) but keeps the #26 / #17-review objection to a heavyweight distinct kind: the
ComputePlanemodule-kind does not duplicate the cluster reconcile/RBAC path — it wraps the unchangedapps/kubernetes. Supersedes #27 (preset fields — see "Alternatives considered" for the full trade-off). The underlying isolation mechanism (remote Flux apply, per-VM boundary, single-tenant, scoped egress, cozystack-api visibility control) is unchanged.Closes #26