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

Cerrado
  • ¿Algo no está bien?
#480 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@jtravs ya está trabajando en esto.

Desde el 7/11/2026.

  • #571 de @jtravs — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
linux, python
Área
backend, hpc

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
3
Forks
3
Merge medio
8 h 36 min
PR fusionados (30 d)
165

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de LupoLab/solprop

Todos los issues de LupoLab/solprop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.