Add code-server package manifests

This commit is contained in:
2026-06-03 01:08:06 +00:00
parent cb6cf58229
commit d85dcb5c11
9 changed files with 301 additions and 59 deletions

107
README.md
View File

@ -1,10 +1,11 @@
# ocdp-workload-manifests
Standalone Kubernetes manifests for OCDP workloads.
Standalone Kubernetes manifests and post-render presets for OCDP workloads.
This repository is intentionally just a Git repository of app manifests. There is
no global catalog index and no dependency on the Gitea API. `ocdp-server` can
read a workload by building a Kustomize target directly from Git.
no global catalog index and no dependency on the Gitea API. `ocdp-server` stores
the template contract; the operator renders Helm sources and then applies
Kustomize presets from this repository.
## Architecture
@ -14,12 +15,15 @@ OCDP keeps the responsibilities split:
Git repo
apps/<app>/base
apps/<app>/components
packages/<app>/presets/<preset>
kustomization.yaml
userInputs.yaml
ocdp-server PostgreSQL
WorkloadTemplate metadata
WorkloadTemplate source.repositoryUrl/ref/path
WorkloadTemplate Helm source
WorkloadTemplate source.preset.repositoryUrl/ref/path
user-facing values schema / parameters
environment overlay and policy metadata
access bindings
no WorkloadClaim instance storage
@ -29,35 +33,50 @@ target cluster
runtime Kubernetes resources
```
This repository stores only the Git base and reusable components. It does not
store `WorkloadTemplate` records and does not store user `WorkloadClaim`
instances.
This repository stores Git bases, reusable components, and Kustomize presets.
For Helm-backed workloads, the operator runs `helm template` first, writes that
output as `rendered.yaml`, then renders the selected preset with Workload
`spec.values`. A preset may include `userInputs.yaml` so admins can see which
values should become the WorkloadTemplate user-facing parameter schema. This
metadata file is not a Kubernetes resource and is not referenced by Kustomize.
An admin creates or updates a `WorkloadTemplate` in `ocdp-server`. That template
can point at one of these Git paths:
can point at a Helm chart plus one of these Git presets:
```yaml
templateType: kustomize
source:
type: gitKustomize
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
ref: code-server-v0.1.0
path: apps/code-server/base
type: helm
repositoryUrl: https://kuoss.github.io/helm-charts
chart: code-server
version: 3.16.1
releaseName: "{{ name }}"
values: |
fullnameOverride: "{{ name }}"
serviceAccount:
create: false
persistence:
enabled: true
size: 20Gi
preset:
type: kustomize
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
ref: main
path: packages/code-server/presets/k3s-hami
```
After the template is stored in PostgreSQL and assigned to users or groups, users
call `ocdp-server` to create a claim by submitting `templateId`, `workspaceId`,
and values. `ocdp-server` resolves the template from PostgreSQL, reads the Git
base, generates any temporary source files or runtime specs outside this repo,
then writes a `WorkloadClaim` CR into the target Kubernetes cluster. The final
user-created claim lives in Kubernetes, not in PostgreSQL.
and values. `ocdp-server` resolves the template from PostgreSQL and writes a
`WorkloadClaim` CR into the target Kubernetes cluster. The operator renders Helm
with the resolved values, applies the Kustomize preset, and then applies the
final Kubernetes resources. The final user-created claim lives in Kubernetes,
not in PostgreSQL.
## Layout
```text
apps/
earth2studio-demo/
base/
code-server/
base/
components/
@ -67,32 +86,46 @@ apps/
litellm/
base/
components/
packages/
code-server/
presets/
k3s-hami/
kustomization.yaml
userInputs.yaml
tests/
kustomize/
```
## Server Usage
`ocdp-server` should store a normal `gitKustomize` reference:
`ocdp-server` should store a Helm source plus a Kustomize preset reference:
```yaml
source:
type: gitKustomize
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
ref: code-server-v0.1.0
path: apps/code-server/base
type: helm
repositoryUrl: https://kuoss.github.io/helm-charts
chart: code-server
version: 3.16.1
releaseName: "{{ name }}"
preset:
type: kustomize
repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
ref: main
path: packages/code-server/presets/k3s-hami
```
For one deployment, `ocdp-server` should generate temporary source files outside
this repository. Those files can point at the Git base and add generated
Secrets, ConfigMaps, components, and patches.
For one deployment, `ocdp-server` stores the Helm chart reference, static Helm
values, preset reference, and the template value contract. The preset renders
with Workload `spec.values`, so environment-specific implementation details
should live in the selected preset instead of in the WorkloadTemplate create
form.
## Exposure
Base services should stay internally reachable. User-facing exposure choices
belong on the WorkloadClaim top-level intent such as `exposure=internal` or
`exposure=external`; the agent/template renderer turns that intent into runtime
Service resources.
Base services should stay internally reachable unless an environment preset
intentionally changes the Service shape. For standard self-service workloads,
exposure is an admin preset decision and a user read view, not a user claim
input.
Reusable components are still useful implementation building blocks:
@ -101,8 +134,7 @@ Reusable components are still useful implementation building blocks:
- `components/service-loadbalancer`: change the app Service to `LoadBalancer`.
- `components/service-nodeport`: change the app Service to `NodePort`.
When `exposure=external` is selected by the user, the agent/template renderer
may generate a NodePort Service and leave the concrete nodePort for Kubernetes
When a preset needs NodePort, it may leave the concrete nodePort for Kubernetes
to allocate:
```yaml
@ -113,10 +145,13 @@ to allocate:
Do not hard-code shared NodePort values in app bases or reusable components.
Environment overlays are different from user choices. They are selected by the
Environment overlays are different from user values. They are selected by the
platform from cluster, workspace, or customer policy information and can carry
things like StorageClass, IngressClass, GPU runtime class, registry prefix,
pull-secret wiring, node selectors, tolerations, and site-specific labels.
things like Service type, StorageClass, IngressClass, GPU runtime class,
registry prefix, pull-secret wiring, node selectors, tolerations, and
site-specific labels. The user-facing exposure view is derived after reconcile:
ClusterIP is hidden from ordinary users, NodePort uses the agent access host and
observed nodePort, and LoadBalancer uses observed external IP/hostname and port.
## Validate