Terraform Change Review Field Notes

Service Level Indicators (SLIs) are easier to understand when they are tied to a working service. Abstract definitions are useful, but a small lab makes the tradeoffs visible: what counts as success, what counts as failure, how latency should be measured, and how trends can reveal degradation before a full incident. This field note uses a companion lab in GitHub: https://github.com/trinidadgithub/IaC/tree/main/sli_app The lab runs a small Flask application, exposes Prometheus metrics, provisions Prometheus and Grafana with Terraform, and includes a basic SLI dashboard. It also introduces lightweight data science habits: percentiles, rolling windows, error-rate comparison, and avoiding misleading averages. ...

Terraform modules are easier to consume when engineers can understand their inputs without reading every line of source code. While reviewing an AWS Terraform Kinesis module, I created an input summary table with six columns: Input, Type, Default Value, Required, Notes, and Recommendation. The goal was simple: make the module safer and faster to use by turning variable definitions into an operator-friendly interface. The Problem This Solves Terraform modules often start clean and become harder to consume over time. Inputs are added for new capabilities, defaults change, conditional behavior grows, and security-sensitive options become mixed with ordinary configuration. The source code still contains the truth, but consuming the module requires reading variables.tf, resource blocks, locals, conditionals, and sometimes provider documentation. ...

A VM can have the correct FQDN intent and still receive the wrong resolver search suffix. The trap is treating these as the same setting: vm_domain -> identity/FQDN domain dns_search -> resolver search suffix list They are related, but they are not the same control. Symptom An environment sets DNS search suffixes to empty: dns_search = "[]" But new vSphere VMs still boot with a resolver search domain such as: search corp.example.com The node audit shows drift even though the Terraform input looked correct: ...

Importing existing vSphere VMs into Terraform can produce a clean source-of-truth checkpoint and still leave a plan that should not be applied. That is common when legacy Kubernetes nodes were built from an older template or outside the current module conventions. Audit Checkpoint A useful checkpoint looks like this: NetBox resources: no-op vSphere resources: update destroy actions: none This means NetBox ownership is reconciled, but Terraform still sees vSphere drift. ...

After existing vSphere VMs are imported into Terraform state, expect drift. The question is not whether drift exists. The question is whether applying that drift is safe. Generate The Audit Plan terraform plan -out=audit.tfplan terraform show -json audit.tfplan \ | jq -r '.resource_changes[]? | [.address, .type, (.change.actions | join(","))] | @tsv' Start with action types: no-op update create delete delete,create For imported production-like nodes, any delete, create, or delete,create action needs explicit review before apply. ...

NetBox has more than one way to represent infrastructure. A VMware VM imported as a DCIM device may look usable in the UI, but it is not the same object model as a NetBox virtualization virtual machine. Terraform provider resources for NetBox virtualization expect the virtualization model. Symptom A known VM does not show up through the virtualization endpoint: curl -s \ -H "Authorization: Token $NETBOX_TOKEN" \ -H "Accept: application/json" \ "$NETBOX_URL/api/virtualization/virtual-machines/?name=$VM_NAME" \ | jq '.count' Expected if it is modeled as a virtualization VM: ...

Use this workflow when existing vSphere VMs need to be brought under Terraform state for audit and future lifecycle management. The first goal is not to change the VMs. The first goal is to make Terraform aware of them and classify drift. Safety Boundary Set the operating rule before importing: Import state and audit only. Do not apply full vSphere changes to existing cluster nodes. This avoids turning a state migration into an accidental infrastructure mutation. ...

After Terraform creates or resizes a vSphere VM, verify NetBox reflects the same lifecycle state. This check is separate from preflight. Preflight prevents unsafe allocation before apply. Post-provision verification proves source-of-truth state matches what Terraform just changed. Set Lookup Values Use generic environment variables so the commands are reusable: export VM_NAME="cluster-a-app-01" export VM_IP="192.0.2.10" export VM_DNS_NAME="cluster-a-app-01.example.com" export NETBOX_CLUSTER_NAME="cluster-a" NetBox API credentials: export NETBOX_SERVER_URL="https://netbox.example.com" export NETBOX_API_TOKEN="..." Verify VM Metadata curl -s \ -H "Authorization: Token $NETBOX_API_TOKEN" \ -H "Accept: application/json" \ "$NETBOX_SERVER_URL/api/virtualization/virtual-machines/?name=$VM_NAME" \ | jq '.results[] | { id, name, status: .status.value, cluster: .cluster.name, vcpus, memory_mb: .memory, disk_size_mb: .disk, primary_ip4: .primary_ip4.address }' Confirm: ...

Use this checklist when resizing Terraform-managed vSphere VMs after initial provisioning. The goal is to update VM state without accidentally replacing the VM, losing NetBox alignment, or skipping guest OS disk follow-up. Edit Desired State Change the VM entry in the environment VM map: locals { vms = { "app-1" = { name = "cluster-a-app-01" ipv4_address = "192.0.2.10" ipv4_netmask = tostring(var.netmask) cpu = 4 ram_gb = 32 disksize = 80 attach_data_disk = true data_disk_gb = 200 } } } Avoid manual vCenter edits for values Terraform owns. ...

When Terraform creates vSphere VMs, NetBox should not be an after-the-fact documentation step. Use NetBox as an ownership gate before vSphere VM creation, then verify Terraform removes the NetBox records when the managed VM is destroyed. Desired Order The safe order is: 1. Resolve required NetBox objects 2. Create NetBox VM record 3. Create NetBox interface record 4. Create NetBox IP address record 5. Set NetBox primary IPv4 6. Create vSphere VM The vSphere VM should depend on the NetBox primary IP relationship, not just the VM record. ...