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.

Architecture

OCDP keeps the responsibilities split:

Git repo
  apps/<app>/base
  apps/<app>/components

ocdp-server PostgreSQL
  WorkloadTemplate metadata
  WorkloadTemplate source.repositoryUrl/ref/path
  user-facing values schema / parameters
  environment overlay/profile metadata
  access bindings
  no WorkloadClaim instance storage

target cluster
  WorkloadClaim CR as the canonical user claim
  Workload CR
  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.

An admin creates or updates a WorkloadTemplate in ocdp-server. That template can point at one of these Git paths:

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

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.

Layout

apps/
  code-server/
    base/
    components/
  vllm-server/
    base/
    components/
  litellm/
    base/
    components/
tests/
  kustomize/

Server Usage

ocdp-server should store a normal gitKustomize reference:

source:
  type: gitKustomize
  repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
  ref: code-server-v0.1.0
  path: apps/code-server/base

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.

Exposure

Base services are ClusterIP. User-facing exposure choices such as clusterip, nodeport, and loadbalancer belong in the WorkloadTemplate values schema. ocdp-server can translate that value into runtime Service configuration or a generated patch.

Reusable components are still useful implementation building blocks:

components/ingress: keep the app Service internal and route through an ingress controller.
components/service-loadbalancer: change the app Service to LoadBalancer.
components/service-nodeport: change the app Service to NodePort.

When nodeport is selected by the user, ocdp-server may generate an instance patch or runtime Service field for an explicit port:

- op: add
  path: /spec/ports/0/nodePort
  value: 30080

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 platform from cluster, workspace, or customer profile information and can carry things like StorageClass, IngressClass, GPU runtime class, registry prefix, pull-secret wiring, node selectors, tolerations, and site-specific labels.

Validate

make validate

make validate runs kubectl kustomize against non-user test overlays under tests/kustomize.