ilkermanap
3d4841f31c
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>
45 lines
1.7 KiB
Desktop File
45 lines
1.7 KiB
Desktop File
[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
|