Node configuration

Four commands sit at the top level of the Site CLI rather than behind execcli — they are what the interactive menu offers when you log in, alongside diagnosis and update-tx-queue-len-vhost0.

Captured 2026-08-03 from the completion menu on software build crt-20260201-0179.

configure                   Initial configuration of the node
configure-generic-hardware  Configure Hardware that isn't certified by F5XC.
configure-network           Initial configuration of the network
configure-http-proxy        Initial configuration of the HTTP proxy

That is the appliance’s own menu text, and those six entries are the entire top level.

Five commands you might expect are not here

factory-reset, upgrade, reboot, show and clear do not exist on build crt-20260201-0179. They were carried in this repository’s command classification for a while on the assumption that a Site CLI would have them, but the live catalog does not. See the on-box index for how that was measured.

Interactive, and reconfigure a live node

Each of these is a wizard that rewrites the node’s configuration. None was run during this documentation work and none has captured output — there is no read-only form to capture. What is verified is that all four exist, and their descriptions, from the completion menu.

configure

Initial configuration of the node: the registration details that bind it to a tenant and a site.

configure-network

Initial configuration of the network — addressing for the node’s interfaces.

configure-http-proxy

Configures an outbound HTTP proxy, for a CE that cannot reach the F5 control plane directly.

configure-generic-hardware

Configures hardware F5 has not certified. Related to the certified-hardware configuration reachable through edit-certified-hardware: without a valid certified hardware endpoint, vpmd exits with “fail to match certified hardware” and the node never registers.

Why this repository does not use them

These are the manual path, and this deployment takes the automated one. Registration is written by cloud-init at first boot — terraform/cloud-init/ce-node.yaml writes /etc/vpm/config.yaml with the cluster name, token and certified-hardware endpoint — so a node comes up already configured and configure has nothing to do.

That matters for two reasons beyond tidiness:

• Reproducibility. A node configured by wizard is configured differently each time somebody does it. A node configured by cloud-init is configured identically every time, which is what makes the demo redeployable.
• They are the recovery path, not the deployment path. Reach for configure when a node needs to be re-pointed and Terraform is not an option — a node that never registered, over the serial console, where nothing else can reach it.

Registration is state, and replacing a node used to strand it

Re-registering is not purely a node-side operation: the tenant holds a registration object keyed on (tenant, cluster_name, hostname). Replacing a CE while keeping its name once wedged the deployment permanently, because the destroyed node’s registration still held that key. That is fixed — see the registration workflow — but it is why configure alone is not always enough to bring a rebuilt node back.