Studio: switch hardware profile from the UI, not from four env vars #36

New issue

Open

opened 2026-07-27 22:19:25 -04:00 by cmoriarty · 0 comments

cmoriarty commented

2026-07-27 22:19:25 -04:00

Owner

Switching the rig between trogdor-quality and trogdor-speed (#35) currently means editing four env vars in the Portainer stack and redeploying. That is the wrong surface for something a human should be able to decide mid-session — "generate this one fast and rough" vs "generate this one properly" is a judgement call about the work in front of you, not a deployment change.

What exists to build on

GET /orch/health and GET /orch/config already carry a hardware block: resolved profile name, description, brain_resident, brain_gpus, roster, and the seat→card map.
GET /orch/profiles lists every shipped profile with the same shape, so the picker has its options without the studio learning the YAML.
The studio already shows the live profile in the system-dot tooltip, and flags a deployed brain that does not match the profile (brain_pinning).
trog profile <name> is the interim CLI path (deliberate: the UI was deferred, not skipped).

What the studio needs

A picker — most likely beside the brain selector, since it answers the same class of question — that shows the current profile and switches to another. Switching must be honest about its cost: it is a stack redeploy, the brain reloads its roster, and in-flight work has to be finished or refused first.

The hard part, stated up front

The orchestrator does not create the brain container; compose does. So a switch is not a runtime toggle — it edits the deployment's env (TROG_PROFILE, BRAIN_ROSTER, BRAIN_GPUS, BRAIN_CPUSET, which must move together) and redeploys the stack. Two candidate shapes:

Studio → orchestrator → Portainer API. The orchestrator gains a POST /profile that patches the stack env and redeploys. Cost: the orchestrator learns about Portainer, which nothing server-side currently knows, and it needs a Portainer token — a real widening of what a compromised orchestrator can do.
Orchestrator recreates the brain itself. It already owns the docker socket and stops/starts the brain today. It could recreate the container with new CUDA_VISIBLE_DEVICES/cpuset and reload its own profile. Cost: the container then differs from what compose declares, so the next unrelated redeploy silently reverts the profile — and the deployment rule is that Portainer stack config is truth.

Neither is obviously right. Worth deciding before building the picker, because the answer decides whether this is a studio feature or a deployment feature wearing a studio hat.

Done when

The live profile is visible in the studio without a tooltip hunt, and switchable from it.
A switch refuses (or waits) while a run, build, or generation is in flight, rather than pulling the rig out from under it.
Whatever path is chosen, the Portainer stack env and the running containers still agree afterwards — brain_pinning stays null.

Related: #35 (the two profiles and the resident brain), #7 (studio), #27 (hardware profiles).

Switching the rig between `trogdor-quality` and `trogdor-speed` (#35) currently means editing four env vars in the Portainer stack and redeploying. That is the wrong surface for something a human should be able to decide mid-session — "generate this one fast and rough" vs "generate this one properly" is a judgement call about the work in front of you, not a deployment change. ## What exists to build on - `GET /orch/health` and `GET /orch/config` already carry a `hardware` block: resolved profile name, description, `brain_resident`, `brain_gpus`, roster, and the seat→card map. - `GET /orch/profiles` lists every shipped profile with the same shape, so the picker has its options without the studio learning the YAML. - The studio already shows the live profile in the system-dot tooltip, and flags a deployed brain that does not match the profile (`brain_pinning`). - `trog profile <name>` is the interim CLI path (deliberate: the UI was deferred, not skipped). ## What the studio needs A picker — most likely beside the brain selector, since it answers the same class of question — that shows the current profile and switches to another. Switching must be honest about its cost: it is a stack redeploy, the brain reloads its roster, and in-flight work has to be finished or refused first. ## The hard part, stated up front The orchestrator does not create the brain container; compose does. So a switch is not a runtime toggle — it edits the deployment's env (`TROG_PROFILE`, `BRAIN_ROSTER`, `BRAIN_GPUS`, `BRAIN_CPUSET`, which must move together) and redeploys the stack. Two candidate shapes: 1. **Studio → orchestrator → Portainer API.** The orchestrator gains a `POST /profile` that patches the stack env and redeploys. Cost: the orchestrator learns about Portainer, which nothing server-side currently knows, and it needs a Portainer token — a real widening of what a compromised orchestrator can do. 2. **Orchestrator recreates the brain itself.** It already owns the docker socket and stops/starts the brain today. It could recreate the container with new `CUDA_VISIBLE_DEVICES`/cpuset and reload its own profile. Cost: the container then differs from what compose declares, so the next unrelated redeploy silently reverts the profile — and the deployment rule is that Portainer stack config is truth. Neither is obviously right. Worth deciding before building the picker, because the answer decides whether this is a studio feature or a deployment feature wearing a studio hat. ## Done when - The live profile is visible in the studio without a tooltip hunt, and switchable from it. - A switch refuses (or waits) while a run, build, or generation is in flight, rather than pulling the rig out from under it. - Whatever path is chosen, the Portainer stack env and the running containers still agree afterwards — `brain_pinning` stays null. Related: #35 (the two profiles and the resident brain), #7 (studio), #27 (hardware profiles).

cmoriarty referenced this issue from a commit

2026-07-27 22:22:05 -04:00

feat: trog profile — switch the rig layout without hand-editing four vars

cmoriarty referenced this issue

2026-07-27 23:10:30 -04:00

Process spine: generate assets per milestone, and two trogdor profiles (quality / speed) #35

cmoriarty referenced this issue

2026-07-27 23:51:44 -04:00

Process spine: generate assets per milestone, and two trogdor profiles (quality / speed) #35