variable "link_name" {
description = "Identifier for this link, e.g. \"dc1-dc2\" -- used only for resource naming/logging, matches modules/mesh-link's link_name convention."
type = string
}
variable "vcloud_host_ssh_target" {
description = <<-EOT
SSH target for the host carrying the mesh bridges, e.g.
"user@vcloud-host" -- or EMPTY (the default) to run `sudo tc` directly
on the machine invoking `tofu apply`. Empty is correct for the D-128
outer root, which executes ON the vcloud host itself (Plane 1) where
the bridges live; the SSH hop remains for any root that runs remotely
(the module's original D-103 Office1 assumption, amended 2026-07-21).
Passwordless sudo for the tc verbs (and, in SSH mode, key-based SSH)
are assumed prerequisites, not configured by this module.
EOT
type = string
default = ""
}
variable "bridge_name" {
description = <<-EOT
The OS-level Linux bridge interface name backing a modules/mesh-link
network. NOT auto-derived from the mesh-link module: reading a
libvirt_network's `bridge` attribute back when the resource didn't set
it explicitly is unconfirmed this session (see modules/mesh-link's
outputs.tf note). Confirm the real bridge name with `virsh net-info
<network-name>` (or `tofu show` post-apply) and pass it explicitly here
-- no default.
EOT
type = string
}
variable "netem_args" {
description = <<-EOT
The raw arguments passed to `tc qdisc ... root netem <netem_args>` --
e.g. "delay 5ms 1ms distribution normal loss 0.1%". No default: the
exact latency/jitter/loss/rate parameters are still an unruled D-100
Phase-0 decision (buildout-design Section 6/10) -- this module provides
the injection mechanism, not the parameter choice. tc's own netem syntax
is stable, long-standing kernel functionality and was not re-verified
this session (out of scope -- the OpenTofu-side mechanism was the
research target, not tc itself); confirm your exact netem_args string
with `man tc-netem` or a live `tc qdisc` test before relying on it.
EOT
type = string
}