# maas-vm-host: registers the vcloud host's libvirt/virsh connection with
# MAAS as a VM host (D-103: "OpenTofu registers each DC's libvirt host to
# that DC's MAAS rack controller as a virsh VM-host, so MAAS DISCOVERS the
# OpenTofu-created node VMs").
#
# D-123 MODEL B (2026-07-16): "the vcloud host's libvirt" above is SUPERSEDED for the DCs --
# under Model B the node VMs live INSIDE vvr1-dc0, so the vm-host to register is vvr1-dc0's OWN
# (INNER) virsh -- power_address = qemu:///system LOCAL to the rack (vvr1-dc0 is BOTH the MAAS
# rack AND the libvirt host, so no cross-fiber virsh dial). Still DEFERRED (DOCFIX-179: a maas
# provider block forces every plan to demand creds); wire in its own gated step after the region
# + inner nodes exist, registering to the Office1 REGION.
#
# REFUTED FOR DC USE BY MEASUREMENT (2026-07-20 step D; D-103/D-123 amendments of that date are
# the authority): snap MAAS cannot open the local libvirt socket (confinement, no libvirt snap
# interface), and a qemu+ssh pod fails on `domblkinfo ... missing storage backend for 'volume'`
# (virsh pods cannot read node-vm's pool+volume disk refs). Discovery -- this module's whole D-103
# job -- is delivered by PXE enlistment instead, and power is RULED per-machine
# (`power_type=virsh` via scripts/maas-node-power.sh; the Roosevelt per-node-BMC shape). Do NOT
# wire this module for a DC. Retained pending the stage-close retire-or-keep ruling (SEC-013).
#
# DELIBERATELY uses `maas_vm_host`, NOT `maas_vm_host_machine` -- confirmed
# by reading both resources' real schemas (canonical/terraform-provider-maas,
# fetched 2026-07-09): `maas_vm_host_machine` takes `cores`/`memory`/
# `storage_disks`/`network_interfaces` as INPUT arguments, i.e. it tells MAAS
# to COMPOSE (allocate + create) a brand-new VM from the host's resource
# pool -- MAAS's own "Compose machine" pod feature. D-103 explicitly rules
# this out: "MAAS owns commission / deploy / power / release of those node
# VMs; it does NOT compose new ones." `modules/node-vm` already pre-creates
# the VMs OpenTofu's own way; registering the host via `maas_vm_host` alone
# is what makes MAAS's chassis-discovery process find and enlist those
# already-existing domains, matching the D-103 flow exactly. Do not add a
# `maas_vm_host_machine` call here -- it would fight node-vm for VM creation.
#
# Requires a `provider "maas" {}` block in the ROOT module (api_url/api_key
# -- see opentofu/README.md); this module itself declares no provider block,
# matching the convention every other module in this repo already follows.

resource "maas_vm_host" "dc" {
  type          = "virsh"
  name          = var.vm_host_name
  power_address = var.power_address
  zone          = var.zone
  pool          = var.pool
}
