Context
Restructuring on restructure/namespace-services (this session) gave PV (Renewables), Ignis+BuEM (Building Model) their own Dockerfiles/containers, each reachable only over HTTP from the gateway — matching the target architecture diagram. Calliope and PyPSA did not get the same treatment: they still execute as local subprocesses (os/exec) inside the same webservice container as the Go gateway/Orchestrator, because the actual model-execution runtime (conda calliope-venv, c2p/pypsa/linopy) is baked into the same image (webservice.dockerfile FROM calliope-base:latest).
So webservice is not a pure orchestrator today — it's gateway + Orchestrator + Optimiser + Grid Simulator bundled into one process/container. environment/gateway/ (the folder holding calliope.dockerfile/calliope_gurobi.dockerfile/webservice.dockerfile) is named that way specifically because it doesn't map 1:1 to either the optimiser or grid-simulator diagram namespace.
Scope (once ratified)
- Extract Calliope's actual model-build-and-run logic (template copy, model.yaml generation,
exec.Command calls into the conda venv) into its own service+container, with its own HTTP API following the same Simulation interface pattern already used by BuEM/Ignis/PV.
- Same for PyPSA.
- Orchestrator (
simulations/orchestrator.go) calls both over HTTP instead of in-process function calls.
- The Calliope → PyPSA handoff itself is still a separate open "?" per the architecture diagram — not assumed resolved by this issue.
Context
Restructuring on
restructure/namespace-services(this session) gave PV (Renewables), Ignis+BuEM (Building Model) their own Dockerfiles/containers, each reachable only over HTTP from the gateway — matching the target architecture diagram. Calliope and PyPSA did not get the same treatment: they still execute as local subprocesses (os/exec) inside the samewebservicecontainer as the Go gateway/Orchestrator, because the actual model-execution runtime (condacalliope-venv,c2p/pypsa/linopy) is baked into the same image (webservice.dockerfileFROMcalliope-base:latest).So
webserviceis not a pure orchestrator today — it's gateway + Orchestrator + Optimiser + Grid Simulator bundled into one process/container.environment/gateway/(the folder holdingcalliope.dockerfile/calliope_gurobi.dockerfile/webservice.dockerfile) is named that way specifically because it doesn't map 1:1 to either theoptimiserorgrid-simulatordiagram namespace.Scope (once ratified)
exec.Commandcalls into the conda venv) into its own service+container, with its own HTTP API following the sameSimulationinterface pattern already used by BuEM/Ignis/PV.simulations/orchestrator.go) calls both over HTTP instead of in-process function calls.