[scotwells]

Summary

When a location blocks a guest's agent port from the rest of the network, a node running an older Galactic quietly ignores the block and starts the VM with the port open. This change has those attachments name a Galactic plugin that only nodes able to enforce the block install. On an older node the VM fails to start rather than starting exposed, and a node rolled back past that plugin retries teardown until it is installed again. Attachments without host-only ports are unchanged.

The matching Galactic change, datum-cloud/galactic#1277, has merged and installs the plugin under its new name. Part of datum-cloud/enhancements#900.

Test plan

• A tap conflist with host-only ports names galactic-tap-host-only
• Every other conflist stays byte-identical
• On a node with the new Galactic, a guest with host-only ports starts and its port stays blocked from the network
• On a node without it, the attachment fails instead of starting with the port open

[ecv]

Approve.

NSO names galactic-tap-host-only only when the attachment is the tap plugin and hostOnlyPorts is non-empty, so a node whose Galactic lacks the binary fails ADD and the VM does not start with the port open. That is the intended fail-closed behavior, and it matches what galactic#1277 installs. #1277 merged at 17:46Z today but is in no Galactic release yet (latest v0.8.2, 2 Nov), so release order matters for the one cell already opted in.

• Condition is plugin == PluginTap && len(hostOnlyPorts) > 0; every other conflist stays on galactic-tap.
• TestConflistCarriesHostOnlyPorts now asserts both cases: fenced gets galactic-tap-host-only, open stays galactic-tap.
• Gated by HypervisorHostOnlyPorts, which has no default (nil, omitempty), but one cell has already opted in: clusters/edge/us-central-1-staging-lab/kustomization.yaml:459 sets hypervisorHostOnlyPorts: [20000] with attachmentMode: Hypervisor, on infra main and in v0.84.208. When that lab runs an NSO with this change, its tap attachments switch to galactic-tap-host-only. Ship a Galactic release carrying #1277 to that lab first, or new VMs there fail ADD and existing ones fail DEL. Unit CI and lint are green; e2e was still running at review.
• Teardown caveat is documented: a node rolled back past the plugin fails DEL for sandboxes whose conflist names it, and retries until the binary returns.

Follow-ups:

• The two on-node test-plan boxes are unchecked (new Galactic blocks the port, old Galactic fails the attachment); tick them before any cell sets hypervisorHostOnlyPorts.
• Existing NADs are rewritten: reconcileNAD runs on every reconcile and CreateOrUpdate sets nad.Spec.Config fresh, so every running VM's NAD on the opted-in lab moves to the new name at the next resync. That is why the Galactic release has to land first.