This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Nas

TrueNAS deploy

The Terraform package prepares this owner’s DNS records through its dedicated Vault AppRole. NAS service provisioning remains outside that root.

This diagram describes the maintained architecture source, not live inventory or service health. The Mermaid source is authoritative; Bazel renders its light and dark SVGs.

Truenas architectureTruenas architecture

1 - DNS Terraform

This root packages the owner’s canonical DNS declarations through the shared DNS module and keeps state in the owner AppRole’s Vault HTTP backend. The root contains DNS resources only. dns_enabled defaults to true after verified adoption. Keep it enabled to retain existing records; disabling it would propose deletion.

The DNS migration procedure owns credential provisioning, reconciliation, and recovery. The adoption record contains import and verification evidence. Use the //infra/nas/tf:tf wrappers for operational commands and //infra/nas/tf:tf_tests.fmt_test for offline source validation.

Operational Terraform calls require the DNS AppRole policy grants and credential fields described by the migration procedure. Provider configuration and authentication require real credentials and live access.

2 - OpenSpec

2.1 - Specifications

2.1.1 - Infra nas

2.1.1.1 - NAS infrastructure Specification

Describe the TrueNAS-related configuration surface currently owned by infra/nas. The baseline is checked-in source at revision 550d7e79b1f5fdbc2b6017b75178471d6914082f, observed on 2026-09-08. The directory contains an AL configuration, DNS declarations, Vault wrappers, and brief documentation. It does not contain a TrueNAS provisioning playbook or Terraform configuration, and this baseline makes no claim about live NAS configuration or availability.

Source baseline limitation: the owning BUILD file restricts the AL target’s visibility to //infra/harvester:__subpackages__, although infra/harvester does not exist in this revision. This declaration does not establish a working consumer integration.

The project SHALL declare its AL configuration through //infra/nas:al. That configuration SHALL depend on the shared //infra:al configuration. The project’s Vault command map SHALL use its own AL target.

Sources: project description and configuration and command targets.

  • WHEN a maintainer inspects the NAS target declarations
  • THEN the AL target includes al.lua and the shared infrastructure AL dependency
  • AND the Vault command map references that NAS AL target

The NAS DNS declaration SHALL expose the NAS host and root names as A records, and SHALL distinguish the DC1 and global cloud aliases. The DC1 cloud alias SHALL target nas.alwaldend.com., while the global alias SHALL target ingress.alwaldend.com.. The DNS filegroup SHALL remain visible only within the infrastructure tree.

Sources: DNS declarations and DNS target visibility.

  • WHEN a DNS consumer selects the entries tagged dc1 and global
  • THEN it receives the NAS destination for the DC1 cloud alias and the ingress destination for the global cloud alias.

2.1.2 - Owned dns

2.1.2.1 - owned-dns Specification

Define NAS DNS management through the owner’s tf root, including canonical declarations, scoped credentials, and offline source checks before adopting live records.

The tf root SHALL consume this owner’s canonical dnsconfig.json through the shared DNS Terraform module, preserving declared record identities and views. DNS resources SHALL default to disabled until the authorized adoption revision and SHALL retain enabled ownership after existing records are imported into the owner’s state. Reconciliation against unchanged declarations and adopted state SHALL propose no record additions, changes, replacements, or deletions.

  • WHEN the checked-in root is evaluated with default inputs before its authorized adoption revision
  • THEN it reads this owner’s declaration and disables managed DNS records
  • AND the package contains the module and declaration inputs
  • WHEN the authorized adoption freezes the old central writers and enables the owner’s record management
  • THEN the owning root imports existing records by exact provider ID into its state while preserving their declared identities and views
  • WHEN the adopted root uses its checked-in source defaults
  • THEN DNS ownership remains enabled and the package retains the module and canonical declaration inputs
  • WHEN the owning root plans against its adopted state and unchanged declarations
  • THEN it proposes no record additions, changes, replacements, or deletions

The DNS wrapper SHALL select src_infra_nas through the repository AL flow and keep secret values in injected variables. DNS injection SHALL select the root’s existing Terraform stage label. Real DNS credentials and Vault policy grants SHALL be prerequisites for operational Terraform calls. RouterOS DNS credentials SHALL be isolated from unrelated RouterOS resources. The package SHALL expose a format test that does not authenticate to Vault or contact DNS providers.

  • WHEN the package format test executes
  • THEN it checks the packaged Terraform configuration without live credentials
  • AND existing non-DNS authentication and backend paths remain unchanged
  • WHEN the wrapper selects its Terraform stage labels
  • THEN it selects DNS credential injection through the owner AppRole
  • AND disabled DNS resources do not imply offline provider configuration