sam
d0b82c4973
The initial two-VM run against a real Proxmox host found three real
bugs in the obmp-docker stack, plus one design issue in this test:
Fixed in obmp-docker (deploy-refinement branch):
- 745f066 deploy.sh: probe sudo with `sudo -n true` instead of
`sudo -v` / `sudo -n -v`; the latter demands a credential
timestamp that NOPASSWD never produces, so both fail on
cloud-init / CI even with NOPASSWD:ALL configured.
- 6df67a7 .env.example: quote GNMI_ADDRESSES with single quotes so
docker compose's .env parser doesn't choke on the mid-line
comma in the double-quoted list form.
Fixed here:
- bmpgen cloud-init: add `port = 1179` under [global.config] to
avoid gobgpd's 179 listener bind failing under Ubuntu 24.04 +
Docker even with --network host and default NET_BIND_SERVICE cap.
We don't accept BGP peers on bmpgen so the port value doesn't
matter as long as it's unprivileged.
- run-test.sh: fix column name for bgp_peers.state -- the opstate
enum uses lowercase 'up', not uppercase 'UP'.
Verified against the live run: 6/6 assertions pass, ip_rib landed
251,760 routes from the store VM's own gobgp connecting to Bromirski's
public full-table feed via --profile test.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.shruns 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 inbgp_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
PVEVMAdminon/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.