variable "vm_name" {
  description = "Domain name, e.g. \"office1-opnsense\", \"dc1-opnsense\"."
  type        = string
}

variable "memory_mib" {
  description = "Memory in MiB. No default -- pass explicitly (OPNsense sizing hasn't been decided; check OPNsense's own hardware-sizing guidance for the expected role before picking a value)."
  type        = number
}

variable "vcpu" {
  description = "Virtual CPU count. No default -- pass explicitly."
  type        = number
}

variable "pool_name" {
  description = "libvirt_pool this VM's disk + config-seed volume live in."
  type        = string
}

# NOTE: there is deliberately NO `disk_size_bytes` here. It was REMOVED 2026-07-12
# (DOCFIX-189) because it was DEAD: once the disk became a direct copy of the prepped
# nano (DOCFIX-187), nothing consumed it, so `disk_size_bytes = 16 GiB` was silently
# ignored and the edge got the base image's 11 GiB instead. An unused variable is legal
# HCL, so neither `tofu validate` nor the plan flagged the lie.
# Disk size is owned by scripts/opnsense-prep-image.sh's GROW arg. Do not re-add a sizing
# input here unless the module actually consumes it.

variable "base_volume_path" {
  description = <<-EOT
    Host filesystem path of the PREPARED (decompressed, qcow2-converted,
    resized) OPNsense nano image -- the output of
    `scripts/opnsense-prep-image.sh`, typically fed through a
    `modules/base-image` call (pass that module's `path` output here; the
    same real-attribute-reference pattern modules/cloudinit-vm uses). Do NOT
    point this at the raw downloaded .img.bz2 -- libvirt_volume's
    create.content.url almost certainly does a plain fetch with no
    decompression/conversion; that work must already be done.
  EOT
  type        = string
}

variable "lan_network_name" {
  description = <<-EOT
    libvirt_network name intended to become this edge's LAN side -- placed
    at interfaces[0] in main.tf, which plausibly (not guaranteed) determines
    which vtnetN device FreeBSD assigns it. IMPORTANT (corrected 2026-07-09
    audit): this variable does NOT by itself make OPNsense treat it as LAN --
    that role assignment happens separately, inside config.xml's own
    interface-to-role mapping (or the interactive/API assignment step).
    "vtnet0 = WAN" is a convention some guides use, not an enforced rule.
    Confirm the real vtnetN<->network mapping on a real boot (e.g. `ifconfig`)
    before writing config.xml's <wan>/<lan> interface names -- do not assume
    "passed as lan_network_name" automatically becomes OPNsense's LAN role.
    Kept as an explicit named variable (not an ordered list) so the INTENT
    stays clear in this file even though the real role still comes from
    config.xml.
  EOT
  type        = string
}

variable "wan_network_name" {
  description = <<-EOT
    libvirt_network name intended to become this edge's WAN side -- placed at
    interfaces[1] in main.tf. Same caveat as lan_network_name: this ordering
    does not itself assign the WAN role in OPNsense; config.xml does. The
    mesh-link legs (modules/mesh-link) or a per-site ISP-simulated segment
    are the expected callers here.
  EOT
  type        = string
}

variable "autostart" {
  description = "Start this domain automatically when the libvirt host boots (D-127 boot matrix). MANUAL (false) for DC containment + node VMs; true for foundational service VMs + edges. Set explicitly per instance in the root -- do not rely on the default."
  type        = bool
  default     = false
}

variable "expose_qga_channel" {
  description = <<-EOT
    D-129: expose the org.qemu.guest_agent.0 virtio-serial channel on this edge.

    OPT-IN, DEFAULT OFF BY DESIGN. Adding a device changes the domain, and on an
    ALREADY-BUILT edge that means a replace + reboot of a live router. Defaulting
    this ON would bounce every existing edge the next time anyone ran a plan. So:
    existing edges are untouched, and NEW DC edges set it true so they boot with
    the channel and never need the retrofit (D-129 Implementation prep).

    WITHOUT the channel the os-qemu-guest-agent PACKAGE still installs and still
    appears "present" -- but it has no transport and can never answer, which is
    exactly the false-success the D-129 review warned about. The package is only
    meaningful when this is true. Verify with `virsh ... guest-ping`, never by
    package listing alone.
  EOT
  type        = bool
  default     = false
}