Update ran as a blocking POST with nothing to show but a spinner, so the
status added in 86c67df could only sit above the table as a banner.
Adds /ws/update/{stack_id}, streaming `compose pull` then `up -d` with
--progress json, and feeds it through the existing DeployTracker — the
same weighting the deploy console uses. The result renders as a progress
bar inside the stack's own row: percentage, phase label, and layer/byte
detail. Non-streaming actions (start/stop/restart/pull/down) reuse the
bar in its indeterminate form, so every row action looks consistent.
compose_service gains _stream_phase, shared by stream_up and the new
stream_update; a failed pull short-circuits before `up`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016pMmFFkdfxkoYjcEcpZTa5
The status banner added in 9d28e12 only rendered on the stack detail
page, but Update is most often clicked from the stacks list — so in
practice the status was invisible. Render it on the stacks list and
dashboard too.
Actions on different stacks run concurrently from the list, so busy
state and status are now keyed by stack id instead of a single value:
previously the first action to finish cleared every row's spinner, and
each new action overwrote the previous one's status. StacksTable takes
an isBusy(id) predicate in place of the single busyId prop.
Also bumps the version so the newly version-tagged CI images (f8bfc91)
actually differ from the running release — self-update compares tags
against APP_VERSION, so shipping without a bump shows no update.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016pMmFFkdfxkoYjcEcpZTa5
The cockpit cards gated purely on `fleet.data`, so any failed
/api/dashboard/fleet request (e.g. a stale backend returning 404, or a
500) left the new components stuck on skeletons forever. Render a clear
error banner with the API message and a Retry button when the query
errors with no data, so the actual cause is visible.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace the analytics-style dashboard (stack-health funnel, uptime %,
operations/day grid, AI pill) with an attention-driven fleet cockpit:
- New /api/dashboard/fleet endpoint: server-side fan-out across the local
host and every agent into one payload — a prioritized "needs attention"
list, headline KPIs, an honest stack-status breakdown and a per-host
resource rollup. Each agent uses its own DB session so the fan-out is
concurrency-safe; failures degrade to "offline" instead of stalling.
- New frontend: AttentionStrip, FleetKpiRow, StackStatusBar and
HostResourceTable; Dashboard.tsx rewritten around them.
- Remove the funnel/summary endpoints, the uptime sampler loop and the
ops-activity machinery; delete the now-unused chart components.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Container card now compares compose-only counts across hosts: agents
report compose_running in /agent/system (pre-0.31.1 agents fall back to
the all-containers number); card retitled, ResourceBar stat labelled
'Containers (all)'.
- Uptime is sampled every 5 min (background loop + opportunistic on read)
and charted as daily averages instead of a once-a-day snapshot; no
sample is written when no compose containers exist (was: fake 100%).
Legacy daily entries in uptime.jsonl still count; file pruned at startup.
- Funnel stage 'monitored' is now per-stack and real: stacks with an
enabled local auto-update policy (was: global webhook-exists toggle).
Frontend label renamed to 'Auto-managed'.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The Dashboard's stacks-usage table (CPU/mem meters + inline
start/stop/restart) is now a reusable components/stacks/StacksTable.tsx
used by both the local and per-agent host sections. Removes the
duplicate inline definition that was left behind by the half-finished
extraction (which broke the build: redeclared StacksTable + dangling
imports). No behaviour change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The per-host resource bar gained a "Volumes" stat showing the total size of
that host's Docker volumes. It reuses the existing cached /volumes/sizes lookup
(docker system df, ~60s TTL) summed client-side, polled every 60s per host so
the slow df walk never blocks the fast system-info poll.
Frontend-only. Fixed sumSizes to reduce<number> so the value is number|undefined.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The per-host resource bar gained a Disk stat (used / total). The agent now
reports disk_total/disk_used via shutil.disk_usage on its stacks dir (a host
bind-mount), alongside the existing cpu/mem/containers fields; the local host
uses the existing system info disk data.
- agent_app.py: _disk_info() + disk_total/disk_used in _system_info().
- Frontend: ResourceBar gained diskUsed/diskTotal (5-column grid); AgentSystem
type gained disk_total/disk_used.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The dashboard resource bar (CPU cores, memory used/total, containers, Docker
version) is now rendered per host instead of once for the local host — each
host section (local + each agent) shows its own bar above its stacks table.
- agent_app.py: _system_info() now also returns mem_used (from meminfo
available), alongside the cpu_cores/mem_total added in 0.19.0.
- Frontend: extracted a ResourceBar component used by the local section and each
AgentDashboardSection; AgentSystem type gained mem_used.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The dashboard now renders a stacks-with-usage table per host: the local host
plus a section for each registered agent (online dot + offline notice), reusing
the same CPU/memory meters and inline start/stop/restart actions.
- agent_app.py: GET /agent/stacks/stats (reuses stats_service); /agent/system
now also returns cpu_cores + mem_total for remote meter references.
- routers/agents.py: proxy GET /api/agents/{id}/stacks/stats (declared before
/{agent_id}/stacks/{stack_id}).
- Frontend: agentsApi.system + stackStats; Dashboard refactored into a shared
StacksTable used by the local section and a per-agent AgentDashboardSection.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The dashboard now lists stacks in a table with live CPU and memory usage per
stack. Usage is sampled from docker stats (one-shot read per running container,
using the daemon-provided precpu for the CPU delta) and aggregated by compose
project.
- services/stats_service.py + GET /api/stacks/stats: per-stack cpu_used (cores),
mem_used (bytes minus reclaimable cache), and the summed assigned cpu/mem
limits (null when none set), read concurrently across containers.
- Dashboard: stacks render as a table with a CPU and a Memory meter. When a
limit is assigned the bar fills toward it (used / limit + %); otherwise it
fills toward the host total. Inline start/stop/restart per row for admins.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Networks and Images are now per-host, rendered as a section for the local host
plus one per registered agent (like the Stacks page).
- agent_app.py: new /agent/networks (list/inspect/containers/connect/disconnect/
create/delete/prune) and /agent/images (list/updates/check), reusing
network_service and a new image_service; DockerError mapped to HTTP status
(forbidden -> 400 so the proxy doesn't treat it as a token failure).
- routers/agents.py: proxy routes at /api/agents/{id}/networks/* and
/api/agents/{id}/images/*, audit-logging mutations.
- services/image_service.py: extracted the image-listing logic so the central
router and the agent share it.
- Frontend: networksApi/imagesApi take an optional agentId; Networks/Images
pages render NetworksSection/ImagesSection per host with a shared HostHeader.
Remote "Prune unused" networks resolves the address-pool-exhaustion deploy
error from the UI.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
