Front end M7, part 2: remote service over SSH, with Slurm

Aperta
  • Qualcosa non va?
#480 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@jtravs ci sta già lavorando.

Dal 7/11/2026.

  • #571 di @jtravs — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
linux, python
Ambito
backend, hpc

Direzione di ricerca

Start by reading the local service in gui/src/solprop_gui/service/server.py, since the remote design reuses its socket, token and re-attach behaviour. The issue says the design is not yet settled, so the first step is a design discussion with the maintainers, not code. Done means an agreed design for the SSH tunnel, the --ensure handshake and the Slurm job model, split into smaller issues.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: gui enhancement priority: low

Part 1 of M7 is built: a local solprop service (gui/src/solprop_gui/service/server.py), runs that outlive the window, re-attach, and a private socket guarded by a token. Part 2 is running the service on a remote Linux machine, and submitting runs to Slurm on HPC systems. It is deferred until the design is settled. The notes below are a starting point.

Clients and transport

  • Clients: Windows, macOS and Linux. Server: Linux.
  • Use the system OpenSSH client (Windows 10+, macOS, Linux), so the user's keys, agent, ~/.ssh/config and jump hosts apply.
  • The GUI starts or finds the remote service with ssh host <python> -m solprop_gui.service.server --ensure, which prints its address and token once. The token stays in the client's memory.
  • Tunnel: a local loopback TCP port forwarded to the remote Unix socket (ssh -L 127.0.0.1:<port>:<socket> host). This works on all three clients; the server keeps its private socket.
  • Handshake: the protocol and solprop versions must match, or the connection is refused with a clear message.
  • A dropped tunnel leaves runs going. Reconnecting re-attaches and replays rows, as locally.

Installing on a machine without solprop

  • If the remote has no solprop, or another version, offer (with explicit confirmation) to install the client's exact version into a user-owned environment: bootstrap uv if needed, then uv venv and uv pip install solprop[gui]==<version>.
  • Handle a machine with no internet (upload wheels over SSH), a chosen install path (home quotas), and the Linux native wheels.
  • The service needs no Qt. A Qt-free service-only install (an extra, or a split package) would keep servers light.

Files live on the server

  • The workspace and its runs become a service request, not a local folder listing.
  • A small remote file browser for "Open results…".
  • Figure export returns bytes for the client to save.
  • Data files a recipe reads are uploaded into the run folder.

Slurm (essential for HPC)

  • The service on a login node does light work only: checks, previews, browsing. It may run inside an interactive allocation where a site requires that.
  • Each run is a job from a user-editable template (partition, time, CPUs/GPUs, modules); a scan is a job array.
  • Live rows: compute nodes often cannot reach a login-node socket. So the job appends its reduced rows to a small file beside its results on the shared filesystem, and the service follows that file.
  • State from squeue/sacct; stop through the run's stop-flag file (scancel as the hard stop); resume is a new submission.
  • Runs must not depend on the service, since sites may kill long-lived login-node processes: a job finishes alone, and a later connection picks up its files.
  • To check: whether solprop's scan executors can submit single runs, or need extending.

Tests

  • Service in a thread, with the tunnel faked over loopback.
  • SSH to localhost.
  • A Slurm test against a containerised Slurm in CI, or by hand.

🤖 Generated with Claude Code

Lingua principale
Python
Stelle
3
Fork
3
Merge medio
8h 37m
PR unite (30g)
159

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LupoLab/solprop

Tutte le issue di LupoLab/solprop

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.