# 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").
#
# 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
}