Component
Cloud E2E coverage for Azure ML, OSMO, runtime dependency installation, and MLflow integration
Problem Statement
The cloud E2E suite leaves three production integration boundaries insufficiently validated:
- The Azure ML to OSMO proxy has a CPU smoke workflow and production submission script, but no automated E2E invokes the path. Dependency or Azure ML MLflow plugin incompatibility can leave the Azure ML job apparently successful because proxy MLflow failures are non-fatal.
- The OSMO RL tests execute
training/rl/scripts/setup_isaac_runtime.sh, but do not prove that the runtime loaded the versions exported from training/rl/uv.lock rather than compatible packages already present in the container image.
- The OSMO VLA fine-tuning test executes
training/vla/scripts/groot/osmo-train-entry.sh, but does not verify MLflow results, model registration, or pinned runtime and base-model provenance.
These gaps can allow dependency, plugin, or runtime-bootstrap regressions to pass task-level success checks.
Proposed Solution
Add one CPU-only AML-to-OSMO proxy E2E lane and strengthen the existing OSMO RL and VLA tests with runtime and integration assertions. Reuse existing production entrypoints and cloud jobs rather than adding duplicate GPU lanes.
Acceptance Criteria
AML-to-OSMO proxy
OSMO RL runtime
OSMO VLA runtime and MLflow
E2E lifecycle
Out of Scope
Component
Cloud E2E coverage for Azure ML, OSMO, runtime dependency installation, and MLflow integration
Problem Statement
The cloud E2E suite leaves three production integration boundaries insufficiently validated:
training/rl/scripts/setup_isaac_runtime.sh, but do not prove that the runtime loaded the versions exported fromtraining/rl/uv.lockrather than compatible packages already present in the container image.training/vla/scripts/groot/osmo-train-entry.sh, but does not verify MLflow results, model registration, or pinned runtime and base-model provenance.These gaps can allow dependency, plugin, or runtime-bootstrap regressions to pass task-level success checks.
Proposed Solution
Add one CPU-only AML-to-OSMO proxy E2E lane and strengthen the existing OSMO RL and VLA tests with runtime and integration assertions. Reuse existing production entrypoints and cloud jobs rather than adding duplicate GPU lanes.
Acceptance Criteria
AML-to-OSMO proxy
workflows/azureml/submit-osmo-proxy-job.sh,workflows/azureml/osmo-proxy-job.yaml, andworkflows/osmo/smoke-test-proxy-e2e.yaml.osmo.workflow_id, terminal status, task counts, success rate, and duration.OSMO RL runtime
setup_isaac_runtime.sh.training/rl/pyproject.tomland frozen lock resolution.OSMO VLA runtime and MLflow
test_e2e_osmo_vla_finetunerather than adding another GPU workflow.training/vla/scripts/groot/osmo-train-entry.sh.E2E lifecycle
Out of Scope