GPU system tracking UI. #124

New issue

Open

opened 2026-07-16 16:24:02 +00:00 by eliribble · 1 comment

eliribble commented

2026-07-16 16:24:02 +00:00

Owner

This issue is to begin work on phase 1, and 3 of the Nidus Reveal Implementation Plan. Specifically I want the database schema and API for worker registration. I'd also like you to create a UI for exercising the worker registration API. It should like in the "sudo" area of the UI and have a new tab, "GPU". This tab will need to show a list of currently known GPU workers, as well as a list of previous instances and some high-level data we have about them. You can look at the Nidus Reveal Design for context on where this all fits.

What I'd like to be able to test from your feature branch is the ability to create a record for a new GPU instance and have it give me the secret key. I'll then spin up an actual GPU instance give it the secret key. We'll need an API for the worker to use the secret key to indicate that it is up and provide detailed information about its hardware. I'm not seeing an API for that in the design document - please at a PUT request to /api/v1/vision/worker/:id where the worker can signal its status. Update the document in your PR.

This issue is to begin work on phase 1, and 3 of the [Nidus Reveal Implementation Plan](doc/nidus-reveal/implementation.md). Specifically I want the database schema and API for worker registration. I'd also like you to create a UI for exercising the worker registration API. It should like in the "sudo" area of the UI and have a new tab, "GPU". This tab will need to show a list of currently known GPU workers, as well as a list of previous instances and some high-level data we have about them. You can look at [the Nidus Reveal Design](doc/nidus-reveal/design.md) for context on where this all fits. What I'd like to be able to test from your feature branch is the ability to create a record for a new GPU instance and have it give me the secret key. I'll then spin up an actual GPU instance give it the secret key. We'll need an API for the worker to use the secret key to indicate that it is up and provide detailed information about its hardware. I'm not seeing an API for that in the design document - please at a PUT request to /api/v1/vision/worker/:id where the worker can signal its status. Update the document in your PR.

ned was assigned by eliribble

2026-07-16 16:24:02 +00:00

ned commented

2026-07-16 16:30:49 +00:00

Member

PR #125 is ready for review. Here is what was implemented:

Backend

Phase 1: Migration 00174_vision_workers.sql creates the vision_workers table with all lifecycle fields, bcrypt-hashed secrets (nwsk_ prefix), operator-provided hardware specs, worker-reported hardware fields, cost tracking, and rolled-up metrics.
Phase 3: Worker registration API at /api/v1/vision/workers/ — CRUD for worker lifecycle (register, list, detail, shutdown).
New endpoint (as requested): PUT /api/v1/vision/worker/{id} — the worker authenticates with its Bearer secret (Authorization: Bearer nwsk_...) and reports its hardware configuration. On first signal, status transitions from pending to active, and first_poll_at is recorded.

Frontend

New GPU tab in the sudo area showing:
- Summary cards (active/pending/shutdown counts, total tasks)
- Worker list with status badges, heartbeat timestamps, uptime, cost
- Detail panel on row click with full lifecycle, hardware specs, and reported environment
- Registration modal with one-time secret display and copy button
- Shutdown button with confirmation dialog

Docs

Updated design.md with section 6.5 documenting the Worker Status Signal endpoint
Updated implementation.md adding the PUT endpoint to Phase 3

To test

Apply the migration: cd db/migrations && ./goose.sh up
Visit /_/sudo → GPU tab
Register a worker → copy the secret

Test the status signal:

curl -X PUT https://nidus-sync/api/v1/vision/worker/<WORKER_ID> \
  -H "Authorization: Bearer nwsk_<secret>" \
  -H "Content-Type: application/json" \
  -d '{"gpu_model": "NVIDIA RTX 4090", "hostname": "test-worker"}'

Verify it shows as active in the UI

PR #125 is ready for review. Here is what was implemented: ## Backend - **Phase 1:** Migration `00174_vision_workers.sql` creates the `vision_workers` table with all lifecycle fields, bcrypt-hashed secrets (`nwsk_` prefix), operator-provided hardware specs, worker-reported hardware fields, cost tracking, and rolled-up metrics. - **Phase 3:** Worker registration API at `/api/v1/vision/workers/` — CRUD for worker lifecycle (register, list, detail, shutdown). - **New endpoint (as requested):** `PUT /api/v1/vision/worker/{id}` — the worker authenticates with its Bearer secret (`Authorization: Bearer nwsk_...`) and reports its hardware configuration. On first signal, status transitions from `pending` to `active`, and `first_poll_at` is recorded. ## Frontend - New **GPU** tab in the sudo area showing: - Summary cards (active/pending/shutdown counts, total tasks) - Worker list with status badges, heartbeat timestamps, uptime, cost - Detail panel on row click with full lifecycle, hardware specs, and reported environment - Registration modal with one-time secret display and copy button - Shutdown button with confirmation dialog ## Docs - Updated `design.md` with section 6.5 documenting the Worker Status Signal endpoint - Updated `implementation.md` adding the PUT endpoint to Phase 3 ## To test 1. Apply the migration: `cd db/migrations && ./goose.sh up` 2. Visit `/_/sudo` → GPU tab 3. Register a worker → copy the secret 4. Test the status signal: ``` curl -X PUT https://nidus-sync/api/v1/vision/worker/<WORKER_ID> \ -H "Authorization: Bearer nwsk_<secret>" \ -H "Content-Type: application/json" \ -d '{"gpu_model": "NVIDIA RTX 4090", "hostname": "test-worker"}' ``` 5. Verify it shows as active in the UI