mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 10:35:51 +00:00
rcourtman
e74fea4bbc
A guest's unified canonical ID hashed its node-scoped source ID (instance:node:vmid), so a live migration to another cluster node re-minted the resource and orphaned every operator-owned row keyed by the old ID: explicit availability check links (fail-closed by design, the reported symptom in #1669), alert overrides, operator state, action audits, manual links, and recovery subjects. VMIDs are unique within a cluster, so guests now derive their canonical ID from instance+VMID ("proxmox-guest:<instance>:<vmid>") and keep it across migrations. The guest-metadata half of #1669 was fixed separately at the metadata-store layer. Existing installs converge through record-declared succession: ingest declares the retired node-scoped IDs superseded for every node the instance currently knows (current names plus native aliases), so rows orphaned by pre-upgrade migrations also re-key. Successions are now recorded durably in a canonical_id_successions table, which memoizes the re-key (steady-state rebuilds re-declare the same eras every tick without touching SQL) and lets change-journal reads merge retired guest eras the way pin EraIDs do for hosts. The succession re-key also covers manual link/exclusion rows. Availability links resolve retired canonical IDs and old-node source triples through a registry superseded index plus guest-triple parsing (persistence keys only, ambiguity fails closed), and the stored LinkedResourceID re-homes to the current canonical ID on the alert-migration cadence. Recovery subjects converge on the same derivation via CanonicalSubjectResourceID, the mapper's registry-miss fallback, node-independent external guest keys, and the store's startup backfill, which also sweeps posture rows stranded under retired subject keys. Metrics history and frontend row identity key off the node-scoped source ID and are deliberately unchanged.