Example App Workflow designed
The reference workflow shows how an app team can build independently while GPUaaS owns the platform substrate. Slurm is the first proving example, not a special-case contract.
Operator Workflow
- Open the app catalog.
- Find an entitled app.
- Deploy the app.
- Fill app-specific deploy fields.
- Observe lifecycle progress in the platform shell.
- Use runtime-specific day-2 controls from the instance page.
App Controller Workflow
- Run independently from GPUaaS core.
- Authenticate with a project-scoped service account.
- Read app instances, members, operations, and allocations through public APIs.
- Acquire machine access through a supported platform path.
- Install or configure runtime software.
- Report progress and status through public APIs.
- Reconcile until desired runtime state is reached.
UI Split
The platform UI owns catalog, entitlements, app instance inventory, generic lifecycle, and common picker primitives. The app UI owns app-specific deploy fields, runtime panels, topology controls, and debugging actions.
Reference App Proof
Each example app should carry the same proof shape so reviewers can compare Jupyter, vLLM, Headlamp, OpenClaw, Slurm, and future apps consistently.
| Proof point | Expected source |
|---|---|
| Manifest validity | SDK manifest validator or contract smoke evidence |
| Launch | public app instance API request and idempotency evidence |
| Connect | active connect action or managed-route readiness evidence |
| Decommission | app decommission request and cleanup evidence |
| Runtime-specific behavior | app-owned controller logs, health, and status updates |
| Platform behavior | audit, evidence/status, billing attribution, and artifact trust refs |
If an example needs direct seed edits, backend-only assumptions, or manual DB inspection to explain basic behavior, the portal should mark that as an App SDK readiness gap.
Canonical sources