mitchell/hamlab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 14 Wiki Activity

PLAN: the Docker tab's polish and retiring Dockhand are one item

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Mitchell-Johnson
2026-09-24 16:15:00 -07:00
co-authored by Claude Opus 5
parent 66c1ed7d13
commit e6625a540c
1 changed files with 38 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN.md
+38 -20
View File
@@ -534,26 +534,44 @@ something long in one, switch away and back, refresh — it's all still there.
`hamlet`'s `docs/hosts.md` bare-metal list, `docs/gotchas.md` (the "`docker ps` is not
the inventory" note names it) and the `grid` row in `CLAUDE.md`.
- **Deprecate Dockhand** — asked for 2026-09-23, not started; the *homelab* half of this
(migrating every stack off Dockhand's data dir, then removing the container) is
`hamlet`'s `docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator",
agreed 2026-09-20. This entry is the *app* half only: what Ham Lab must do before that
migration can start. Its Stacks page already creates, edits, deploys, updates, restarts,
stops, downs and deletes stacks on every machine, so the gaps are Dockhand's extras:
- **Git-sourced stacks.** Dockhand's `stack_sources` table points a stack at a repo and
pulls it. Ham Lab has no equivalent. Decide whether to build it or to drop it — most
stacks here have no row in that table anyway, so dropping it may be honest.
- **Scheduled image updates.** Ham Lab checks for new images only when asked (a registry
request Docker Hub counts) and never updates by itself. If anything relies on Dockhand
updating on a schedule, that must move here or be dropped on purpose.
- **Webhooks / per-host environments**, if either is in use — inventory before deciding.
- **Deploying from a host path without an orchestrator container.** Ham Lab already runs
compose inside `dockhand` because that is how the stacks were deployed; once they move
to a neutral home the "via" path is unused for them, but a stack deployed to `grid` or
the Mac still goes over `tcp://<node>:2375` from the hub. Decide whether Ham Lab should
instead ask the node's own Ham Lab to deploy locally, which would end the `*:2375`
exposure (its own item in `docs/pending.md`).
- *Not app work, but the trigger:* nothing here blocks starting the migration except the
- **Grow the Docker tab until Dockhand can go** — asked for 2026-09-23 and widened
2026-09-24 to take in Docker tab polish and feature work, on the same reasoning as the
Files item: it is one tab, and the gaps that block retiring the old tool and the things
that would simply make it better are the same body of work. The *homelab* half —
migrating every stack off Dockhand's data dir, then removing the container — is `hamlet`'s
`docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator", agreed
2026-09-20. This entry is the *app* half.
Where it stands: Stacks already creates, edits, deploys, updates, restarts, stops, downs
and deletes stacks on every machine, and Containers does start/stop/restart, logs that
follow, inspect, and the images/volumes/networks tables. So this is not a rewrite.
- **What Dockhand still does that Ham Lab does not.**
- *Git-sourced stacks.* Dockhand's `stack_sources` table points a stack at a repo and
pulls it. Ham Lab has no equivalent. Decide whether to build it or drop it — most
stacks here have no row in that table anyway, so dropping it may be the honest answer.
- *Scheduled image updates.* Ham Lab checks for new images only when asked, since each
check is a registry request Docker Hub counts, and never updates by itself. If
anything relies on Dockhand updating on a schedule, that must move here or be dropped
on purpose. Note the Jobs tab and the ZFS schedules already show the shape this would
take: a cron line Ham Lab owns, not a ticker in the daemon.
- *Webhooks and per-host environments*, if either is in use. Inventory before deciding.
- **Known gaps in the tab itself**, worth closing whether or not Dockhand goes:
- *Removing networks* — volumes and images can be pruned and removed, networks cannot.
- *Container detail is thin next to the stack view.* No per-container resource limits,
restart-policy editing, or exec-into-container from the tab (the Terminal tab is the
workaround). Decide which of these belong here at all.
- *Logs are polled with `--since` rather than followed over a held connection.* That was
deliberate and works, but a long tail is choppier than the Services tab's live tail,
which does hold a connection. Worth reconciling the two.
- *Image update checks are remembered six hours and asked for per stack*, so there is no
one view of "what is out of date across the fleet".
- **The `*:2375` question, which this is the moment to settle.** Ham Lab runs compose
inside `dockhand` because that is how the stacks were deployed; once they move to a
neutral home that path is unused for them, but a stack deployed to `grid` or the Mac
still goes over `tcp://<node>:2375` from the hub. Decide whether the hub should instead
ask the node's own Ham Lab to deploy locally, which would end the unauthenticated
Docker socket exposure — its own item in `docs/pending.md`, currently filed under
"decided, no action", and this is the change that would make closing it free.
- *Not app work, but the trigger:* nothing above blocks starting the migration except the
inventory. Do that first.
- **A Virtualization tab** — asked for 2026-09-23, not started, and **large**. Run and