HydraIssues

Today open issues live in hydraissue (issues.experiencenet.com) and nodes live in hydracluster (nodes.yaml). When operating a kiosk or body, there is no way to see "what open issues exist for this specific machine" without manually searching issue titles.

Proposal: surface per-node open issues in the hydracluster admin UI's node detail view.

Possible designs

A. Read-side join in hydracluster (recommended)

• hydracluster admin UI calls hydraissue GET /api/v1/issues?q=<node-name>+OR+<node-id> (or a structured field) when rendering a node's page.
• Display matching open issues as a small list with title + status + link.
• No data model change in hydraissue; relies on hostname/node-id appearing in the issue title or description, which is already convention.

B. First-class node field on issues

• Add a nodes []string field to Issue in hydraissue's store.
• New endpoint GET /api/v1/issues?node=<id> returns issues tagged with that node.
• hydraissue admin UI gets a node-id selector when filing/editing.
• hydracluster's node page calls this filtered endpoint.

C. Pure convention (cheap)

• Standardise the issue title prefix (e.g. [node-adf19775] or [turbo-pancake-76]) and rely on text search.
• hydracluster admin UI links out to issues.experiencenet.com/?q=<node-name> rather than embedding results.
• No code changes to hydraissue; only convention + a link.

Recommendation

Start with A for read-side surfacing (low cost, immediate value), then move to B if the volume of node-tagged issues grows enough to warrant structured filtering.

Why now

We just filed two node-specific issues (#122 catalog refactor scoped at cheeky-cactus, and the cosmic-pretzel firewall issue we are about to file). Without a linkage view, the next operator looking at cosmic-pretzel-98 in hydracluster has no idea there is an outstanding firewall issue against it.