Macvlan was a single-NIC SSH-safe hack that predated veth mode and was
never selected by any active config path. Deletion is Phase 0 item 1 of
the network layer redesign (mulga-siv-125.1).
Removed:
- BridgeModeMacvlan const + setMacvlanMAC + ifaceIsMacvlan probe
- Macvlan MAC alignment block in launchService (only fired on dead path)
- Macvlan branch in detectBridgeMode + matching tests
- Macvlan duplicates of IGW/AddNAT centralized-NAT tests (veth versions
already cover the same path)
- --macvlan flag + macvlan case branch in setup-ovn.sh
Refactored:
- useCentralizedNAT() now == BridgeModeVeth (was != BridgeModeDirect);
verifyBridgeMode already rejects empty/unknown at startup
- Three IGW-pool tests now explicitly WithBridgeMode(BridgeModeVeth)
(previously relied on empty-mode defaulting to centralized)
Kept intentionally:
- Deprecation notes in docs/compute/vpc-networking/README.md
- Legacy macvlan-interface cleanup in reset-dev-env.sh + ansible
teardown role (migration for operator systems with stale spx-ext-*
interfaces from pre-veth installs)
viperblock's WriteWALToChunk(false) is a no-op when the WAL is under
4MB (viperblock.go:1647-1657), so small user-data writes (the unit
file + index.html, ~300 bytes total) sit in the on-host WAL and are
lost when the host reboots before the WAL hits the threshold.
Workaround: write 8MB of zeros at end of user-data + sync to push WAL
over the threshold so the unit-file write definitely lands in
predastore before the host reboot. Drop when upstream fix lands.
Mirrors the same workaround in the Go reboot test
(tests/e2e/reboot/reboot_test.go on feat/e2e-go-harness).
Phase 8.3 polled VPC instance IPs via two-hop SSH. In single-node macvlan
mode the host has no route to VPC subnets, so SSH always timed out (10 min
of dead retries) even when the VMs were healthy (ALB targets passing health
checks).
Replace with a LaunchTime comparison: the daemon resets LaunchTime to
time.Now() when it relaunches QEMU on recovery, so LaunchTime >= REBOOT_START
is a fast, network-topology-independent reboot confirmation.
The internal-ALB approach was wrong on two counts:
- ALB_ENI_MAC is the OVN VPC ENI MAC (lives on br-int), never appears
in br-mgmt neighbour table, so the mgmt IP lookup always fails.
- Switching to internal masked the real bug: OVN EIP DNAT not restoring
properly after a host reboot, which is exactly what this test should catch.
Restore internet-facing ALB and EIP-based traffic bursts. The post-reboot
traffic failure (Phase 8.6) is the correct signal for the outstanding OVN
EIP DNAT persistence bug.
Keep the Phase 8.3 LaunchTime fix: two-hop SSH to VPC private IPs doesn't
work in single-node macvlan (host has no route to VPC subnets). LaunchTime
from describe-instances is fast and topology-independent.
Two changes to fix cell-18 (single/static/debian-13/reboot-single):
1. Switch ALB to --scheme internal.
Internet-facing ALBs work pre-reboot on single-node but post-reboot the
OVN EIP DNAT (nat-addresses=router GARP) is not re-established in time,
causing 100% curl timeouts. Internal ALB routes traffic via br-mgmt using
the mgmt IP discovered from the ALB ENI MAC in the br-mgmt neighbour table,
bypassing OVN external NAT entirely.
2. Replace Phase 8.3 guest SSH uptime check with LaunchTime assertion.
Two-hop SSH to VPC private IPs fails in single-node macvlan: the host has
no route to VPC subnets. LaunchTime from describe-instances is reset by the
daemon on QEMU relaunch, so LaunchTime >= REBOOT_START reliably confirms
recovery without network reachability to the guest.
The post-reboot guest uptime check was a single-shot ssh with a 10s connect
timeout. After the host comes back, guest QEMU + cloud-init + sshd inside
each guest still need a few seconds to settle, so the check raced them.
Poll up to GUEST_SSH_SECS (default 180s) per guest, mirroring the host
TCP/22 poll. Run 25329248329 cell-18 reproduced this — ALB targets went
healthy ~2s after the second SSH attempt failed.
joshsiv-mulga