Initial commit: MAAS-deployable Proxmox VE images with cluster automation

Builds a Proxmox VE image that MAAS can deploy to bare metal, plus first-boot
automation that configures the node and joins it to a Proxmox cluster with no
manual steps.

The image starts from the official Debian cloud image and installs proxmox-ve
on top of it, rather than capturing a raw disk from the Proxmox ISO. That keeps
MAAS in control of partitioning, networking, SSH keys and cloud-init, and makes
moving between Proxmox releases a variable change instead of a rewrite.

Contents:

  * Makefile driving the whole flow: build, verify, preseed, upload
  * customize-proxmox.sh, run inside the Packer build VM, which layers Proxmox
    onto the Debian cloud image and resets the pmxcfs node identity so one image
    can produce many nodes
  * pve-maas-init, a first-boot state machine covering /etc/hosts, node-unique
    identifiers, the root password, vmbr0 conversion, cluster create/join and
    the local-lvm thin pool; each stage is resumable across reboots
  * curtin-hooks, which stops curtin installing a kernel over APT and pins
    interface names by MAC so they match what MAAS recorded at commissioning
  * a MAAS curtin preseed template and cloud-init examples
  * deploy-cluster.sh, which builds a whole cluster through the MAAS API
  * verify-image.sh, 22 static checks on the produced tarball

Cluster identity lives entirely in deploy-time cloud-init user-data, so a single
image and preseed can build any number of independent clusters.

Verified end to end against MAAS 3.7.2: proxmox-ve 9.2.0 / pve-manager 9.2.11 /
kernel 7.0.14-15-pve, deployed to two machines that formed a quorate cluster with
local-lvm on both, with no manual intervention.

The README documents four failure modes found along the way that all fail
silently: curtin rejecting "kernel: null", pvenetcommit overwriting the network
configuration at boot, interface renaming leaving the link down, and a systemd
ordering cycle that made systemd delete the service's start job.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

overlay/etc/systemd/system/pve-maas-init.service

@@ -0,0 +1,44 @@
+[Unit]
+Description=Proxmox VE post-deployment configuration for MAAS
+Documentation=file:/etc/pve-maas/pve-maas.conf
+After=network-online.target
+Wants=network-online.target
+ConditionPathExists=!/var/lib/pve-maas/complete
+
+# DIKKAT - burada cloud-init servislerine "After=" YAZMAYIN.
+#
+# After=cloud-final.service + WantedBy=multi-user.target birlesimi bu imajda
+# siralama dongusu olusturuyor ve systemd dongoyu kirmak icin BU servisin
+# baslatma isini siliyor:
+#
+#   multi-user.target: Found ordering cycle on pve-maas-init.service/start
+#   multi-user.target: Found dependency on cloud-final.service/start
+#   multi-user.target: Found dependency on multi-user.target/start
+#   Job pve-maas-init.service/start deleted to break ordering cycle
+#
+# Bunun yerine script kendi icinde "cloud-init status --wait" ile bekliyor;
+# boylece hem conf.d dosyalari yazilmis oluyor hem de MAAS deploy sinyalini
+# almis oluyor, systemd bagimlilik grafigine dokunmadan.
+
+[Service]
+# Type=simple (oneshot DEGIL) - bu onemli.
+#
+# Type=oneshot ile servis bitene kadar multi-user.target ulasilmis sayilmiyor.
+# cloud-final.service ise "After=multi-user.target" ile siralanmis. Script
+# icinde cloud-init'i bekledigimiz icin bu bir kilitlenme uretiyordu:
+#
+#   cloud-final.service    waiting      (multi-user.target bekliyor)
+#   pve-maas-init.service  running      (cloud-init bekliyor)
+#   multi-user.target      waiting      (pve-maas-init bekliyor)
+#
+# Type=simple ile servis hemen "basladi" sayilir, multi-user.target acilir,
+# cloud-final calisir ve beklememiz doner. Asama takibi zaten
+# /var/lib/pve-maas/*.done dosyalariyla yapiliyor.
+Type=simple
+ExecStart=/usr/local/sbin/pve-maas-init
+TimeoutStartSec=0
+StandardOutput=journal+console
+StandardError=journal+console
+
+[Install]
+WantedBy=multi-user.target