This is the multi-page printable view of this section. Click here to print.
Specifications
1 - Infra nas
1.1 - NAS infrastructure Specification
Purpose
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.
Requirements
Requirement: Scoped NAS configuration packaging
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.
Scenario: Inspect the NAS configuration and Vault packaging
- WHEN a maintainer inspects the NAS target declarations
- THEN the AL target includes
al.luaand the shared infrastructure AL dependency - AND the Vault command map references that NAS AL target
Requirement: Distinct local and global cloud DNS destinations
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.
Scenario: Consume DNS declarations for different views
- WHEN a DNS consumer selects the entries tagged
dc1andglobal - THEN it receives the NAS destination for the DC1
cloudalias and the ingress destination for the globalcloudalias.
2 - Owned dns
2.1 - owned-dns Specification
Purpose
Define NAS DNS management through the owner’s tf root,
including canonical declarations, scoped credentials, and offline source checks
before adopting live records.
Requirements
Requirement: Owner-local DNS configuration
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.
Scenario: Inspect the preparatory configuration
- 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
Scenario: Adopt existing DNS records
- 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
Scenario: Inspect adopted source defaults
- 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
Scenario: Reconcile existing DNS records
- WHEN the owning root plans against its adopted state and unchanged declarations
- THEN it proposes no record additions, changes, replacements, or deletions
Requirement: Scoped DNS execution and offline checks
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.
Scenario: Validate the Terraform source
- 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
Scenario: Prepare an operational Terraform invocation
- 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