sam 6fc92541e9 router extension (dormant) + v2 redesign doc after OOM'd first run
Adds the real-router BMP extension code and a redesign doc capturing
what changed in the test's intent.

  scripts/router_bmp.py           push/dry-run/remove `bmp server 2`
                                  on all 18 lab routers via paramiko
                                  SSH shell. Inventory + cred pattern
                                  lifted from obmp-rib-poller/poller.py.
                                  Activation scope: bmp-activate server 2
                                  on the existing BMP-MONITORED
                                  neighbor-group -- mirrors production.

  terraform/router_bmp.tf         terraform_data resource with two-step
                                  safety (dry-run first, apply on
                                  confirm), triggers_replace on action
                                  change, destroy provisioner calls
                                  `remove` (idempotent, on_failure=
                                  continue so a stuck router doesn't
                                  block VM teardown).

  terraform/terraform.tfvars      enable_router_bmp / confirm_router_push
                                  both default false (dormant).

  docs/redesign-real-routers.md   captures the pivot from v1 "prove
                                  deploy.sh works" to v2 "canary
                                  collector receiving real router BMP".
                                  Documents that v1 store VM OOM'd at
                                  4 GB under the internal --profile
                                  test feed alone, proposes 32 GB /
                                  8 vCPU for v2 and dropping --profile
                                  test so the collector receives ONLY
                                  real router BMP.

State on prox940 as of this commit:
  - v1 VMs (9001 store, 9002 bmpgen) destroyed via PVE API
    (terraform destroy hung on the OOM'd guest agent)
  - Terraform state cleaned
  - Cached Ubuntu image kept for a fast next apply
  - Lab routers untouched (extension code dormant)

Not yet done, awaiting user input:
  - v2 sizing landed in terraform.tfvars
  - Compose scope decision (add --no-feeders to deploy.sh vs
    workaround in cloud-init)
  - Re-apply
  - Router extension dry-run + confirm

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-07-21 07:21:03 -07:00

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.
Description
End-to-end portability test for obmp-docker: two Proxmox VMs, cloud-init, deploy.sh, BMP assertion set.
Readme 71 KiB
Languages
HCL 61.1%
Python 23.5%
Shell 15.4%