Replacing Vagrant with Barn in Pigsty: resources, names, and migration work

Pigsty can use one inventory for Barn and Ansible. The migration needs to preserve topology selection, image matrices, resource scaling, fixed addresses, and SSH workflows while replacing the old scripts’ implicit addressing, naming, and destruction behavior.

Status (2026-11-10): vm_scale, the 1-vCPU / 2-GiB defaults, vm_hosts, barn hosts install -f, and Pigsty’s bin/sandbox-dns are implemented in the local working trees and have passed the offline checks below. They are unreleased. Pigsty’s Makefile still uses Vagrant; the second half of this article describes the remaining work. Released Barn 1.1.0 actually defaults to 2 vCPU / 4 GiB when parsing an inventory and does not support these additions.

What the Vagrant scripts provide

Old resource differences need not carry over: meta uses 2 vCPU / 4 GiB; full uses one 2-vCPU / 4-GiB node and three 1-vCPU / 2-GiB nodes; simu mixes several sizes. The new base is 1 vCPU / 2 GiB per node. Database, build, or application tests can raise their base resources or scale explicitly. These VM defaults do not replace module capacity requirements.

Prerequisites such as new: del up and meta9: cmeta del vmeta9 up ssh do not establish a reliable execution order. make -j can configure, destroy, and start concurrently. The new entry point should use a sequential recipe or script that stops at the first failure.

Sources: configuration generator, Vagrant directory, and Pigsty Makefile.

The vm_scale decision

Resolve vm_cpu, vm_mem, and vm_scale independently in this order: host > deepest child group > parent group > all.vars > default. Then multiply once:

Effective CPU    = base vm_cpu (default 1) × vm_scale (default 1)
Effective memory = base vm_mem (default 2048 MiB) × vm_scale (default 1)

Setting only vm_scale: 3 produces 3 vCPU / 6 GiB. Adding vm_cpu: 2 and vm_mem: 4GiB produces 6 vCPU / 12 GiB. A host can set vm_scale: 1 to override its group’s multiplier; scales at different levels do not compound. Disks do not scale. See the configuration reference for units, bounds, and upgrading existing deployments.

The VM parameter design specifies command scope, short flags, environment variables, precedence, and persistence for image, architecture, CPU, memory, scale, and root disk size. The proposal forwards only explicitly supplied Make IMAGE/ARCH/CPU/MEM/SCALE/DISK variables as CLI flags, which outrank corresponding BARN_* environment variables. Template defaults and host exceptions remain in YAML, and ordinary lifecycle commands save no hidden preferences. An IMAGE option or distribution suffix may override images in homogeneous profiles. Build profiles must retain per-node vm_image unless the user explicitly requests one image for all nodes.

DNS is feasible as an explicit operation

Changing the system /etc/hosts still requires root. Extraction, validation, and preview can run as the ordinary user, with only the final controlled write delegated to Barn’s helper. Repeating an unchanged plan needs no sudo. Initial setup is one occasion to publish names; adding a portal or changing a VIP requires another publication.

Pigsty’s bin/sandbox-dns interprets service configuration. Barn accepts generic all.vars.vm_hosts mappings, combines them with node names and aliases, validates them, and replaces the # barn:begin/end block. These mappings stay outside the VM spec hash, so DNS edits do not require VM recreation or restart.

With the development commands available, run these from the Pigsty repository:

# Requires Python 3, PyYAML, and a Barn build with hosts install -f
bin/sandbox-dns -f conf/meta.yml          # preview by default
bin/sandbox-dns -f conf/meta.yml --json
bin/sandbox-dns -f conf/meta.yml --apply  # Barn requests sudo when necessary
barn hosts uninstall --yes

Set BARN=/absolute/path/to/barn to use a local build. The script first calls barn validate, then creates a temporary inventory with mode 0600 containing only node identities and names. It does not copy Pigsty credentials, keys, or share configuration. Identical mappings deduplicate; conflicting destinations identify their sources, with names compared without case. Records owned by other tools remain intact, and conflicts require an explicit decision about migrating those older records.

Like Barn, the adapter reads a static inventory without running inventory plugins, group_vars, host_vars, or general Jinja expressions. Unresolved templates in relevant fields, wildcards, and addresses outside the inventory subnet fail explicitly. pg_dns_target: primary reflects the declared inventory and does not follow live Patroni failover; an already configured VIP is preferable for an HA entry point. When several infra nodes each resolve i.pigsty to themselves, the host cannot represent all those local views simultaneously. Select one ingress or use distinct domain names first.

If wildcard names and dynamic records become necessary, evaluate domain-specific forwarding to Pigsty DNS. macOS domain resolvers and Linux resolver integration need separate designs. The current phase needs neither a resident DNS process on the host nor a global nameserver change.

Offline audit of 54 configurations

On 2026-11-10, the local candidate ran barn validate --json against all 54 conf/**/*.yml files and extracted their names. 53 passed VM validation; 42 passed DNS extraction. These are static checks. Module deployment and VIP failover still require native acceptance tests.

Barn reserves .1 for the host and .2–.8 for DHCP; static nodes start at .9. Pigsty’s common .2/.3/.4 VIPs must move. None of the current 54 templates uses .100/.101/.102, making them candidates for this sandbox migration. Update explicit DNS records, connection strings, and examples together, and check for collisions with the selected inventory’s nodes and other VIPs. Relaxing hosts validation would not resolve the network conflict.

Barn names nodes using nodename > pg_cluster-pg_seq > node-lastOctet. Pigsty’s node_id_from_pg: true can instead overwrite an explicit nodename in the guest. Preserve old script names such as meta, node-1, and el9 explicitly through inventory names and vm_alias; verify both host SSH aliases and guest hostnames.

Complete the replacement in this order

Barn still manages one Linux deployment per user. Profiles describe desired topologies for that deployment. Changing BARN_HOME does not isolate the user’s shared runtime paths or host private network, so it is not a concurrent-environment mechanism. Image defaults belong to separate layers too: the new Pigsty entry point can select u26 while Barn retains its embedded catalog’s u24 default.

Implementation and validation evidence

Resource inheritance and scaling are in inventory.go and inventory_test.go. Hosts merging and privilege boundaries are covered by hostconfig and cmd/barn/hosts_inventory_test.go. Pigsty’s new local files are bin/sandbox-dns and tests/test_sandbox_dns.py, with service rules checked against roles/infra, roles/pgsql, roles/node_id, and roles/minio. These links identify the repositories; the local working trees remain authoritative for the unreleased changes until they are committed and published.

Completed checks include make build, Barn make check, 11 Pigsty extractor unit tests, and the 54-template offline audit. The real command for conf/meta.yml returned applied: false and displayed 10 names. System hosts writes, VM resource changes, VIP failover, and Pigsty playbooks have not been executed; they are assigned to the native acceptance phase above.