sam d30ec2074a initial commit: two-VM Proxmox portability test for obmp-docker
Terraform (bpg/proxmox) provisions two Ubuntu 24.04 cloud-init VMs on a
Proxmox host, one running obmp-docker's `deploy.sh --scope full-stack`
and the other running GoBGP as a BMP-source stand-in. `scripts/run-test.sh`
runs the six assertions from docs/design.md (containers healthy, BMP
peer up, ip_rib/bgp_peers non-zero, Grafana healthcheck).

Layout:
  terraform/            provider + VM + cloud-init snippet resources
  terraform/cloud-init/ user-data templates (store + bmpgen)
  scripts/              run-test.sh, teardown.sh
  docs/design.md        topology, assertion set, and rationale

Cred handling:
  terraform.tfvars is gitignored; endpoint + api_token can also come
  from PROXMOX_VE_ENDPOINT / PROXMOX_VE_API_TOKEN env vars.

Not validated locally: `terraform init && terraform validate` -- the
terraform binary is not on the authoring host. YAML + shell + HCL brace
balance verified.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-07-20 18:19:45 -07:00

3.4 KiB

obmp-portability-test

End-to-end portability test for the obmp-docker stack. Spins up two fresh Proxmox VMs from a stock Ubuntu cloud image, has one deploy the OpenBMP stack (deploy.sh --scope full-stack --yes) and the other run GoBGP configured to open a BMP session to it, then asserts that data actually lands in Postgres.

If this test passes, "portability" is more than a hope — you can hand the obmp-docker URL to a new operator and they get a working stack.

What it proves

  • deploy.sh runs to completion on a from-scratch Ubuntu 24.04 host with no prior state.
  • The stack's containers all reach healthy after the documented delay.
  • A router (GoBGP standing in for one) can open a BMP session to the collector on the ROUTER_FACING_IP / ROUTER_FACING_PORT defined in the target's .env.
  • Route data actually lands in ip_rib, peer sessions land in bgp_peers — i.e. the ingest path works end-to-end across two hosts.

If any of these fail, the test tells you which step broke.

Layout

obmp-portability-test/
├── README.md
├── docs/design.md               <- what/why in more detail
├── terraform/
│   ├── main.tf                  <- providers + versions
│   ├── variables.tf             <- inputs, all with descriptions
│   ├── terraform.tfvars.example <- copy to terraform.tfvars, fill in
│   ├── image.tf                 <- one-time cloud-image download
│   ├── store_vm.tf              <- VM A: OpenBMP store
│   ├── bmpgen_vm.tf             <- VM B: GoBGP BMP source
│   ├── outputs.tf               <- IPs, next-step hints
│   └── cloud-init/
│       ├── store.cloud-init.yaml.tftpl
│       └── bmpgen.cloud-init.yaml.tftpl
└── scripts/
    ├── run-test.sh              <- terraform apply + wait + assert
    └── teardown.sh              <- terraform destroy wrapper

Prerequisites

  • Proxmox VE 7.4+ (bpg/proxmox provider requires it).
  • A PVE API token with permissions to create/destroy VMs, download files to the ISO storage, and use the target storage pool. Any user with PVEVMAdmin on / works for a lab setup; production would scope tighter.
  • Terraform 1.5+ on the machine you run this from.
  • SSH keypair for reaching the VMs after they boot (path passed as a terraform variable).

Running

cd terraform
cp terraform.tfvars.example terraform.tfvars
$EDITOR terraform.tfvars      # fill in PVE endpoint, token, network, storage
terraform init
terraform validate
terraform plan
terraform apply

# Once the VMs are up (cloud-init takes 5-10 min for docker+deploy.sh):
cd ..
./scripts/run-test.sh         # polls SSH, then runs the assertions

To tear down:

./scripts/teardown.sh

Cost of one test run

Two VMs (2 vCPU / 4 GB / 20 GB disk each by default) for ~30 min. On a Proxmox host with headroom, negligible. All state is destroyed on teardown; cloud image is cached across runs.

What's NOT tested

  • Authelia mode (OBMP_AUTH_MODE=authelia) — this test uses local auth because there's no reverse-proxy front-end in the two-VM topology.
  • Real router integration (BGP-LS, gNMI, NETCONF) — GoBGP handles the BMP path only. Extending to a third VM with FRR + gNMI is future work.
  • Long-running behavior — the assertions fire once, ~15 min in. Not a soak test.