# =====================================================================
# vr1-dc0 MAAS registration root (Model B step D / runbook Step 9).
#
# WHY A THIRD ROOT, rather than adding `provider "maas"` to an existing one:
# DOCFIX-179 removed the maas provider block from the OUTER root after measuring
# that its mere PRESENCE forces every `tofu plan` to demand maas_api_url AND the
# SENSITIVE maas_api_key -- even for a plan that creates zero MAAS resources,
# which would bake a fake key into plan/state (the DOCFIX-175 plaintext-secret
# surface). That lesson applies verbatim to the INNER substrate root: coupling
# routine substrate plans to MAAS credential availability would be repeating the
# defect the repo already paid to learn. So MAAS registration gets its own small
# root with its own state, and the substrate roots stay credential-free.
#
# WHAT IT DOES: registers the DC's inner libvirt as a MAAS VM host (pod) so MAAS
# DISCOVERS the already-existing, OpenTofu-created node VMs. It deliberately does
# NOT compose machines -- see modules/maas-vm-host's header for the
# maas_vm_host vs maas_vm_host_machine reasoning (D-103).
#
# WHERE IT RUNS: from the Office1 headend (voffice1), the D-128 Plane-2 host --
# same place the inner substrate root runs.
#
# SECRET HANDLING: maas_api_key comes ONLY from TF_VAR_maas_api_key in the
# environment, read from the operator-placed 0600 file. It is never written to a
# tfvars file. NOTE: it DOES land in this root's terraform.tfstate (unavoidable
# with this provider), so that state file inherits the same handling as any
# credential-bearing artifact -- 0600, on voffice1, never committed.
# =====================================================================

provider "maas" {
  api_url = var.maas_api_url
  api_key = var.maas_api_key
}

module "vr1_dc0_vm_host" {
  source        = "../modules/maas-vm-host"
  vm_host_name  = var.vm_host_name
  power_address = var.power_address
  zone          = var.zone
  pool          = var.pool
}

output "vm_host_id" {
  description = "MAAS id of the registered VM host -- the handle for a later teardown."
  value       = module.vr1_dc0_vm_host.id
}

# MAAS's OWN view of the host's capacity. Not inputs -- a post-registration
# cross-check against the D-121/D-123 sizing math (vvr1-dc0 = 108 vCPU / 416 GiB):
# if MAAS reports something else, the nesting or the sizing is not what we think.
output "maas_reported_cores" {
  value = module.vr1_dc0_vm_host.resources_cores_total
}

output "maas_reported_memory" {
  value = module.vr1_dc0_vm_host.resources_memory_total
}