# Allocation And Runtime Flows v1 Purpose: - Define the user-facing flow that connects compute allocation, storage, SSH access, and managed runtime bundles. - Prevent storage, restart, and runtime work from landing as disconnected features. - Provide a stable product flow reference for future UX and API slices. Inputs: - `doc/product/Allocation_Experience_Gaps_v1.md` - `doc/product/Allocation_Storage_Model_v1.md` - `doc/product/Allocation_Project_SSH_Access_v1.md` - `doc/product/Launchable_OCI_Workload_Images_v1.md` - `doc/product/Managed_Runtime_Bundles_v1.md` - `doc/product/Navigation_Redesign_App_Platform_v1.md` Related: - `doc/product/UX_Implementation_Spec.md` - `doc/api/openapi.draft.yaml` --- ## 1. Executive Summary The product should treat compute allocation as the foundation, then layer optional storage and managed runtime choices on top. The user should be able to: - get compute quickly - optionally attach durable storage - optionally choose a managed runtime bundle such as PyTorch - optionally launch a curated OCI workload or composition profile, such as JupyterLab or a model-serving stack - later restart the machine - later grant project-member SSH access - later change managed runtime state without giving up the allocation This flow keeps the product: - compute-first - fast - extensible without turning allocation creation into a huge complex wizard. --- ## 2. Primary Objects The user-facing model should be: ### 2.1 Allocation Represents: - one active compute environment - one machine binding - one primary SSH/terminal endpoint ### 2.2 Attached storage Represents: - durable project-scoped data attached into an allocation ### 2.3 Managed runtime bundle Represents: - an optional supported environment layered on top of the allocation - such as PyTorch or Jupyter ### 2.4 SSH access grants Represents: - who may SSH into the allocation - which public keys are effective ### 2.5 Launchable workload profile Represents: - a runnable app/workload on top of an allocation - usually OCI-backed - optionally a composed profile such as model workers plus gateway and observability add-ons These are distinct objects and should not be collapsed into one overloaded configuration blob. --- ## 3. Creation Flow ### 3.1 Minimum fast path The minimum allocation flow should remain: 1. choose compute 2. choose SSH key 3. allocate This preserves the product’s speed advantage. ### 3.2 Optional enrichments at create time Users may optionally add: - persistent storage attachments - initial managed runtime bundle These should be optional steps, not always-required complexity. ### 3.3 Create-time flow shape Recommended create flow: 1. Compute selection 2. Access setup 3. Optional persistent storage 4. Optional managed runtime 5. Review and create The order matters: - compute first because that is the primary purchase/intent - access next because users expect to know how they will get in - storage before runtime because runtime may depend on durable project data - runtime last because it is an overlay, not the base machine identity --- ## 4. Post-Create Flow Once the allocation is active, the user should be able to manage: - SSH access - attached storage - managed runtime bundle - launchable workload profiles - restart - metrics and health These belong on allocation detail, not spread across disconnected pages only. Recommended sections on allocation detail: - Overview - SSH Access - Storage - Managed Runtime - Workloads - Metrics / Health - Activity --- ## 5. Storage Flow ### 5.1 During create User may attach durable project storage immediately. ### 5.2 After create User may attach/detach durable project storage later. ### 5.3 User understanding The UI must make this boundary explicit: - local machine disk is scratch - attached project storage persists --- ## 6. Managed Runtime Flow ### 6.1 During create User may choose an initial managed runtime bundle. Examples: - none - PyTorch - Jupyter ### 6.2 After create User may: - apply a managed runtime later - upgrade a managed runtime - switch managed runtime bundles where supported ### 6.3 Ownership boundary Platform owns: - managed runtime paths - supported activation/update behavior User owns: - arbitrary SSH-installed customizations elsewhere --- ## 7. Restart Flow Restart should be a normal action on allocation detail. Flow: 1. user clicks restart 2. confirmation explains session/process interruption 3. allocation enters `restarting` 4. machine returns 5. allocation returns to `active` or `restart_failed` Restart should preserve: - attached storage intent - SSH access state - managed runtime association --- ## 8. Collaboration Flow Allocation detail should support project-member access grants. Flow: 1. owner or project admin opens `SSH Access` 2. selects project member 3. selects that member’s public key(s) 4. saves 5. runtime authorized keys reconcile The product message must remain: - the platform never shares private keys - each user authenticates with their own private key --- ## 9. Activity and Progress Every long-running operation should emit user-visible progress. This applies to: - allocation provisioning - restart - storage attach/detach - managed runtime install/upgrade - launchable workload start/stop/update - composed workload add-on enable/disable Minimum UX: - current step - recent activity - last update timestamp This should be shared UX infrastructure rather than reinvented per feature. --- ## 10. Recommended First-Slice UI Architecture ### 10.1 Allocation list Show: - status - current runtime summary - attached storage summary - quick actions ### 10.2 Allocation detail Primary control surface for: - SSH Access - Storage - Managed Runtime - Restart ### 10.3 Apps / Workloads Higher-level app bundles and workload UIs still matter, but raw compute users should not be forced through app surfaces just to manage a machine. Launchable workload profiles can bridge these surfaces: - allocation detail can offer “launch on this allocation” - apps/workloads can offer a catalog and detail view - the underlying profile remains the same product object --- ## 11. Things To Avoid - forcing every user through a heavyweight wizard when they only need raw compute - hiding storage semantics in separate docs instead of the UI - mixing team SSH access with personal default SSH key settings - treating managed runtime bundles as if they own all user-installed state - making restart an admin-only or hidden feature --- ## 12. Decision Summary The correct product flow is: - fast compute allocation first - optional storage and managed runtime enrichment at create time - rich post-create management on allocation detail That gives the platform a coherent compute-first UX while still allowing it to grow into a stronger managed runtime/app platform over time.