Skip to content

epic(cluster): hardware inventory & first-node selection #1080

Open
1 of 5 issues completed
Open

Description

@dezren39

Hardware inventory & first-node selection

Purpose

Know exactly what hardware exists, in what condition, so the first 3-5 cluster nodes are picked on evidence instead of memory.

Scope

Gather full hardware stats for all ~12 Threadripper machines (CPU, board, RAM, every NVMe/HDD with model + SMART, NICs, GPUs). Note the 8 HDDs still in the box (no baseline data exists yet). Rank machines by identical-ness and drive quality and name the first 3-5 cluster nodes and their order.

Execution mode

Hybrid: the inventory design, templates, and analysis are online; gathering stats needs machines powered and reachable (physical), or BMC/KVM access once cabled.

Dependencies

Feeds every other epic. Node selection gates epics 5 and 6.

Acceptance

A committed inventory (one record per machine) covering every machine and drive; a named, ordered first-node list with the reasoning recorded; open questions (exact NIC spec, switch gear) either answered or filed as task issues.

Structure

Part of the basement cluster program. Project home: planning/roadmaps/basement-cluster.md in this repo. Full program register: goal workspace files/idea-register-2026-10-20.md (Muse goal goal_ba17a5777c21). Detailed task issues are filed as sub-issues of this epic; dependencies use blocks / blocked-by links.

Hard rules for the whole program: no HashiCorp anything; everything bootstrappable from config, no hand-built state.

Activity

  1. added
    area/infraInfrastructure, deployment, and operations
    epicMeta-issue grouping multiple items (org Project Type=Epic)
    on Oct 27, 2026
  2. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  3. added
    effort/lLarge: multi-day or open-ended; expect staged check-ins
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    mode/hybridOnline work plus a physical step (power, cabling, KVM access to a real device)
    on Oct 27, 2026
  4. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    Epic map — basement cluster program

    # Epic Issue
    1 Hardware inventory & first-node selection #1080
    2 Firmware / BIOS / BMC audit #1081
    3 Basement power & space #1083
    4 Network fabric #1084
    5 Storage assembly & validation #1085
    6 TALM + Talos bootstrap #1086
    7 Cozystack platform #1087
    8 Platform services #1088
    9 Observability, backup & recovery #1090
    10 Cloud extension (OCI & egress) #1091
    11 First workload: ID app #1092
    12 ESP32 wing #1093

    This epic: #1080 — Hardware inventory & first-node selection
    Dependencies: Feeds all others; gates #1085, #1086

    Filed in the 2026-10-26 cluster seed. Project home: planning/roadmaps/basement-cluster.md.

  5. 1 remaining item

  6. added
    queue/queuedHas a queued task in the Supabase agent queue
    source/creatorFiled by the new-issue-creator job
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 3, 2026
  7. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    state: triaged (coverage pass)
    Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/none). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
    Found via: coverage pass 2026-11-03

  8. added
    work/assignedQueue worker lifecycle state
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    user/escalatedQueue or user escalation state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  9. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    state: picked-up → blocked (escalated to Drew — physical access required)
    queue: repo-health-code-pilot
    task: 7624 (blocked, reason class escalated-to-user)
    by: openchamber-scheduled-lane
    at: 2026-11-03T14:00Z

    Verdict: still live, and not workable from this repo — the blocker is hardware time

    Revalidated at current main (4c75cc808):

    • planning/roadmaps/basement-cluster.md:13 still carries this epic as a planned row — "Gather hardware stats for all ~12 machines and pick the first 3–5 cluster nodes" — with no status change since the roadmap was written.
    • No inventory records exist anywhere in the repo: planning/roadmaps/ holds only the roadmap, the electrician brief and the repo roadmaps; a Threadripper search across tracked Markdown returns the roadmap and the electrician brief, no per-machine records. So the epic's acceptance (one committed record per machine and drive, a named ordered first-node list) is not quietly done.
    • Nothing else in the queue or in open PRs covers it; this is not a duplicate and there is no superseding artifact.

    Why this is Drew's call, not a worker's

    The epic's own execution mode is hybrid, and the missing half is physical: "gathering stats needs machines powered and reachable (physical), or BMC/KVM access once cabled." A code-queue worker cannot power twelve machines, cable BMC, or read SMART data off drives that are still in the box (the 8 HDDs the epic explicitly says have no baseline). Everything a worker could contribute — the record schema, the analysis templates — is already described as online, and making those up front without a single real record would be busywork against a format nobody has validated.

    So the exact decision required:

    1. A hardware window where the ~12 machines are powered and reachable (or BMC/KVM cabled), so the inventory can actually be collected.
    2. Who collects it — Drew on site, or a session driven against reachable hosts once they are up.

    Handling

    • Queue task blocked (escalated-to-user), issue labelled user/escalated in place of status/needs-triage; queue/blocked + status/blocked set, work/assigned kept while it waits.
    • When the window is scheduled, the task resumes with this note as the brief: collect per-machine records (CPU, board, RAM, every NVMe/HDD with model + SMART, NICs, GPUs), commit them under planning/roadmaps/ (or wherever epic(cluster): hardware inventory & first-node selection #1080 names), then produce the ranked first-node list.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/infraInfrastructure, deployment, and operationseffort/lLarge: multi-day or open-ended; expect staged check-insepicMeta-issue grouping multiple items (org Project Type=Epic)meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedmode/hybridOnline work plus a physical step (power, cabling, KVM access to a real device)queue/blockedQueue or user escalation statesource/creatorFiled by the new-issue-creator jobstatus/blockedQueue or user escalation statetask/triageQueue packet kind: verify, reproduce, and route this itemuser/escalatedQueue or user escalation statework/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions