tritonadm setup

tritonadm setup creates the control plane on a head node and destroys it again. It has four subcommands: bootstrap, converge, apply, and destroy. One of them is required. setup on its own is a usage error.

All four subcommands act on the local host, so all four run in the head node global zone as root. They drive imgadm, svccfg, svcadm, and the native tritond-vmadm zone library, and they run zlogin, vmadm list, vmadm get, ipadm, route, prtconf, and sysinfo. The dispatch arm for setup does not receive the global --endpoint or --api-key options. The tritond sessions that setup opens read TRITONADM_ENDPOINT, TRITONADM_API_KEY, TRITONADM_ACCESS_TOKEN, the config file, and the local tritond socket, as described in Endpoint and credential resolution.

Synopsis

tritonadm setup bootstrap [OPTIONS]
tritonadm setup converge [OPTIONS]
tritonadm setup apply [OPTIONS]
tritonadm setup destroy [--dry-run] [--yes]

Description

setup bootstrap is genesis. It installs the platform image, creates the founder FoundationDB and tritond zones, and installs the global-zone agents. It preserves the root credential and signs the CLI in. With an answers document, it approves the founder compute node and imports the answers as the committed cluster intent, then creates the DNS server and the first certificate that the answers request. It ends with the founder pivot. It prints == bootstrap complete — run `tritonadm setup converge` to continue == when it finishes. You can run it again after any interruption before the pivot. It refuses to run again after the pivot.

setup converge moves the observed state toward the committed cluster intent. It wakes the intent reconciler in tritond and prints the reconciler's step log until every step is satisfied. Every step is re-entrant, so it can run on any coherent deployment state. It is the forward path for a genesis that stopped after the founder pivot. Without --answers, it reads the committed intent from the control plane.

setup apply runs bootstrap and then convergence in one pass.

The command has two entry paths. The --answers path reads a JSON answers document and resolves it against a facts snapshot. It prints a plan preview with fingerprint words and stops on error-severity findings. It then lowers the approved plan into a setup plan and runs the same executor. The flag-derived path resolves a plan from the options below, an optional TOML file passed with --config, and host facts probed at run time. The flag-derived path commits no intent, so the reconciler has nothing to converge toward.

Two profiles shape the control network. In poc, the control plane uses a host-private illumos etherstub. tritond gets a second NIC on the admin network for off-box reachability. In production, the control plane uses an operator-supplied nic_tag with explicit addresses. An answers document lowers to production, except when its admin network sets host_private: true. That document describes a single-node datacenter: it lowers to poc, builds the etherstub on the declared CIDR, and runs no founder pivot.

setup creates no zpool. The only host networking it creates is the poc etherstub nic_tag, the global-zone vnic, that vnic's address, and, for an answers document with an external DNS block, the external network's nic tag.

setup destroy takes no resource options. It probes the host for every resource that apply can create and destroys what is present. Configuration that changed after apply cannot change the target of the teardown.

Options

setup bootstrap, setup converge, and setup apply

The three subcommands accept the same option set. --answers selects the answers-document path. Every plan-shaping option is refused together with it.

Option	Value	Default	Description
--answers	path	none	Resolve this JSON answers document against facts, print the plan preview, then lower and apply the approved plan. Cannot be combined with the plan-shaping options listed under Answers documents.
--facts	path	live gather	A captured facts snapshot to resolve --answers against. Requires --answers. Without it, facts are gathered from this machine with triton_facts::gather().
--config	path	none	TOML file of plan settings. Options on the command line win over the file. Keys are listed under Configuration file.
--fdb-ip	IPv4 address	192.168.250.2 in poc	Control-network address for triton-fdb0. In production this option, or a discoverable running triton-fdb0, is required.
--tritond-ip	IPv4 address	none	Control-network address for triton-tritond. Required in production. In poc the address is fixed at 192.168.250.10 and this value is not read.
--tritond-admin-ip	IPv4 address	DHCP lease	poc only: static admin-network address for the second NIC of tritond. In production this value is not read.
--mantad-ip	IPv4 address	192.168.250.12 in poc with --with-mantad	Address of a mantad node. Repeat for a multinode cluster. Conflicts with --mantad-nodes.
--mantad-nodes	integer	none	Number of mantad nodes. Addresses are allocated from free addresses on the control network. Conflicts with --mantad-ip.
--replication	integer	1 for fewer than 3 nodes, 3 at 3 or more	Byte-plane replication factor. A value of 2 or higher with fewer than 3 nodes is refused. Accepted values are clamped to the range 1 through the node count.
--clickhouse-ip	IPv4 address	192.168.250.11 in poc when ClickHouse is enabled	Control-network address for triton-clickhouse.
--netmask	dotted mask	255.255.255.0	Admin-network mask in poc. Control-network mask in production.
--gateway	IPv4 address	first default route from route -n get default	Admin-network gateway in poc. Control-network gateway in production.
--resolver	IPv4 address	first nameserver line in /etc/resolv.conf	DNS resolver written into the zones.
--nic-tag	nic_tag name	admin	poc only: nic_tag for the off-box admin NIC of tritond.
--profile	poc or production	production when --controller-nic-tag is set, poc otherwise	Control-plane profile. Any other value is rejected.
--controller-nic-tag	nic_tag name	none	production: the private control-network nic_tag. Setting it selects the production profile.
--channel-url	URL	see Channel selection	Channel manifest URL. Wins over --channel.
--channel	channel name	see Channel selection	Named channel shorthand, expanded to the manifest URL of that channel.
--image-dir	path	none	Install images and agents from a local directory of built artifacts instead of the signed channel. Bypasses the channel fetch and its signature check. --channel and --channel-url are then unused.
--with-mantad	flag	off	Plan the mantad (S3) zones. In production, requires --mantad-ip or --mantad-nodes, and more than one node is refused. In poc, the address defaults to 192.168.250.12.
--with-clickhouse	flag	on in poc, off in production	Plan the triton-clickhouse zone.
--no-clickhouse	flag	off	Leave ClickHouse out of the plan. Overrides both the profile default and --with-clickhouse.
--fdb-secret	hex string	discovered, else newly minted	Pin the FoundationDB cluster secret. An empty value and the literal generate both use the default.
--fdb-memory	GiB integer	clamp(host_ram_gb / 8, 2, 8)	Memory for triton-fdb0. Host RAM comes from prtconf -m. When it cannot be detected, the value is 16 GiB, which yields 2 GiB.
--fdb-disk	GiB integer	20	Disk quota for triton-fdb0.
--tritond-memory	GiB integer	4	Memory for triton-tritond.
--tritond-disk	GiB integer	20	Disk quota for triton-tritond.
--clickhouse-memory	GiB integer	8	Memory for triton-clickhouse in the printed plan.
--clickhouse-disk	GiB integer	40	Disk quota for triton-clickhouse in the printed plan.
--dry-run	flag	off	Print the resolved plan and the planned changes. Change nothing.
--yes	flag	off	Skip the confirmation prompt shown before a run whose plan contains a destructive change. Visible alias: --force.
--insecure-issuer	flag	off	Accept a plaintext single sign-on issuer when the run declares no DNS, or DNS without ACME. Required on the flag-derived path, which declares no DNS. The issuer is immutable once a realm is seeded. Without a DNS name it is lost with the founder zone. Throwaway labs only. converge does not check it.
--force-skip-dns-preflight	flag	off	Continue after a failed DNS delegation preflight. DNS and certificate issuance will not work until the delegation matches the plan.
--force-skip-cert-gate	flag	off	Continue after the genesis certificate-issuance gate when ACME did not issue a wildcard bundle inside the wait budget. The cluster starts without TLS until the certificate reconciler succeeds.

There is no option for mantad, booter, or DNS server sizing, and no --with-booter option. The booter is enabled through the configuration file key with_booter or through an answers document. ClickHouse, mantad, and the booter are created by the intent reconciler during convergence, with the fixed sizes under Zone sizing. The reconciler creates mantad only when the committed answers set datacenter.manta.enabled. On the flag-derived path nothing creates the mantad zones: bootstrap validates the mantad options, and no intent is committed. The ClickHouse sizing options change only the printed plan.

Channel selection

bootstrap and apply resolve the channel from --channel-url, then --channel, then the channel_url and channel keys of the --config file, then the stable channel. converge with neither flag nor --image-dir first reads the cluster's channel.upstream_url through tritond and prints channel <URL> (cluster config channel.upstream_url). It falls back to the same chain when the key is unset or the control plane does not answer.

When the channel fetch fails, bootstrap and apply report resolve the release channel for bootstrap. converge reports this message:

resolve the release channel for converge; a cluster installed from --image-dir must pass --image-dir again, or declare an upstream with `tritonadm config set channel.upstream_url <url>`

setup destroy

Option	Value	Default	Description
--dry-run	flag	off	Print the teardown diff. Change nothing.
--yes	flag	off	Skip the teardown confirmation prompt. Visible alias: --force.

Configuration file

--config reads a TOML file. Every key is optional. An unrecognized key is a parse error. Command-line options win over file values.

Key	Type	Equivalent option
profile	string	--profile
controller_nic_tag	string	--controller-nic-tag
nic_tag	string	--nic-tag
netmask	string	--netmask
gateway	string	--gateway
resolver	string	--resolver
fdb_ip	string	--fdb-ip
tritond_ip	string	--tritond-ip
tritond_admin_ip	string	--tritond-admin-ip
mantad_ips	array of strings	--mantad-ip
booter_ip	string	none
mantad_nodes	integer	--mantad-nodes
replication	integer	--replication
clickhouse_ip	string	--clickhouse-ip
with_mantad	boolean	--with-mantad
with_booter	boolean	none
with_clickhouse	boolean	--with-clickhouse
fdb_memory_gb	integer	--fdb-memory
fdb_disk_gb	integer	--fdb-disk
tritond_memory_gb	integer	--tritond-memory
tritond_disk_gb	integer	--tritond-disk
clickhouse_memory_gb	integer	--clickhouse-memory
clickhouse_disk_gb	integer	--clickhouse-disk
channel_url	string	--channel-url
channel	string	--channel
insecure_issuer	boolean	--insecure-issuer

poc control network

The poc profile uses fixed names and addresses.

Resource	Value
Etherstub nic_tag	triton0
Global-zone vnic	cpgz0
Global-zone address	192.168.250.1/24
Netmask	255.255.255.0
triton-fdb0	192.168.250.2
triton-tritond	192.168.250.10
triton-clickhouse	192.168.250.11
triton-mantad	192.168.250.12
triton-booter	192.168.250.13

The founder pivot takes the lowest free addresses in the /24 for triton-fdb1 and triton-tritond1. On a fresh poc host these are 192.168.250.3 and 192.168.250.4.

A single-node answers document builds the etherstub on its declared admin CIDR instead of 192.168.250.0/24, and allocates addresses from that network's infra_range.

Zone sizing

Zone	Created by	Memory	Disk
triton-fdb0	bootstrap	clamp(host_ram_gb / 8, 2, 8) GiB	20 GiB
triton-tritond	bootstrap	4 GiB	20 GiB
triton-dnsedge0	bootstrap, when the answers declare DNS	1 GiB	10 GiB
triton-clickhouse	intent reconciler	8 GiB	40 GiB
triton-mantadN	intent reconciler	4 GiB	100 GiB
triton-booter0	intent reconciler	2 GiB	40 GiB

Every control-plane zone gets cpu_cap 200 and a delegated dataset. Every control NIC is net0 on the control nic_tag, with vlan_id 0, MTU 1500, and primary set. In the poc profile tritond also gets net1 on the admin nic_tag, and net1 becomes the primary NIC. net1 is static when --tritond-admin-ip is given and DHCP otherwise.

Behavior

Plan resolution

setup apply resolves the plan before it touches the host. It reads --config when given, probes host facts, and looks for an existing FoundationDB cluster.

Discovery reads the live cluster file from a running triton-fdb0 over zlogin. It tries /etc/fdb/fdb.cluster first and /data/etc/fdb/fdb.cluster second. If neither is present, it reads the zone metadata keys triton:fdb_cluster_secret and triton:fdb_cluster_peers. A cluster file whose description is not triton is ignored. A lookup error is propagated. It is not read as an absent cluster.

The FoundationDB cluster secret resolves in this order: --fdb-secret, then the secret discovered from a running triton-fdb0, then a newly minted random 128-bit hex value.

The production profile requires --controller-nic-tag, an --fdb-ip or a discoverable running triton-fdb0, and --tritond-ip. Each missing value produces its own error.

Answers documents

--answers is refused in combination with --config, --tritond-admin-ip, --mantad-ip, --mantad-nodes, --replication, --clickhouse-ip, --netmask, --gateway, --resolver, --nic-tag, --profile, --controller-nic-tag, --fdb-secret, --fdb-memory, --fdb-disk, --tritond-memory, --tritond-disk, --clickhouse-memory, --clickhouse-disk, --with-mantad, --with-clickhouse, and --no-clickhouse. The image-source and execution options remain legal.

The plan preview prints verbatim. Any error-severity finding stops the run before anything is touched. With --dry-run the run stops at the preview and fetches no channel. The preview needs no addresses, so you can validate an answers document off-node against a --facts snapshot.

Without --dry-run, bootstrap and apply then run the founder bond preflight and, when the answers declare DNS, the DNS delegation preflight. Every phase then checks that the answers' platform image source can satisfy the request. All of this happens before any host change.

An answers document whose admin network declares infra_range owns the control-plane addresses. Passing --fdb-ip or --tritond-ip together with it is refused. Lowering sets profile=production, or profile=poc when the admin network is host_private. It takes the control nic_tag from the name of the network, the netmask from its CIDR, the gateway verbatim, and the resolver from the first entry. A derived address outside the declared CIDR is rejected.

Order of operations

bootstrap runs in this order. apply runs the same steps and then the convergence steps below.

1. Resolve the plan. Check the single sign-on issuer: a plaintext issuer needs --insecure-issuer, except on a single-node datacenter that declares a console name. Print the plan, starting with == tritonadm setup: genesis bootstrap == (apply prints single-node headnode bring-up in place of genesis bootstrap).
2. Load images and agents. Scan --image-dir, or fetch the channel manifest and verify its minisign signature against the publisher key compiled into the binary.
3. Validate the resolved image set. triton-platform is the only required image. It carries every control-plane role, including ClickHouse and mantad.
4. Refuse to continue when the founder pivot will run and the artifact source carries no tritonagent. A dry run, an adopted cluster, and a single-node datacenter skip this check.
5. Refuse to run genesis again when pivot descendant zones exist. See Re-running bootstrap.
6. Assemble the resource graph and print the planned changes. With --dry-run, stop here.
7. Apply the graph, in graph order:
   1. poc control network: the triton0 etherstub nic_tag, the cpgz0 vnic, and its address.
   2. poc boot service site/triton-gz-vnic: the start-method script at /opt/triton/triton-gz-vnic/bin/triton-gz-vnic (mode 0755) and the manifest at /opt/triton/triton-gz-vnic/smf/triton-gz-vnic.xml (mode 0644), imported and enabled, with a copy under /opt/custom/smf so SmartOS imports it again at boot.
   3. imgadm install of triton-platform.
   4. triton-fdb0, then FoundationDB genesis.
   5. triton-tritond.
   6. The tritonagent bundle, its agent.env, and its SMF service.
   7. The proteusadm bundle.
   8. With an answers DNS block, the external network's nic tag on the founder.
8. Read the one-time root password from /data/state/tritond/server.out inside the tritond zone. Write /root/triton-root-password at mode 0600, with endpoint=, username=root, and password= lines.
9. Configure the CLI against http://<TRITOND_IP>:8080 by exchanging that password for a token pair. This step is skipped when a session already resolves. A failure here is a warning, not a genesis failure.
10. Register the genesis zones in the infrastructure-zone registry. The tritond zone is skipped when the founder pivot will run.
11. With an answers document: when datacenter.dns.provider is set, store the DNS provider API token and restart the founder tritond. Then approve the founder compute node and import the answers as the committed intent, or verify an intent that is already committed.
12. With an answers DNS block: create triton-dnsedge0, check that the nameservers serve, put the DNS server first in the global zone's resolver list, and wait for the first certificate.
13. Read the SSO root password from the tritond zone and write /root/triton-sso-root-password.
14. Run the founder pivot, or print why it is skipped. With an answers DNS block, check DNS serving again after the pivot and, with ACME, check the TLS certificate of the surviving tritond.
15. Print the closing lines. See Bootstrap output.

The DNS provider token is read from TRITON_DNS_PROVIDER_API_KEY when that variable is set and not empty. Otherwise bootstrap prompts for it without echo, as Gandi LiveDNS API key for zone <ZONE>: or Cloudflare API token for zone <ZONE>: . A credential already stored under the same reference is reused without a prompt.

converge, and the second half of apply, run in this order:

1. Derive the control-plane endpoint: the surviving triton-tritond1 address after a pivot, or the founder tritond on an adopted cluster or a single-node datacenter.
2. Resolve a session: a stored or environment session, then the /root/triton-root-password handoff, then the local tritond socket.
3. With answers, check that they match the committed intent.
4. Point the CLI config at the endpoint, and with an answers DNS block put the DNS server first in the global zone's resolver list.
5. Unless --image-dir was given, set channel.upstream_url to the resolved channel when the key is unset.
6. Wake the intent reconciler and print each step transition. With --image-dir, when the channel-publish step is blocked, publish the local directory as the in-cluster channel from this host.
7. Exit at the fixed point with == converge complete: intent revision <N> at fixed point ==.

The reconciler's steps include clickhouse-zone, dnsedge-zone, dns-serving, first-certificate, dc-trust-anchors, endpoint-convergence, clickhouse-wiring, mantad-deployment, manta-storage, channel-publish, booter-zone, booter-serving, boot-policy, declared-records, pi-staging, control-plane-seats, and manta-growth. A step the intent does not request reports not applicable. When no step changes for 20 minutes, converge fails and names the first step that is not satisfied. The reconciler keeps running in tritond after the command exits.

A dry run of bootstrap resolves the plan, fetches and verifies the channel manifest, validates the image set, and prints the graph diff. The founder pivot is not simulated. A dry run of converge with an answers document, given or already committed, prints the answers preview and stops. Without one, it prints the endpoint it would talk to and lists the steps.

Readiness gates

triton-fdb0 is created with no readiness probe. The genesis step that follows retries the cluster-creation command instead. triton-tritond gates on an HTTP success from http://<TRITOND_IP>:8080/v1/health, and its readiness is required.

Gate	Budget	Poll interval
HTTP readiness	180 seconds	4 seconds
Zone-file readiness	240 seconds	4 seconds
SMF service settle	180 seconds	2 seconds

An HTTP or zone-file gate logs a still-waiting milestone every 30 seconds.

FoundationDB genesis

Genesis is the single cluster-creation step, and it is authorization-gated. It runs fdbcli --exec "configure new single ssd" inside the zone only when /data/version is absent and /data/fdb-genesis.pending contains the literal 730. A /data/version that holds any other value refuses genesis. A missing /data/version on its own is not authority to run the command.

Genesis waits up to 30 seconds for the pending marker and up to 120 seconds for the database to report available. It polls every 250 milliseconds. It then revokes the zone metadata capability and stamps /data/version. On failure it collects diagnostics from the zone: svcs -xv site/triton-fdb, pgrep -fl fdbserver, the SMF log, the fdbserver log, and the recovery trace.

Founder pivot

The founder pivot runs at the end of every bootstrap and apply, except in two cases. An adopted cluster, whose FoundationDB address is a coordinator list, prints founder pivot skipped: this run created no fdb zone (adopted cluster). A single-node datacenter prints founder pivot skipped: single-node datacenter (the founders are the survivors). In both cases the founder tritond is permanent and is registered at step 10.

The pivot opens with == D6 founder pivot: grow fdb1@<FDB1_IP> + tritond1@<TRITOND1_IP>, retire the founder ==. Its steps:

1. Take two free control-network addresses for the replacements. With an answers DNS block they are chosen before triton-dnsedge0 is created.
2. Grow triton-fdb1 through the plan, approve, and grow path. The founder compute node is approved first if it is not yet Approved.
3. Provision triton-tritond1 through the control plane with first-boot peers that name both FoundationDB members. With ACME, it is born with a certificate. Gate on its /v1/health, then require an authenticated, store-backed read to succeed.
4. Rewrite TRITONAGENT_ENDPOINT in agent.env and the stored CLI endpoint to point at triton-tritond1. Restart tritonagent synchronously, then wait for a heartbeat from the restarted agent and for 30 seconds of claim drain.
5. Register the founder tritond in the infrastructure-zone registry and retire it through the control plane's teardown operation. The agent runs the teardown as a Delete job.
6. Decommission and destroy triton-fdb0 through the plan, approve, and decommission path, driven through triton-tritond1. Read the post-swap cluster status, and fail unless it reports both available and quorum reachable.
7. With an answers document, read the committed intent back through triton-tritond1.

On success the pivot prints == founder pivot complete: fdb and tritond both proved grow & shrink ==.

Wait	Budget
Each grow, provision, teardown, and decommission operation	20 minutes
Founder compute node reaching Approved	5 minutes
Replacement tritond serving a store-backed read	180 seconds
Restarted agent heartbeat after the endpoint change	90 seconds

A pivot failure fails the run with a message that begins D6 founder pivot failed — genesis is NOT complete.

Re-running bootstrap

Before it touches the host, bootstrap looks for the pivot descendant zones triton-fdb1 and triton-tritond1.

Host state	Result
No descendant zone	A normal genesis run.
Both descendants and both founders, triton-fdb0 and triton-tritond	An interrupted pivot. Bootstrap prints incomplete founder pivot: both replacements and both founders exist; bootstrap will verify the replacements and resume retirement, checks the replacements, and resumes the two retirements.
Any other combination	Bootstrap refuses. A dry run prints a warning instead.

The refusal reads:

refusing to re-run genesis: pivot descendant zone(s) <ZONES> exist without both founder zones and both replacements. A completed pivot continues with `tritonadm setup converge`; inspect the zone and operation records before recovering any other partial state.

converge does not run this check.

Confirmation

bootstrap and apply print the planned diff first. When the plan contains a destructive change and --yes was not passed, it prompts Apply the changes above? This modifies existing resources. with a default of No. A purely additive first-run bring-up applies with no prompt.

danger

Answering No skips only the resource changes. The command prints aborted; nothing was changed. and continues with the credential handoff, the CLI configuration, the answers import, and the founder pivot, then exits with success. Review the plan with --dry-run before running bootstrap or apply, and press Ctrl-C at the prompt to stop the run.

destroy prints the diff. It reports nothing to destroy. when the plan has no changes. Otherwise it prompts Tear down the resources above? This is destructive. with a default of No, unless --yes was passed.

Managed files and services

Zone images are staged into a temporary directory under /var/tmp. They are streamed to disk while hashing, verified against the manifest sha256, and installed with imgadm install -m <MANIFEST> -f <CONTENT>. An already-installed uuid is skipped.

Global-zone agent bundles extract under /opt/triton/<NAME> with /usr/bin/gtar and --no-overwrite-dir. Absolute paths and .. segments in a bundle are rejected. The installed version is read from /opt/triton/<NAME>/etc/version, so an install is idempotent on the stamp.

bootstrap writes /opt/triton/tritonagent/etc/agent.env at mode 0644. It manages the TRITONAGENT_ENDPOINT key, set to http://<TRITOND_IP>:8080. When the answers declare DNS whose certificates need data center trust anchors, it also writes them to /opt/triton/tritonagent/etc/dc-anchors.pem at mode 0644 and manages a TRITON_DC_ANCHORS key that points at that file. Operator-added keys such as RUST_LOG survive later runs. The tritonagent SMF service restarts when the bundle was extracted again or agent.env changed. proteusadm ships no SMF manifest, so no service is registered or restarted for it.

Bootstrap output

After the pivot, bootstrap prints these lines:

  bootstrap root credential preserved at /root/triton-root-password
  surviving control plane: <ENDPOINT>
  sso issuer     <ISSUER_URL>
  sso root pw    <PASSWORD>   (identityd root; shown once, store it now)
  sso handoff    preserved at /root/triton-sso-root-password

== bootstrap complete — run `tritonadm setup converge` to continue ==

Between the surviving control plane line and the SSO lines, a run from the channel sets channel.upstream_url to the channel it installed from, when the key is unset. A failure there is a warning: WARNING: could not record channel.upstream_url (<ERROR>); run `tritonadm config set channel.upstream_url <URL>` before converge. An --image-dir run leaves the key unset.

When the SSO password cannot be recovered, the sso root pw line names the reset command instead. When identityd does not answer its health check, a single line sso NOT RUNNING (password login still works) names the svcs command to diagnose it.

Teardown

danger

setup destroy deletes every control-plane zone in the list below that exists on this host, with its data, and then the images those zones used. There is no undo. It acts on this host only, so seats on other compute nodes keep running. It leaves /root/triton-root-password, /root/triton-sso-root-password, and the tritonadm configuration in place.

setup destroy runs the same graph shape in reverse. It removes these resources, in order:

1. The proteusadm bundle.
2. The tritonagent SMF service, its managed agent.env key, its bundle, and /var/lib/tritonagent.
3. The control-plane zones, then every image uuid they reported.
4. The site/triton-gz-vnic boot service and its files.
5. The poc control network, with nictagadm delete -f.

The control-plane zone list is triton-fdb0, triton-tritond, triton-mantad0, triton-booter0, triton-clickhouse, and triton-dnsedge0, plus every contiguous numbered triton-fdbN, triton-tritondN, and triton-mantadN from 1, plus the legacy unindexed triton-mantad. Image uuids are read from the running zones, not from a channel manifest, so teardown works offline. A resource that is not present is a no-op. For that reason, the fixed poc network names are always attempted.

Only the TRITONAGENT_ENDPOINT key is removed from agent.env. The file is removed only when nothing else remains in it. The external network nic tag that an answers DNS block created is left in place.

See also

• tritonadm command index
• tritonadm install
• tritonadm self-update
• Genesis on the founder
• Enroll compute nodes and converge
• Requirements
• Updates and channels
• Architecture