6 Commits

Author	SHA1	Message	Date
Josh Siviour	3e195506d3	feat(images): mkosi system-image migration — CPU eks-node/ecs-node + GPU variants (#605) ... * fix(eks): GPU node AMI declares uefi boot mode The spinifex-eks-node-gpu catalog entry declared BootMode: bios, but the Ubuntu 26.04 GPU appliance image is built GPT/EFI-only. Under legacy BIOS no OVMF/pflash firmware is attached, so the guest hangs at firmware with zero serial console output. * fix(images): install open-kernel NVIDIA DKMS driver for Blackwell GPUs Blackwell-generation GPUs (e.g. RTX Pro 6000 Blackwell) refuse to initialize under the closed/proprietary kernel module: dmesg shows RmInitAdapter failing with "requires use of the NVIDIA open kernel modules" (NVRM error 0x22). Switch from nvidia-dkms-<ver>-server to nvidia-dkms-<ver>-server-open in both the shared ubuntu-gpu-nvidia recipe and its verbatim duplicate in eks-node-gpu. nvidia-utils has no separate open variant (userspace tools only), so it is unchanged. * fix(eks): tolerate CP and GPU taints in ebs-csi-controller/lbc addons A cluster with a GPU-only nodegroup has no untainted node: the CP carries CriticalAddonsOnly (EKS parity keeps user workloads off it) and every worker carries nvidia.com/gpu. Without tolerations for both, ebs-csi-controller and aws-load-balancer-controller have nowhere to schedule and stay Pending forever. Real EKS never needs this since its control plane isn't a schedulable node, so the stock upstream manifests carry no such toleration. * fix(images): give the libguestfs appliance a working resolver The guest's /etc/resolv.conf symlinks to systemd-resolved's stub (127.0.0.53), which isn't running inside the appliance chroot, so DNS is dead until package installs need it. Point it at a real resolver before package installs, then restore the stub symlink afterward so the shipped AMI still gets its DNS from systemd-resolved at boot like a stock cloud image. * fix(gpu): skip upstream PCIe bridge devices during VFIO bind/unbind A GPU's IOMMU group can include an upstream PCIe bridge when the platform lacks ACS isolation between them. vfio-pci refuses to bind non-endpoint bridge devices, so Claim/ReclaimByAddress must filter bridge-class (0x06) members out of the group before touching driver bindings, rather than failing the whole claim or leaving the bridge rebound incorrectly. * fix(ecs): GPU node AMI declares uefi boot mode The spinifex-ecs-node-gpu catalog entry declared BootMode: bios, but the Ubuntu 26.04 GPU appliance image is built GPT/EFI-only. Under legacy BIOS no OVMF/pflash firmware is attached, so the guest hangs at firmware with zero serial console output. Same defect and same fix as the eks-node-gpu entry: both images are built by the same script from the same stock Ubuntu cloudimg, so both were EFI-only and only one was corrected. * fix(images): open-kernel NVIDIA module on ecs-agent-gpu, pin driver branch ecs-agent-gpu still installed nvidia-dkms-<N>-server, the proprietary kernel module. NVIDIA ships no proprietary module for Blackwell (GB202) and later, so ECS GPU container-instances could not bind those cards on any driver branch. It is the third verbatim copy of the routine and was missed when the other two were fixed. Also pins the driver branch across all three copies. The branch was resolved at build time via apt-cache search | sort -rn | head -1, which sorts on the number in the package name — but that number is a branch alias, not a driver version (nvidia-dkms-535-server installs 580.126.20), so the ordering key need not match what installs. Resolving also let identical source produce different drivers on different days. The pin lives in setup.sh rather than manifest.conf because manifest variables are not passed into the guest: the setup script is uploaded and executed by virt-customize --run, with no environment carried across. * fix(eks): tolerate CP and GPU taints in argocd addon All six argocd Deployments and its StatefulSet carried no tolerations. A cluster with a GPU-only nodegroup has no untainted node to place them on: the control plane carries CriticalAddonsOnly and every worker carries nvidia.com/gpu, so the pods stay Pending forever. Same defect the ebs-csi-controller and load-balancer-controller addons already had. Real EKS never hits it because its control plane is not a schedulable node, so the stock upstream manifests carry no such toleration and the divergence is ours to maintain. * refactor(images): extract eks-node initd logic into init-agnostic helpers The OpenRC runscripts carried their start_pre logic inline, so porting a service to systemd meant re-deriving that logic under a distro change rather than just rewriting the init wiring. Move it into /bin/sh helpers that either init system can drive, keeping eks-node on Alpine/OpenRC. k3s-prestart takes the restore-block guard, config.yaml derivation, konnectivity-agent and CoreDNS staging, and the token-webhook wait. konnectivity-server-prestart takes the CA wait and cert mint, plus the server-count derivation that used to run at parse time. Both keep every guard, bound and message as-is. Values flow back the way the GPU image already does it: the helper writes shell assignments to a /run file and the init system sources them, so command_args is built in start_pre where it used to be a top-level assignment. k3s-agent-prestart moves to eks-node and becomes the single copy. The GPU manifest claimed its helpers were reused verbatim from eks-node while hand-copying this one; it now points at the shared file, so the two cannot drift. k3s-agent.initd still sources agent.env and exports itself rather than delegating: OpenRC has no EnvironmentFile= equivalent, and the daemon inherits only what the runscript exports, so a helper subprocess sourcing it would not reach k3s. The helpers run under set -eu, which the runscripts did not. The awk over first-boot.env is guarded on the konnectivity manifest, not on the env file, so a missing env file exits awk nonzero; without || true that turned a warn-and-continue into a refusal to start k3s. Covered by a test that fails on rc=2 if the guard is dropped. * feat(images): build system images in a pinned mkosi container Move the image-build toolchain into a container so a runner needs only Docker. The toolchain cannot drift between runners, and the same build runs identically on a developer's machine. mkosi builds in a user namespace, which two of Docker's default confinements block: the seccomp profile masks CLONE_NEWUSER, and the docker-default AppArmor profile separately blocks unsharing the mount namespace. Both are relaxed; neither is a privilege grant, as capabilities stay dropped and no devices are exposed. mkosi also runs as an ordinary user rather than root, since as root it takes a path that needs real CAP_SYS_ADMIN. Verified end to end: an Ubuntu 26.04 Format=disk image builds from the Debian container and the artefact is a valid GPT disk, with the package cache on a named volume cutting a forced rebuild from ~2min to ~34s. * feat(images): publish system images from the build container Convert mkosi's raw output to a compressed qcow2, write the .sha256 sidecar the spx catalog verifier matches, and upload both to R2 using the same pinned toolchain as the build, so publishing needs nothing on the host either. The toolchain image build moves to a shared helper rather than being duplicated across the two entry points. Publishing needs no relaxed confinement, unlike the build: qemu-img and aws create no namespaces, so it keeps Docker's default seccomp and AppArmor profiles. The object path carries no version and the catalog resolves newest-wins, so an upload overwrites the live image with no way back. Copy the current object to a timestamped archive key first, making a bad publish a restore rather than an unrecoverable loss. * fix(images): build the image on the output's mount, not the cache volume mkosi assembles the image in its workspace and moves the result to the output directory. The workspace lived under the cache volume, which is a different mount from the output bind mount even when both sit on one filesystem, so the move failed EXDEV and mkosi fell back to copying — requiring the finished image to exist twice at once. That is invisible on a small image and fatal on a real one: a ~4G GPU image needed ~8G to land and died with ENOSPC after a successful build. Point the workspace at the output's own mount so the move is a rename again and the image only exists once. The package cache stays on the volume, which is the part worth persisting across runs. * feat(images): add mkosi base config and gpu-nvidia profile Establish images/ with a base mkosi.conf plus a gpu-nvidia profile, replacing the throwaway smoke-test config. The base builds a bootable UEFI disk; the profile adds the NVIDIA stack. Most of ubuntu-gpu-nvidia-setup.sh does not carry over. Its kernel-version hunt, the do_bootloader=no kernel-img.conf hack and the manual update-initramfs all exist only because that pipeline chroots into a prebuilt cloud image that already has a kernel. mkosi installs the kernel and owns the bootloader, so the version is known rather than detected, and the postinst asserts exactly one kernel instead of searching for it. The static configuration (nouveau blacklist, unattended-upgrades blacklist, cloud-init docker group) becomes files under mkosi.extra/ rather than heredocs. linux-image-generic drags in every linux-firmware split package, none of it relevant to a headless VM guest; left at the default the modules initrd embeds all of it into the UKI, which grew to ~880MB and overflowed the 512M ESP. The initrd module set is trimmed to mkosi-initrd's curated default, which is a boot fix and not only a size one. Verified in the built artefact, not just the build log: nvidia.ko.zst and the four sibling modules under /usr/lib/modules/<kver>/updates/dkms, the nouveau blacklist, and the nvidia runtime in docker's daemon.json. * fix(images): unblock guest boot on wait-online and firstboot A guest built from these images stalled twice on the way to a login prompt, both times on a unit waiting for input that never arrives in a VM. systemd-networkd-wait-online holds network-online.target until every managed link is up, and docker.service pulls that target in with Wants=, so any image carrying docker inherits the wait whether or not it wants it. A guest whose links are slow or absent ran the unit to its full 120s default with multi-user.target queued behind it. Override it to --any with a short timeout: one link up is what a single-NIC guest actually needs. systemd-firstboot separately prompts on the console for anything the image does not already carry, before multi-user.target. With no timezone baked in, boot stopped dead at "Please enter the new timezone name" and waited for a keystroke. Setting locale, keymap and timezone at build time leaves firstboot with nothing to ask. Both are baked into the base rather than delivered as first-boot drop-ins: an image built from scratch has no cloud-init to write them. Measured on wattle with an A1000 passed through: login at 42.8s, down from ~210s, and the firstboot prompt is gone. nvidia-smi in the guest reports "NVIDIA RTX A1000, 595.71.05, 8188 MiB". Also widen the images gitignore to output-*/ so a scratch build cannot leave multi-GB artefacts stageable. * feat(images): make the base image reachable — cloud-init, sshd, console An image built from scratch launched unreachable. The images this replaces start from a stock Ubuntu cloud image and inherit cloud-init, sshd, sudo, a network renderer, dbus and a serial console from it; mkosi installs only what is listed, so none of it was there and nothing said so. Guests get their SSH key and user-data from IMDS via cloud-init, so without the package a launched instance has no authorized_keys at all — no error, just no way in. It also made any cloud-init-delivered config inert, including the gpu profile's docker-group drop-in. Each addition is load-bearing on its own: cloud-init consumes IMDS: keys, user-data, hostname, network openssh-server the key needs a sshd to be installed into netplan.io cloud-init's renderer on Ubuntu; with no renderer the NIC is never configured, IMDS is never reached, and cloud-init falls back to DataSourceNone dbus systemd only Recommends it and mkosi installs no Recommends, so systemctl could not reach the system bus — and the EKS and ECS bootstraps drive guests with systemctl from user-data lsb-release cloud-init shells out to it; without it every boot reports "degraded" forever and the status stops being a usable signal The kernel also needs console=ttyS0 baked in. The launcher gives every guest a serial port and get-console-output reads it, but a kernel with no console= writes to none of it: the console stopped after the UEFI bootloader and every boot failure was invisible. ttyS0 goes last because Linux makes the final console= the controlling /dev/console. manage_etc_hosts is set because cloud-init renames the guest per launch but at its default never writes a matching hosts entry, so sudo warned on every call. datasource_list is deliberately NOT pinned: the guest identifies the platform from the SMBIOS system UUID the launcher spoofs, ds-identify narrows to Ec2 on its own, and pinning per image is the customisation this migration deletes. Verified on wattle with an A1000 passed through: ssh in as ubuntu with spinifex-key, cloud-id "aws", cloud-init status done (not degraded), no failed units, nvidia-smi reports the A1000 on 595.71.05, docker active, boot 26.7s. * feat(images): let the guest grow its root into the volume it was given mkosi sizes the disk to its content, so the image ships with a root partition that fills the disk to its last sector and ~1.4G free. Nothing in it can expand that: cloud-init's growpart module is enabled, but the growpart binary lives in cloud-guest-utils, which is not installed and is not pulled in as a Recommends by anything in the package set. systemd-repart is not an alternative — Ubuntu's systemd package carries no repart binary, unit or definitions at all. The result was a node handed a larger volume that it could only ever use the first few GiB of, with the rest allocated and unreachable. That is fatal for a worker whose job is to pull container images. gdisk is deliberately left out despite being a cloud-init Recommends: growpart resizes GPT through sfdisk, which arrives via the hard fdisk dependency, and e2fsprogs brings the resize2fs that the resizefs module runs afterwards. Verified on wattle: the gpu-nvidia image launched with a 20G root reports 20G on df -h / (was 4.4G), via "'/' resized: changed (/dev/vda2) from 4770582528 to 20936900096", with nvidia-smi still reporting the A1000 and no failed units. * feat(images): move eks-node-gpu and ecs-agent-gpu onto mkosi profiles Adds the eks-common, eks-agent and ecs profiles, so both GPU node images build from the composed base rather than a hand-authored tree, and the three verbatim copies of install_nvidia_gpu_stack() collapse into gpu-nvidia alone. Splits Docker out of gpu-nvidia into its own profile. Docker belongs to the standalone GPU AMI, whose purpose is `docker run --gpus all`; the EKS and ECS node images run k3s or containerd and reach the GPU through CDI. Fusing the two was fatal for ECS rather than merely wasteful: gpu-nvidia installed containerd.io from Docker's repository, which Conflicts/Replaces the Ubuntu containerd the ecs profile needs, so gpu-nvidia + ecs could not resolve at all. nvidia-container-toolkit stays in gpu-nvidia — every GPU image needs nvidia-ctk to generate its CDI spec. Closes three gaps the pilot left, each of which only shows up on a booted guest: /etc/modules-load.d/nvidia.conf, without which nothing loads the modules on a headless node and CDI generation finds no GPU; mulga-cdi-generate.service, which no profile shipped; and an apt-mark hold on the toolkit packages, which the unattended-upgrades blacklist does not cover for a plain `apt upgrade`. mkosi-build.sh gains --image, naming an output and expanding it to an ordered profile list. The order is load-bearing: mkosi runs each profile's postinst in the order the profiles are passed, so docker's nvidia-ctk wiring must follow gpu-nvidia. Leaving that to callers meant an argument-order mistake produced a healthy-looking image with no GPU wiring, so docker's postinst also fails loudly when gpu-nvidia is selected but nvidia-ctk is absent. Profiles reference build inputs where they already live via ExtraTrees= instead of copying them, keeping one copy of the helpers shared with the Alpine image. Go binaries are built on the host into a staging tree, since the builder container carries no Go on purpose: go.mod is the single pin for the toolchain and a second pin in the Dockerfile could disagree with it silently. * fix(images): install systemd-resolved so the guest has a DNS resolver mkosi installs only the packages named in Packages= plus their hard dependency closure, and systemd-resolved is merely a Recommends of systemd. So it was never installed: the image shipped a 0-byte /etc/resolv.conf that nothing populated, because netplan renders to systemd-networkd and networkd alone does not write resolv.conf. glibc then fell back to localhost and every lookup failed with "[::1]:53 connection refused", which reads as a network fault rather than a missing package. A node that cannot resolve cannot pull a container image. The ECS GPU node booted, registered as a container instance, then failed every task at image pull. The EKS image carries the same defect but is masked by the cloud-init bootcmd in nodegroup_userdata.go that writes resolv.conf at launch; the ECS launch path has no equivalent, so only ECS exposed it. * fix(images): name build output by image and never report a skipped build as success Two defects in the build wrapper that let the wrong bytes reach a boot test. Every composition wrote the same spinifex.raw, taken from the base config's ImageId, so an artefact carried no record of which profiles produced it and an EKS image was distinguishable from an ECS one only by which build ran last. Passing --image-id names the output after the image, and as a side effect the name lands in the guest's /usr/lib/os-release. Publishing correspondingly loses its default input: --name is the published object and --image the local artefact, and with nothing tying the two together a defaulted input meant whatever raw happened to be in the output directory could be uploaded under the name the caller asked for. mkosi also skips the build whenever the output path merely exists. It does not compare inputs, so it never notices an edited mkosi.conf or a restaged binary, prints "Use --force to rebuild" and exits 0 — a stale image indistinguishable from a fresh one. Builds are now always forced, and the run additionally asserts the expected raw was written during this invocation rather than trusting the exit status. The cache worth keeping is the package download volume, which --force does not touch. * feat: add gpu-amd mkosi profile for the ROCm AMI Ports scripts/images/ubuntu-gpu-amd-setup.sh so ubuntu-gpu-amd builds under mkosi as 'gpu-amd docker'. Without it the legacy scripts/images/ tree has to stay alive for one remaining image. Pins the ROCm repo by apt priority rather than only adding it: Ubuntu 26.04 universe ships its own vendored rocminfo, which unpinned apt preferred over AMD's, mixing release trains within one image. Uses a systemd unit for render/video group membership instead of a cloud-init runcmd, because cloud-init's config merge takes a duplicated runcmd key wholesale from one fragment and silently discards the other, which would have dropped the docker profile's own usermod. Runtime GPU verification is deferred — no AMD hardware is available. * feat(images): add eks-server, ec2-node and CPU eks-node/ecs-node mkosi images Ports the K3s server side of EKS off the legacy Alpine/OpenRC builder: nine systemd units, a templated etcd-snapshot service with daily and 15-minute timers, the addon/coredns/konnectivity assets, and the six server binaries. konnectivity-server is not an in-repo package, so it gets a pinned host-side clone-and-build rather than an entry in profile_binaries(). Splits ec2-node out of eks-common. mulga-ebs-byid mints the by-id links for any attached volume and mulga-mgmt-net configures any multi-NIC system VM, so neither belongs behind an EKS profile that a database image would have to compose to reach them. Start-at-boot moves into preset files. mkosi runs preset-all after every postinst, so a postinst enable is discarded before the image is finished, and with no policy file the fallthrough is enable — which built an image that ran a control plane and a worker at once. Installs the cloud-init datasource pin as 99- rather than 90-. cloud-init-base ships its own 90_dpkg.cfg declaring datasource_list, read_conf_d sorts the directory in reverse and the merge keeps the first source, so a 90- prefixed file lost the key silently. The postinst now asserts the merged result. * refactor(eks-node): make the role selector init-agnostic eks-node-role and k3s-first-boot drove OpenRC directly, so on the systemd image the selector enabled nothing and the node never started k3s. Both now dispatch through svc_enable/svc_start/svc_disable on a detected init, with EKS_NODE_INIT overriding detection so either branch is testable on a host that has only one. Detection prefers rc-update over systemctl: the test suite stubs rc-update on PATH, and preferring systemctl would have silently rerouted those cases to a path they were not written for. Enable and start stay two separate passes. The server path starts mulga-eks-k3s-recovery before k3s so a recovery directive applies before the apiserver comes up, and collapsing to systemctl enable --now would interleave them. The dispatch is duplicated in both scripts rather than shared: they are single-file deliverables with no library-path convention between them. Tests cover both branches across all three roles, including that server-join still gets no k3s-first-boot, and that rc-update wins when both inits are present. * fix(eks-node): enqueue role-selected units instead of blocking on them eks-node-role.service declares Before=k3s.service, and mulga-eks-k3s-recovery.service declares After=eks-node-role.service, so a blocking systemctl start deadlocks: systemd will not run the queued job while the selector is still activating, and the selector cannot finish until that job runs. Type=oneshot defaults TimeoutStartSec=infinity, so nothing breaks the tie and the node wedges mid-boot with the role written but no control plane. On a booted guest the selector sat in activating for 261s until the VM was torn down. Start with --no-block on systemd. The ordering the blocking call was implicitly providing is already declared between the units themselves, so systemd sequences them correctly on its own. OpenRC runs the script directly rather than scheduling it, so that branch keeps blocking and keeps surfacing failures through set -e. * fix: escape $ in konnectivity-server ExecStart so server-count survives systemd expands $VAR/${VAR} in Exec*= from the unit's own environment before the command runs, substituting an empty string for a name it does not know. KONN_SERVER_COUNT is not a unit variable — konnectivity-server-prestart writes it to /run/konnectivity-server-args.env, which the wrapper shell sources at runtime — so systemd rewrote the flag to `--server-count=` before /bin/sh saw it. konnectivity-server then died on flag parsing, which is why the unit logged Started and produced nothing despite --logtostderr=true and journal+console, and why the apiserver's cluster egress selector found no UDS for the life of the cluster. This is a port artefact. konnectivity-server.initd is flag-for-flag identical and shares the same prestart script, but under OpenRC the shell was the only thing reading ${KONN_SERVER_COUNT}, so the same text was correct. Escape it as $$ to defer expansion to the wrapper shell, and add lint_unit_expansions() to reject any unescaped $VAR/${VAR} in an Exec*= line of a profile's units. The linter joins line continuations first, since the offending reference sat mid-way through a wrapped multi-line ExecStart, and runs on the host before the container starts so a bad unit fails the build in seconds rather than at first boot. $(cmd) is deliberately not flagged: systemd leaves it literal. Verified on env12 with a rebuilt image: TestEKS/IRSAPod and TestEKS/EBSCSIVolume, which both previously failed on `kubectl exec ... timed out` through the egress tunnel, now pass, with zero UDS connect errors across the run. * fix: refresh the stale qcow2 mkosi-build leaves beside a fresh raw mkosi only emits the raw. A qcow2 next to it came from a previous run's hand conversion, and nothing about its name says which build it belongs to, so it survives a rebuild and silently ships the old image to a node while the raw beside it carries the new one. Observed on a rebuild that left the raw at 15:34 carrying a fix and the qcow2 at 12:45 carrying the pre-fix unit. This is the same failure the existing freshness assertion guards against, one file over, so extend that block rather than add a second check. Refresh rather than delete: the qcow2 is what gets copied to a node and imported, so removing it would push the manual conversion, and this trap, back onto the caller. Convert via a temp name and rename so an interrupted run leaves the old file rather than a half-written one that looks current. * fix: resolve the awsvpc task DHCP client instead of hardcoding udhcpc ecs-agent leases a task ENI's OVN-assigned address inside a per-task netns, which systemd-networkd does not manage, so it shells out to a DHCP client. That call was hardcoded to busybox udhcpc, which Alpine ships and Ubuntu does not. `ip netns exec` exits 1 rather than 127 when it cannot exec the binary, so the failure surfaced as an opaque "network setup failed" with the task stuck in STOPPED, and it took every awsvpc-mode workload with it: TaskAwsvpc and ServiceWithELB both failed on the mkosi image, the latter as runningCount=0 because its target group targets task ENI IPs. Resolve the client at setup time, preferring udhcpc so Alpine behaviour is unchanged and falling back to dhcpcd. Presence of the udhcpc binary is not sufficient to select it: Debian and Ubuntu's busybox ship the applet without /usr/share/udhcpc/default.script, and udhcpc then takes the lease and exits nonzero having configured nothing. Same order and same reasoning as dhcp_oneshot() in mulga-mgmt-net.sh. Both invocations stay one-shot, leaving no daemon behind in the netns. Install dhcpcd-base in base, because neither client was present in any profile. That also repairs mulga-mgmt-net.sh, whose own udhcpc/dhcpcd fallback resolved to nothing on Ubuntu and would have failed the first time a cross-host control-plane data NIC needed it — the S5 path the step-6 plan notes has never been exercised. The DHCP-client choice is injected so the tests assert a named platform's branch rather than whatever happens to be installed on the machine running them; without that the same test exercises different code on an Alpine CI box and an Ubuntu dev box. * refactor: retire the ec2-node profile, fold its helpers into the base image ec2-node carried mulga-ebs-byid and mulga-mgmt-net, and every EKS composition had to remember to list it — eks-common even guarded on its presence and aborted the build without it. ECS did not list it, so the ECS image shipped with no by-id symlinks for hot-attached volumes at all. Neither helper is answerable at build time: any image may later be attached a volume, and any image may later be launched as a control plane. Both are inert when unused (mulga-ebs-byid is udev-driven; mulga-mgmt-net exits 0 when its fw_cfg blob is absent), so the base image is where they belong. That deletes the composition rule, the guard, and the ECS gap in one move. Also drops ec2-node from the two eks image compositions in mkosi-build.sh. Verified on freshly built spinifex-ecs-node and spinifex-eks-node raws: both carry the helpers and the udev rule, mulga-ebs-byid is enabled via multi-user.target.wants and mulga-mgmt-net via cloud-init.target.wants. * fix(eks): force UseMTU=false on netplan units so DHCP renewal can't reinflate the pinned link mulga-vpc-mtu only won the boot race by ordering: netplan renders UseMTU=true (it does not inherit networkd's own false default), so a DHCP lease renewal at T1 could silently re-apply the advertised MTU to the link. usemtu_off() forces UseMTU=false via a runtime drop-in in the systemd-documented [DHCPv4] section for every rendered unit and reloads networkd, removing the dependency on boot ordering entirely. assert_pinned() then verifies the link and its routes actually match before exiting, so any regression is a loud boot-time failure instead of a silent one. Both are no-ops on the Alpine/dhcpcd image, which has no systemd-networkd. * fix(images): state UseMTU=false under both the current section and the legacy alias netplan renders the DHCP settings under [DHCP] while systemd documents [DHCPv4]. A drop-in naming only one parses cleanly and does nothing if the running systemd disagrees, which is the silent no-op the drop-in exists to prevent. * fix(ecs): install iptables on both ecs-node images, cover task-role credential fetch credendpoint.go DNATs the ECS task credential endpoint via iptables; neither the mkosi ecs profile nor the legacy Alpine manifest installed it, so the endpoint silently failed to start and any task with a task role could not fetch credentials while the instance still looked healthy. Also fixes a latent bug in the e2e task-role trust policy (Service-principal-only, which this platform's HTTPS AssumeRole path can never match) and adds a TaskRoleCredentials subtest that fetches real credentials from inside a task container, so a dead endpoint fails the suite instead of passing unnoticed. * fix(images): ship preset files for base, eks-common and ecs start-at-boot mkosi runs systemctl preset-all after every profile's postinst, discarding whatever systemctl enable a postinst performed. eks-server and eks-agent already carry preset files for this reason; base, eks-common and ecs still relied on the default-enable fallthrough, which happens to match today but is one upstream package change from reversing. Adds 10-mulga-base.preset (mulga-ebs-byid, mulga-mgmt-net), 30-mulga-eks-common.preset (mulga-eks-provider-id, mulga-vpc-mtu) and 40-mulga-ecs.preset (containerd, ecs-ca-install, ecs-agent; also disables cni-dhcp.service/socket, which containernetworking-plugins enables by default with nothing to serve under the baked host-local IPAM conflist). Removes the now-redundant systemctl enable calls from each postinst, matching the eks-server/eks-agent precedent. * fix(sts): attribute ecs-tasks.amazonaws.com to container-instance callers The HTTPS AssumeRole path passed an empty principalSource, so matchServicePrincipal denied every Service clause other than the IMDS-only EC2 one. A role carrying the trust policy AWS documents for an ECS task role was unassumable by construction. Service attribution is now derived from the authenticated SigV4 caller: an assumed-role session of the account's ecsInstanceRole — the only credential the in-guest agent holds — is attributed ecs-tasks.amazonaws.com, and only for roles in its own account. Nothing in the request body contributes, so a task holding its own task-role session cannot claim the service principal. * fix(images): remove baked SSH host keys, pin Seed= for reproducibility openssh-server's postinst bakes an identical host key pair into every build, making every guest from one build mutually MITM-able; sshd-keygen already regenerates keys on first boot (ConditionFirstBoot=yes), so the baked pair is pure non-determinism with no purpose. Also pin Seed= so systemd-repart stops assigning fresh partition UUIDs on every build. Verified on a built spinifex-ecs-node image: no ssh_host_* files ship, cloud-init still lists ssh in cloud_init_modules, and sshd-keygen.service is wired via ssh.service.wants/ (redundant regeneration path). A two-build comparison dropped content-differing files from 9 to 1 (only the UKI, whose zstd internals remain sensitive to unrelated input changes). --------- Co-authored-by: tomnewton-mulga <tom.newton@mulgadc.com>	2026-07-30 12:57:43 +10:00
Josh Siviour	d663760dec	feat(eks): control-plane disaster recovery — etcd snapshot + restore-snapshot (#503) ... * fix(eks): write etcd-snapshot.env at CP launch so snapshots actually run * test(eks): cover resolveSystemPredastoreURL and buildEKSServiceDeps Diff-coverage gate for 852f61d9 was unmet (48.8% < 60%) because the mgmt-bridge branches and EKSServiceDeps assembly had no direct test. * feat(eks): restore-snapshot DR path (fresh CP + cluster-reset restore + NLB re-point) * fix(eks): make restore-snapshot fail-safe (validate snapshot, unwind on partial failure, honest status) * fix(eks): sign etcd-snapshot uploads with deployment region (was 403ing) * fix(eks): apply recovery directive on DR-seed first boot + single-node replacement host * fix(daemon): log NATS handler failures at Error (were only on the trace span)	2026-07-10 22:14:58 +10:00
Josh Siviour	e47baf321c	feat(eks): HA control-plane recovery + reconciliation, VM restart hardening, viperblock AEAD pin (#480) ... * feat(eks): reconciler in-place control-plane restart on sustained degradation Phase 1 of EKS CP recovery (siv-243). The ACTIVE-branch reconciler only recorded health; a CP VM that died (OOM/host crash) left the cluster wedged ACTIVE-but-unreachable with no recovery path. Add a CPInstanceControl surface and bounded in-place restart: once an ACTIVE cluster's CP stays unhealthy past a grace window, StartInstance is issued (backoff-spaced, capped) when the instance is stopped/error, re-mounting the same root volume so embedded etcd survives. Degradation stays AWS-faithful ACTIVE + a ClusterHealth issue rather than a non-AWS DEGRADED status enum. cpControl nil keeps the reflect-only path. Wiring of a real CPInstanceControl in the daemon and the error-state manager-eviction fix are the remaining Phase-1 integration steps; Phase 2 (etcd snapshot cadence + restore-snapshot) is tracked separately. * feat(eks): wire control-plane restart into the reconciler via instance service Threads a CPInstanceControl into the per-cluster reconciler (siv-243 Phase 1). cpControlAdapter binds the daemon instance service + account: InstanceState reads the CP's EC2 state via DescribeInstances, StartInstance restarts a stopped CP via StartStoppedInstance, which loads from the shared stopped store and re-mounts the same root volume so embedded etcd survives. Wired as EKSServiceDeps.CPControl = d.instanceService and passed through spawnReconciler. Recovers a cleanly-stopped control plane co-located with the reconciler leader. Remaining: DescribeInstances is node-local so a cross-node stopped CP needs an aggregating describe; and an error/crashed CP (not in the stopped store) needs a dedicated error-state restart path — both tracked as Phase-1 follow-ups. * feat(eks): cross-node CP describe + error-state control-plane restart The reconciler's control-plane recovery was wired to the node-local instance service: DescribeInstances only saw the leader's node and StartStoppedInstance only handled a cleanly-stopped CP from the shared KV. A crashed/OOM CP ends in error state, still resident in its owning node's manager map (not the stopped store), so recovery never reached it — the actual incident in the recovery plan. Wire EKSServiceDeps.CPControl to a NATS-backed eksCPControl. DescribeInstances fans out across every host (gateway scatter-gather) so the reconciler observes a CP on any node. RecoverInstance drives the gateway StartInstances two-step: ec2.cmd.<id> recovers a live error/running owner in place (the owner stays subscribed through the crash; vmMgr.Start relaunches error->pending, re-mounting the etcd root volume), falling back to ec2.start shared-KV rehydration for a stopped CP. The CP VM is ManagedBy=EKS, hidden from customer DescribeInstances; relax that hide so the owning account resolves its own managed CP when targeting it by explicit instance ID (bulk listings still hide it). EC2APIState already maps the internal error state to the AWS closed-enum stopped, which cpRestartable accepts. * fix(eks): reconcile CP as system account, not customer The control-plane VMs are launched under the system account (admin.SystemAccountID()), not the customer account that owns the cluster record. spawnReconciler was binding cpControlAdapter to the customer account, so InstanceState/RecoverInstance ran as the customer — which cannot see or own its own cluster's system-owned CP VMs. DescribeInstances returned zero and the reconciler logged 'control-plane instance not found', never restarting a wedged CP. Bind the adapter to the system account instead. Revert the earlier DescribeInstances managed-VM relaxation: it was based on the mistaken assumption that CP VMs are customer-owned. Visibility is resolved by the system-account adapter, so the explicit-ID escape hatch is dead code. * fix(vm): pre-create mgmt tap on disk-boot restart path The direct-boot branch pre-creates the management tap via NetworkPlumber.SetupTap (owned by the daemon euid), but the disk-boot/else branch only appended the QEMU tap,id=mgmt0 device without creating the tap. The daemon runs as a non-root user without CAP_NET_ADMIN, so QEMU can only attach a tap it already owns; on the disk-boot path QEMU tried to create /dev/net/tun itself and failed with 'Operation not permitted', failing every stopped-instance restart (StartInstances returned ServerInternal). This blocked EKS control-plane recovery: the reconciler found the stopped CP and issued the restart, but the VM never booted. Call SetupTap for the mgmt tap in the disk-boot branch, mirroring direct-boot. * feat(eks): recover all HA control-plane members, not just primary The reconciler restarted only ControlPlaneInstanceID (the primary CP member), so on an HA cluster the other server VMs stayed stopped and etcd never regained quorum (1/3) — apiserver healthz stayed fail even after recovery ran. maybeRecoverControlPlane now iterates every member in ControlPlaneNodes (falling back to the scalar ID for single-node clusters), restarting each stopped/error member per pass while preserving the grace window, attempt cap, and backoff gates. Refs mulga-siv-509 * fix(eks): keep cloud-init polling IMDS so primary CP gets its user-data The eks-node system VM's user-data is delivered only via IMDS (the NoCloud seed was retired in #411). IMDS (169.254.169.254) is reachable only once mulga-mgmt-net brings up the data NIC via DHCP and the per-tap br-imds datapath reconciles, which on the first-launched (primary) CP can lag cloud-init's stock 120s probe window. With the default max_wait cloud-init falls back to DataSourceNone, permanently losing the launch user-data (no SPINIFEX_K3S_ROLE -> no k3s server) and wedging the cluster in CREATING. Bake a cloud.cfg.d drop-in that pins DataSourceEc2 and raises max_wait to 600s so cloud-init keeps polling until the datapath is ready instead of falling through to None. Worst case a slow boot, never a lost role. * fix(eks): warm IMDS instance-role creds before first SigV4 sign On IMDS-credentials mode the on-VM SigV4 helpers (eks-token-webhook, eks-gateway-publish, mulga-eks-state-report) sign via the SDK default chain, which resolves in-VM IMDS instance-role creds. The per-tap br-imds datapath lags VM boot by minutes (observed ~264s), and the SDK's IMDS client fast-fails each probe (250ms dial), so early Retrieve calls return 'context deadline exceeded' / 'no EC2 IMDS role found'. eks-gateway-publish only retries for 30x5s=150s, shorter than the datapath warm time, so it exhausts its budget and drops the bootstrap/state publish -> cluster hangs in CREATING. The credential chain is sound (the CP role trusts ec2.amazonaws.com and AssumeRoleForInstance evaluates that principal); the failure is timing. Add gwsign.Signer.EnsureCredentials and block in eksgw.New until the instance-role creds first retrieve (2s interval, 10m ceiling aligned with cloud-init max_wait), so every helper's first signed request already holds creds instead of racing a cold datapath. Static-key mode is unaffected. * fix(eks): retry CP data-NIC DHCP until cross-host datapath is up A single ~16s DHCP one-shot on the primary data NIC lost the race against the cross-host OVN datapath (logical-port binding + per-tap reconcile on the remote placement host), stranding the NIC IP-less so the Ec2 datasource never reached IMDS and the CP member wedged. Add dhcp_acquire: retry the one-shot on a budget aligned with cloud-init's Ec2 max_wait (600s), confirming an inet address before success. Each attempt still exits leaving no daemon, so cloud-init's later ENI management is unaffected. * fix(eks): drop reconciler registry entry when Run self-exits ReconcilerRegistry.Spawn only cleaned up its holder on ctx cancel (Stop/StopAll). When a ClusterReconciler's Run returned on its own — a terminal cluster state or a lost lease — nothing cancelled the ctx, so the holder leaked and a later same-name create silently no-opped at the head of Spawn, never reconciling to ACTIVE. Thread a finished channel from RunClusterReconciler's Run goroutine back to Spawn's watcher, which now cleans up on whichever fires first: an external cancel or Run exiting. On self-exit it deletes its own holder and releases the lease, so a fresh same-name create re-spawns and reconciles. * fix(eks): run mulga-mgmt-net in boot runlevel before cloud-init-local CP user-data is delivered only via IMDS since the NoCloud seed was retired (#411), so cloud-init DataSourceEc2 must reach 169.254.169.254. mulga-mgmt-net DHCPs the data NIC that makes IMDS reachable, but it was added to the default runlevel and only declared `before cloud-init` (the network-stage service). cloud-init-local therefore ran its init-local Ec2 crawl first with no data-NIC route and burned its whole probe window (~4 min) before mulga-mgmt-net brought eth0 up, regressing CP bringup from ~1m50s to ~5m54s. Add mulga-mgmt-net to the boot runlevel in setup.sh instead of default, drop it from ENABLE_SERVICES, and order it `before cloud-init-local` so the data NIC and IMDS route are up before the init-local crawl. Keeps the IMDS-only user-data path; the raised Ec2 max_wait stays as a safety net for host br-imds datapath lag. * fix(vm): refresh LaunchTime on crash-restart so watchdog spares relaunch RestartCrashedInstance re-launched a crashed VM without refreshing Instance.LaunchTime. The pending watchdog measures now-LaunchTime against PendingWatchdogTimeout, so the stale original launch time tripped launch_timeout on the next tick and terminated the crash-restart mid-flight. Refresh LaunchTime under the state lock, mirroring the daemon-restart restore path (restore.go), so the relaunch gets a fresh timeout window. Adds a regression test asserting LaunchTime advances. * feat(eks): reconcile control-plane member count after a lost member The cluster reconciler self-heals a stopped/error control-plane VM in place but never replaced a terminated/gone member, so an HA cluster ran below haControlPlaneCount permanently. Add a member-count reconcile pass that provisions one replacement CP joining the surviving etcd quorum. - CPProvisioner + EKSServiceImpl.ProvisionReplacementCP: replay the persisted create template on a free host, the single-node analogue of the spread join branch, with rotating creds re-derived. - ControlPlaneTemplate persisted on ClusterMeta at create (per-node and rotating-cred fields cleared). SwapControlPlaneMember CAS swaps the dead node for the replacement and refreshes the [0] scalar mirrors. - maybeReplaceControlPlaneMember fires only when no member is restartable and one is truly lost, a healthy majority survives, bounded by grace, backoff and an attempt cap; placement excludes live-member hosts. - Replacement prunes the superseded member from etcd once joined: k3s-first-boot deletes the stale Node (EKS_ETCD_PRUNE_PEER_IP) so quorum width returns to N. json tags added to K3sServerInput (now persisted). * feat(eks): in-guest control-plane self-diagnosis on healthz fail When a control-plane apiserver reports unhealthy, the reconciler only saw healthz=fail with no cause, and the guest has no on-demand command channel (serial root login is password-gated, no guest agent). Make the CP self-diagnose and relay the cause through the one-way state report. - mulga-eks-state-report.sh: diagnose() collects failing /readyz?verbose subchecks, isolated /healthz/etcd reachability, and etcd-db-dir free space; on fail write a verbose block to the host-captured serial console and add a JSON-safe reason to the state payload. - ServerStateReport: add Reason (omitempty; empty from a healthy CP or an older AMI predating the field). - cluster_reconciler observe(): surface the reason in the health issue. - Tests: POSIX unit test for the agent (stubbed kubectl/df); Go tests for the reason-bearing and terse health-issue paths. * feat(eks): 15-min etcd snapshot cadence alongside nightly Nightly alone is too coarse a recovery point for a young cluster. Install the same mulga-eks-etcd-snapshot script into a second Alpine crond periodic dir (/etc/periodic/15min) so it also runs on a ~15-minute RPO window; the script picks its cadence tier from the dir it is invoked from ($0 sniff) and encodes the tier in the snapshot key (etcd-{tier}-{ts}.snap), so a predastore S3 lifecycle rule can retain the frequent rolling window shallow and the nightly copies deep. Server-role only (agents exit early); no restore-path change. Add a self-contained POSIX unit test (stub k3s/curl/logger, symlinked crond dirs to exercise the real $0 tier sniff) covering agent no-op, frequent + daily key prefixes, local-snapshot prune, and quiet no-op without creds. * feat(eks): auto-reform wedged etcd quorum via boot-time cluster-reset An HA k3s control plane does not self-heal after a simultaneous full-CP restart: embedded etcd never reforms quorum (etcd:unreachable sustained), and in-place VM restarts cannot fix it. Add a last-resort escalation that drives the documented k3s cluster-reset recovery, pull-based so the host never needs an inbound channel into the guest. Reconciler: maybeReformEtcdQuorum escalates only when every CP member is VM-running but the health issue carries etcd:unreachable, the cluster is HA, and a grace window has elapsed. It sets per-member recovery directives (seed = cluster-reset, others = wipe-rejoin), epoch-bumped and keyed by instance ID, then restarts the members. Bounded by grace/backoff/attempts; a recovered cluster clears the directives once. Enabled via WithEtcdResetRecovery alongside the existing CP control wiring. Directive plane: per-member KV directive {epoch, action, snapshot} with store helpers, an EKS service Get/Set pair over NATS-RPC, and an internal-recovery gateway route (system-cred carve-out, same as internal-addons). The CP server instance role gains eks:GetRecoveryDirective. Guest: mulga-eks-k3s-recovery is a pre-k3s oneshot (server role only) that fetches its directive through the AWS gateway (eks-gateway-fetch -resource recovery), epoch-guards one-shot application, then runs `k3s server --cluster-reset` (optionally restoring a predastore snapshot) or wipes the local etcd datastore to rejoin the reset seed. Wired into the image manifest, setup.sh perms, and the eks-node-role selector. Tests: reconciler escalation gates + recovery clear, directive store epoch increment + service validation, and a POSIX unit test for the guest agent. * fix(eks): reboot running CP members to apply etcd cluster-reset directive The etcd quorum-reformation escalation drove StartInstance on the seed and followers, but the reset gate only fires when every member is VM-running. The StartInstances path rejects a running instance with IncorrectInstanceState, so the guest never re-entered its boot sequence and the cluster-reset/wipe-rejoin directive was never applied — the wedged control plane stayed wedged. Reboot the running members (QMP system_reset) instead, re-entering the boot sequence so the on-VM recovery agent applies the directive. Adds RebootInstance to the CP control surface (interface, adapter, NATS-backed daemon impl) and switches maybeReformEtcdQuorum to it; the stopped/error in-place restart path keeps StartInstance. * fix(eks): graceful stop for etcd reset recovery The etcd quorum-reformation reset path forced running CP members through a hard QMP system_reset to re-enter the boot sequence and apply their recovery directives. A hard reset skips a clean unmount: on the next boot e2fsck cleared the recovery and k3s runlevel entries (dangling inodes), so the cluster-reset never ran and k3s was unstartable — the reset defeated recovery. Replace the reboot with a graceful StopInstance (QMP system_powerdown, clean unmount, SIGKILL fallback). The existing in-place restart path (maybeRecoverControlPlane) then boots each stopped member clean on a later tick, and the on-VM recovery agent applies its directive against an intact filesystem. Reuses existing lifecycle machinery; the stop also tolerates a wedged QMP client via the SIGKILL fallback. Swaps RebootInstance -> StopInstance across CPInstanceControl, cpInstanceController, the cpControlAdapter, and the NATS-backed eksCPControl (gateway RebootInstances -> StopInstances), plus the reset/recovery test fakes. * fix(vm): retry QMP dial and unlink stale socket on relaunch A QEMU killed with SIGKILL (crash or etcd-reset restart) leaves its qmp-<id>.sock inode behind. On relaunch the startup os.Stat probe and the QMP dial both raced that dead listener, so a single dial returned 'connection refused': StartStoppedInstance then reported ServerInternal and left the instance KV-stopped even though the guest booted fully. The wedged member stayed invisible to the reconciler's cpLive gate, stalling recovery. Unlink the stale socket before launch so the inode that appears is the fresh QEMU's, and retry the QMP connect with a short backoff to cover the window where the socket is bound but not yet listening. Handshake failures are not retried — a listener answered, so the error surfaces immediately. * feat(eks-ui): surface cluster Health.Issues on the EKS console DescribeCluster is AWS-faithful (Status stays ACTIVE, degradation lives in Health.Issues), but the cluster detail page only rendered the status badge, so a degraded control plane still showed as ACTIVE with no visible signal. Add a destructive health badge next to the status and a Health row that lists the issue messages, mirroring the addons tab. Healthy clusters read OK. * chore: rebuild ui * fix(viperblockd): stop mount-path daemon VB uploader to prevent checkpoint clobber The daemon-side VB created in the ebs.mount handler is stored in MountedVolume.VB for the whole mount, and its background chunk uploader was only stopped at daemon shutdown. That state-only VB ran DrainToBackend every 30s, overwriting the live checkpoint the nbdkit plugin VB (the data-path writer) keeps updating, leaving SeqNums inconsistent with sealed chunk ciphertext and causing transient AEAD auth failures on cloned encrypted volumes. Stop its uploader right after New, matching the other short-lived VB call sites. Also bump viperblock to the atomic chunk-ObjectID allocation fix. * build(deps): pin viperblock to landed AEAD concurrency fix Bump github.com/mulgadc/viperblock to the dev commit b08bea6 that eliminates "cipher: message authentication failed" on encrypted volumes under concurrent read-modify-write + background chunk drain. Removes the local-path replace used while the fix was in flight.	2026-07-09 09:43:32 +10:00
Josh Siviour	7bbd99c792	feat(eks): multinode control-plane + IMDS/token-webhook CP fixes (426/427/428/495/496) (#459) ... * feat(eks): multinode control-plane networking, IAM, and CoreDNS parity Integrates the EKS multinode fix set for the managed-control-plane topology so a 3-worker cluster brings up ingress/ALB and cross-node DNS the way AWS EKS does. Squashed from feat/eks-workload-lifecycle, rebased onto dev; the node-IAM piece (4f6ea8cf) is dropped as dev's lazy IAMProvider supersedes it. EKS: - Route apiserver egress (exec/logs/webhooks) through konnectivity (apiserver-network-proxy): CP servers run konnectivity-server behind the cluster NLB (:8132), workers run konnectivity-agent, so apiserver->pod traffic rides the agent-initiated reverse tunnel instead of an unroutable CP->VPC path. Server-count fan-out gives every apiserver a tunnel to every replica (HA-correct). - Pin k3s node-ip to the CP-VPC primary on overlay re-home; CP-overlay flannel mesh SG rule authorized at cluster launch with ordered teardown. - Pin VPC data NIC MTU to 1320 so flannel fits the OVN underlay. - Pin the CoreDNS DaemonSet to workers (drop CriticalAddonsOnly + CP/master tolerations, add anti-control-plane nodeAffinity) for AWS-EKS parity. - Spread nodegroup workers across hosts; addon readiness falls back on workload rollout when gvks are absent. - elbv2: allow the proxy_protocol_v2.enabled target-group attribute. EBS: - Move volume attachment state to state.json so a live nbdkit VB cannot clobber it; route mounted-volume state updates through the live VB with a retry for in-use marks racing the mount responder; keep the boot volume in-use across stop/crash unmount. * fix(eks): gate orchestration on the resolved IAM ensurer, not raw deps.IAM missingOrchestrationDeps gated on s.deps.IAM, but production wires only the lazy deps.IAMProvider and leaves deps.IAM nil (set directly by tests only). The gate therefore reported missing=[IAM] on every node forever, so CreateCluster/CreateNodegroup were rejected with ServiceUnavailable even though the IAM service was fully up via the provider. Gate on s.iamEnsurer() instead — the same resolver (deps.IAM, else deps.IAMProvider()) the nodegroup/role code already uses — so the protective check still rejects a node with no IAM service but passes when the provider supplies one. Add a regression test that sets only IAMProvider and asserts the gate is satisfied; the existing nil-both test still rejects. * fix(eks): let eks-token-webhook use IMDS creds when static keys absent The CP VM launches on an instance profile, so buildK3sUserData omits EKS_ACCESS_KEY/EKS_SECRET_KEY. loadConfig() rejected absent static keys before eksgw.New could fall back to the IMDS SDK chain, so the webhook aborted on boot, never wrote token-webhook.kubeconfig, and the apiserver crashed on the missing --authentication-token-webhook-config-file file, stalling the cluster at CREATING until it timed out to FAILED. Drop the static-key precondition (matching the sibling eks-gateway-publish and eks-gateway-fetch helpers); keep the genuinely-required gateway/account/ cluster gates. * fix(eks): stop dhcpcd IPv4LL hijacking IMDS on multi-NIC control plane The K3s control-plane system VM is dual-NIC (data ENI + mgmt NIC on br-mgmt, which has no DHCP server). dhcpcd's no-lease IPv4LL fallback assigned a 169.254.x.x address and a 169.254.0.0/16 route on the mgmt NIC, capturing 169.254.169.254 and steering IMDS off the data NIC away from the per-tap br-imds datapath, where the host RST it. eks-gateway-publish then failed to sign requests and no bootstrap artifacts were ever published, so clusters sat CREATING until they timed out to FAILED. Bake noipv4ll into /etc/dhcpcd.conf so dhcpcd never assigns an IPv4LL address or /16 route on a NIC that fails DHCP; real DHCP leases (workers, data ENI) are unaffected and IMDS falls through the data NIC's default route to the br-imds demux, matching the single-NIC path. Defense in depth: mulga-mgmt-net deletes any default route on a NIC declared NIC<n>_DEFAULT=0. * fix(eks): grant eks:WebhookTokenReview to the control-plane instance role The eks-token-webhook relays `aws eks get-token` bearer tokens to the gateway broker at POST /clusters/{name}/token-review, signing with the control-plane VM's IMDS instance-role creds (spinifex-eks-server). That route authorizes against eks:WebhookTokenReview, but the role's inline policy granted only eks:PublishInternal and eks:ListInternalAddons, so the gateway 403'd every relay and the apiserver returned 401 to all external kubectl. Add eks:WebhookTokenReview to eksServerInlinePolicy. EnsureSystemInstanceProfile re-asserts the inline policy on every control-plane instance-profile ensure, and the gateway evaluates authorization per request, so existing clusters converge without a rebuild once the shared role is updated.	2026-07-09 09:43:30 +10:00
Josh Siviour	74b91b5cc5	feat(eks): HA control plane — 3-node etcd quorum spread across distinct hosts (#335) ... * feat(eks): node-targetable control-plane VM (HA spread transport prereq) Groundwork for HA control-plane placement (mulga-siv-231.7.1): make the k3s control-plane VM placeable on a specific Spinifex host. - Add a sys.medium instance type (2 vCPU / 4 GB) and boot the control-plane VM as it instead of t3.medium. A sys.* type keeps the CP VM out of customer DescribeInstanceTypes and makes the daemon register the node-targeted system.LaunchInstance.{type}.{nodeID} subject (only sys.* types get it). - Add K3sServerInput.TargetNodeID and a LaunchSystemInstanceOnNode method on the launcher: empty/local node launches in-process (unchanged single-CP path); any other node dispatches over the node-targeted subject, where the receiving daemon runs the launch and owns the VM. The spread orchestrator (reserve N hosts, launch per host, verify, rollback, <3-host fallback) lands separately; CreateCluster still launches locally (TargetNodeID empty), so behaviour is unchanged. * feat(eks): HA control-plane spread orchestrator Place N=3 k3s server VMs across distinct Spinifex hosts via a per-cluster spread placement group, with all-or-nothing rollback and single-CP fallback. - placeControlPlane: capacity fan-out (HostScheduler) -> >=3-host gate -> ensure spread group (system account) -> ReserveSpreadNodes(Min=Max=3) -> parallel per-node LaunchK3sServerVM(TargetNodeID) -> node-vms placement verify -> FinalizeSpreadInstances. Any launch/verify/finalize failure terminates launched VMs, releases the reservation, drops the group. - <3 schedulable hosts or a lost reservation race falls back to a single local control-plane VM (prior behaviour). - ClusterMeta gains ControlPlaneNodes[] + ControlPlaneSpreadGroup; [0] is mirrored into the scalar ControlPlane* fields for back-compat. DeleteCluster tears down every CP VM and the spread group. - Wire PlacementGroup + Scheduler into EKSServiceDeps + orchestration-deps gate. * fix(eks): size HA control-plane spread on raw host headroom SchedulableHosts matched the CP type by name in node.status's per-type capacity list, but that list omits sys.* types (system types are hidden from customers). The CP VM is sys.medium, so the match never hit and SchedulableHosts returned 0 on every node — placeControlPlane always fell back to a single CP, making the >=3-host spread unreachable in production. System VMs consume host vCPU/memory like any guest, so size the fit against each node's raw schedulable headroom (Total - Reserved - Alloc) and the type's footprint instead. Adds instancetypes.SpecForSystemType for the sys.* vCPU/memory spec and a pure nodeFitsSystemInstance helper. * feat(eks): k3s server-join role for HA control-plane quorum Servers 2..N now boot in join mode: server: https://<first-server>:6443 + a shared cluster token, without cluster-init, so they join the first server's embedded-etcd quorum instead of each cluster-initing an independent datastore. - K3sServerInput gains JoinToken (shared cluster secret, set on every server) and ServerURL (set => join server, no cluster-init, server-join role). - buildK3sUserData branches cluster-init vs server:, emits token:, and selects SPINIFEX_K3S_ROLE server vs server-join. - launchControlPlaneSpread launches nodes[0] first (cluster-init), derives the join URL from its ENI IP, then launches the rest in parallel as join servers; a first-server failure skips the joins and rolls back. - CreateCluster mints a per-cluster crypto-random token (GenerateK3sClusterToken) threaded into the placement template. - eks-node-role.sh adds a server-join case: token-webhook + k3s + state-report, but not k3s-first-boot (the first server already publishes the bootstrap artifacts; a join re-publish only races the bootstrap bus). * fix: open etcd-peer/kubelet ingress on EKS control-plane SG for HA join Join servers (231.7.2) register over the supervisor port 6443 but their embedded etcd could not peer with the quorum: the control-plane SG only admitted 6443 from the VPC CIDR, omitting etcd client+peer 2379-2380 and kubelet 10250 between control-plane nodes. A single cluster-init server never exercises those ports, so the gap stayed hidden until multi-server HA — the join registered but its etcd never replicated the raft log, leaving the node perpetually NotReady. Add EnsureControlPlaneHAIngress with self-referencing (cpSG->cpSG) rules for etcd 2379-2380 and kubelet 10250, called from CreateCluster after EnsureControlPlaneIngress. Verified live on a 3-node cluster: join servers reach Ready and form a 3-member etcd quorum that survives loss of the original first server. * feat: register all control-plane ENI IPs as EKS cluster NLB targets Register every HA control-plane server ENI IP in the cluster NLB target group, not just the primary. The TG already health-checks :6443, so a dead member drains and kubectl/apiserver traffic fails over to surviving etcd-quorum members. Add RegisterClusterTargets batch helper; the single RegisterClusterTarget now delegates to it.	2026-06-10 12:25:47 +10:00
Josh Siviour	f14fb64562	feat(eks): unify eks-server + eks-agent into one eks-node AMI (#288) ... * feat(eks): unify eks-server + eks-agent into one eks-node AMI Collapse the two K3s AMIs into a single spinifex-eks-node image whose role (server vs agent) is chosen per-instance at first boot, halving build time, storage, and CVE-rotation surface. - scripts/images/eks-node/: superset manifest + merged setup.sh; all role services baked but only crond + the new eks-node-role selector enabled. - eks-node-role first-boot selector reads SPINIFEX_K3S_ROLE, rc-update adds + starts the matching services (server: k3s + eks-token-webhook + k3s-first-boot publisher; agent: k3s-agent), records /etc/spinifex-eks/role, self-disables. Paths are env-overridable; eks-node-role_test.sh covers all five cases. - mulga-eks-etcd-snapshot.sh early-exits on agent nodes. - k3s_server_vm.go seeds SPINIFEX_K3S_ROLE=server into first-boot.env. - Makefile/dev-install: build-eks-node-image / import-eks-node-image replace the server+agent targets. - Delete scripts/images/eks-server + eks-agent. The launcher resolves the AMI by the spinifex:managed-by=eks tag, so running clusters (which hold the resolved AMI ID) are unaffected. AMI bake + cluster boot are operational integration steps, not yet run. * fix(eks): order eks-node-role after cloud-config/cloud-final The first-boot role selector reads /etc/spinifex-eks/first-boot.env, which cloud-init delivers via write_files in the cloud-config/cloud-final stages. The selector only depended on net+cgroups, so on a fast boot it could start before write_files landed and read a missing role env. Add an after-ordering on cloud-config + cloud-final so the env file is always present first.	2026-06-04 12:28:56 +10:00