fix(spdk-start): pass the host's fence ports to the SPDK pod so the entrypoint stops flushing iptables (R26.3)

[wmousa]

Problem

The ultra SPDK entrypoint ran iptables -F before every SPDK start to clear port fences left by a previous SPDK instance. The pod shares the host network namespace with the CNI, so the flush also wiped cilium's host chains: every SPDK restart on the ams1 cluster (2026-09/10) dropped host-to-pod traffic until the cilium agent was restarted.

The entrypoint is being changed (ultra fix/r263-scoped-fence-cleanup) to delete DROP/REJECT rules for an explicit port list only. It cannot derive that list itself: it sees RPC_PORT and FW_PORT, while the lvol and hublvol ports are allocated by the control plane.

Change

• port_block.host_fence_ports(node, db): every port the control plane may have fenced on that host for this SPDK instance. The lvol and hublvol ports of the node's own lvstore and of every lvstore it backs as secondary or tertiary, read from both the per-lvstore map and the legacy node-level fields. The legacy fields matter: records written by 25.10.x only carry those, and the 25.10.x control plane is the one that leaves iptables fences behind during an online upgrade. After the node is on the 26.x image the control plane only uses the SPDK port-block RPCs and the health check no longer reads iptables, so nothing else would ever remove them.
• restart_storage_node computes the list and passes it to spdk_process_start; SNodeClient sends it as fence_ports only when non-empty, so an older storage-node API sees the same request as before.
• Both storage-node APIs (kubernetes.py, docker.py) accept fence_ports and render it as the FENCE_PORTS env of the SPDK container (space-separated); the pod template gets the env entry. An older image ignores the variable.

Verification

• ruff and mypy clean on the touched files.
• New tests/unit/test_fence_ports_for_spdk_start.py: legacy 25.10 record, primaries backed by the node, per-lvstore map with dedup and a malformed entry, unassigned ports, env rendering, client omits the param when empty, both SPDKParams accept it, template renders it.
• Unit suite green locally (run with the 3.12 env; this branch's tox pins 3.9, so CI is the authoritative run).
• Not cluster-tested yet. Needs: 25.10.x cluster, upgrade control plane to this build, restart one node onto the companion ultra image, confirm iptables -S on that host has no leftover --dport 91xx -j REJECT and that cilium's chains are intact.

Systemic causes

• The port list a host can be fenced on existed only implicitly, scattered over the call sites of port_block.set_port and _node_lvs_ports in tasks_runner_port_allow.py. This PR adds a second derivation. One owner (the model: "ports this host serves") would remove both; cost moderate, it touches the port-allow recovery path.
• The 26.x health check never consults iptables once the RPC exists (port_block.is_port_blocked), so a leftover host rule on a lvol port is invisible. A cheap guard: read iptables once per restart on the storage-node API side and log any --dport DROP/REJECT it finds on a simplyblock port.
• spdk_process_start takes 24 positional/keyword parameters and grows by one per feature; a request model shared by client and both APIs would make additions like this one a single edit.

🤖 Generated with Claude Code