# obmp-portability-test

End-to-end portability test for the [obmp-docker](http://10.40.40.143:3000/sam/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](http://10.40.40.143:3000/sam/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

```bash
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:

```bash
./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.