Proposal: `--backend gflow` — a single-node Slurm-like scheduler for shared workstations

[AndPuQing]

I maintain gflow — a lightweight job scheduler for a single shared GPU workstation or lab server: queue, priorities, dependencies, arrays, time limits, GPU allocation with waiting reasons, per-user/per-project quotas, fair-share, reservations. It exposes an HTTP API (/jobs, /stats, /reservations, /quotas), a stdio MCP server (gflow mcp serve, 17 tools incl. preview_submit_jobs and triage_job), and Slurm-flavored CLIs (gbatch / gqueue / gjob / gcancel / gctl).

The overlap I'd like to propose:

1. --backend gflow for local experiments — Orx keeps the experiment tree, the immutable source snapshot and orx supervise; gflow owns admission, queueing and GPU allocation on the workstation. Submitting a run as a real queued job (with a waiting reason) instead of a detached process would make orx runs show why something isn't running yet.
2. A companion skill pack so the agent can ask "is the GPU free / why is my run pending / what did the last three failures look like" without a new backend.
3. gflow mcp serve already speaks MCP.

Issue #303 from @pswpswpsw is the demand signal I'd point at: workstations today, clusters tomorrow — the middle case (one big shared box, several researchers, no cluster admin) is where gflow lives.

I should have a draft PR up within a week. Before I start: is this something you'd want in the repo, and is there anything you'd rather see done differently?

@sox8502 @myles332

[sox8502]

@AndPuQing Thanks for opening this.

Based on conversations that we've had with users & usage statistics, people seem to be content with Slurm or whatever bespoke compute setup they have locally.

Let's keep this issue open. If more people express interest in an native gflow integration in OpenResearch, we can discuss what the exact shape of the integration should look like.