Quest: Analysis Sandboxing

← All Specs
This is the spec for the Analysis Sandboxing quest View Quest page →

Quest: Analysis Sandboxing

Layer: Forge Priority: P90 Status: active Tasks: 5 total (0 done, 5 open)

Vision

Run all analyses in isolated environments (containers, cgroups, or sandboxed subprocesses) so a runaway analysis cannot corrupt the database, filesystem, or other running services. Each analysis gets its own temp directory, restricted filesystem access, and resource budget. Design for future migration to external container runtimes (Docker, AWS Batch, K8s) while running locally today.

The immediate requirement is not heavyweight orchestration. It is reliable,
named execution environments that SciDEX analyses actually use today, with
auditable runtime selection, tempdir isolation, and explicit DB/provenance
paths, so single-cell/genomics/data-ML workflows stop conflicting with one
another on the shared host.

Tasks

☐ [Forge] Implement cgroup-based process isolation for analysis execution (P5)
☐ [Forge] Create per-analysis temp directories with restricted filesystem access (P4)
☐ [Forge] Design pluggable executor interface for future container/cloud migration (P4)
☐ [Forge] Add analysis environment health checks and corruption detection (P3)
☐ [Forge] Implement conda environment activation for analysis tool execution (P3)
☐ [Forge] Standardize runtime catalog and per-analysis execution logging (P4)
☐ [Forge] Add resumable runtime-backed analysis entrypoints for real-data pipelines (P4)

Success Criteria

☐ All tasks completed and verified
☐ Integration tested end-to-end
☐ Metrics visible on Senate/Quests dashboards
☐ Design supports future scaling to external compute
☐ A representative analysis can be launched in a named Forge runtime and
leaves behind execution logs, isolated temp state, and reproducible outputs

Quality Requirements

> All new analyses must run in named Forge runtimes with visible execution logs. Stub runtimes (named but non-functional) are prohibited. Executor interface must be non-mock — real isolation, real resource limits, auditable temp cleanup.

Architecture Notes

This quest is designed with a local-first, cloud-ready philosophy:

  • All implementations must work on the current single VM
  • All interfaces must support future migration to containers/cloud
  • Resource limits are configurable, not hardcoded
  • Executor/sandbox abstractions allow swapping implementations

Work Log

_No entries yet._

File: quest_analysis_sandboxing_spec.md
Modified: 2026-04-24 07:15
Size: 2.8 KB