OpenStack compatibility check

Before you connect an OpenStack cloud to Waldur, you can check that Waldur can perform every OpenStack operation it supports on that cloud. The check is a single Python script, waldur_openstack_compat.py. It drives a Waldur deployment through the full lifecycle of an OpenStack tenant and reports each operation as passed, failed or skipped.

Waldur's own backend makes every call to the cloud, so a pass means Waldur's code works there: the OpenStack client libraries it ships, the API microversions it requests, and the way it reads the responses. A script that called OpenStack directly would only show that the cloud works.

What it checks

About a hundred operations, grouped as follows:

Area	Operations
Discovery	Credentials, external networks, flavors, volume types, availability zones
Service settings	Registering the cloud, pulling flavors, images and volume types; hypervisors and Placement inventories, usages and allocation candidates
Tenant	Create (Keystone project, user and roles, router, network, subnet), update, change password, set and pull quotas, pull security groups, server groups and floating IPs
Security groups	Create with rules, replace rules (including a remote group), update, delete
Networking	Network create, update and MTU; subnet create, host routes, connect and disconnect; router static routes, external gateway, interfaces, a second router
Ports	Create, change fixed IP, allowed address pairs, security groups, enable and disable, port security on and off
Floating IPs	Allocate, attach to and detach from a port, description, release
Instances	Create (boot from volume, data volume, floating IP, security groups, server group), console URL and log, metadata, Placement allocations, stop, resize, start, restart, rescue, security groups, ports, allowed address pairs, floating IPs
Volumes	Create, update, attach, detach, extend (also while attached), retype
Snapshots and backups	Snapshot, restore to a volume, delete; instance backup, restore to a new instance, delete
Load balancers	Load balancer, pool, listener, member, health monitor, floating IP on the VIP, VIP security groups, delete
Network sharing	RBAC share of a network with a second tenant and its revocation
Teardown	Every resource is deleted the way a user would delete it, then both tenants are terminated

An operation is skipped when the cloud or the options give it nothing to work with. For example, retype needs a second volume type, and rescue needs an image with the hw_rescue_device or hw_rescue_bus property that the tenant can see. The reason is printed next to it.

Requirements

A Waldur deployment with a running Celery worker, and a staff user's API token or credentials for it. The Waldur must reach the cloud's public API endpoints.
Admin credentials for the cloud, as an RC file sets them (OS_AUTH_URL, OS_USERNAME, OS_PASSWORD, OS_PROJECT_NAME, OS_USER_DOMAIN_NAME).
Python 3.9 or later with requests, on any host that can reach the Waldur API. A controller of the cloud works well: the RC file is already there, and the password never has to leave it.
Capacity for one small tenant: two instances at once (the second is a backup restored and deleted again), a few volumes, one load balancer, and three free addresses on the external network: the tenant router's gateway and two floating IPs. A second tenant is created without an external gateway for the network-sharing check.

Running it

source admin-openrc.sh
python3 waldur_openstack_compat.py \
    --waldur-url https://waldur.example.com \
    --waldur-token <staff API token> \
    --external-network public \
    --image "Ubuntu 24.04" \
    --flavor m1.small \
    --volume-type ssd

Without --image, --flavor and --volume-type, the script picks from what the new tenant sees: the first image, the smallest flavor by RAM, and the first volume type. The resize target defaults to the next larger flavor with the same disk size.

A run takes 30 to 45 minutes, mostly waiting on instances, volumes and the load balancer. It prints each operation as it completes, then a table, and writes the same results to openstack-compat.json. The exit status is 0 when no operation failed.

Options

Option	Default	Purpose
`--waldur-url`	`WALDUR_URL`	Waldur API, e.g. `https://waldur.example.com`
`--waldur-token`	`WALDUR_TOKEN`	Staff API token; or `--waldur-username` and `--waldur-password`
`--waldur-insecure`	off	Do not verify the Waldur API's TLS certificate
`--os-auth-url`, `--os-username`, `--os-project`, `--os-domain`	`OS_*` variables	Cloud admin credentials; the password is read only from `OS_PASSWORD`
`--os-verify-ssl`	off	Have Waldur verify the cloud's TLS certificates
`--external-network`	first external network	Name or ID of the network floating IPs come from
`--image`, `--flavor`, `--volume-type`	picked	What the instance and volumes use
`--resize-flavor`	next larger flavor	Target of the resize
`--retype-to`	none	A second volume type; retype is skipped without it
`--rescue-image`	any rescue image	Image to rescue the instance with
`--live-volume-resize`	off	Enable live volume resize on the offering and extend a volume while its instance runs
`--no-rbac`	off	Skip the second tenant and the network-sharing check
`--image-upload`	off	Also upload a small image into the tenant; Waldur cannot delete it afterwards
`--timeout`	600	Seconds to wait for each asynchronous operation
`--report`	`openstack-compat.json`	Where to write the results
`-v`, `--verbose`	off	Log each failed operation's traceback as well

What it leaves behind

The script registers the cloud in Waldur as a new offering, under a new organization and project whose names carry the run's random suffix (OS compat 3f9a1c). The cloud admin password is therefore stored in that Waldur's service settings, as it would be when the cloud is onboarded for real.

At the end, everything the run created in the cloud is deleted, and the offering is archived. The organization and project stay in Waldur and can be removed there. If a teardown step fails, its line in the table names the resource, which is then left in the cloud project of the tenant oscompat-<suffix> (or oscompat-b-<suffix>) and has to be deleted there by hand.

Reading the results

Each failed operation shows Waldur's error, which usually quotes the cloud's response. Some things to check:

A whole section is skipped: an earlier operation it depends on failed, and the line says which. Fix that one first.
Load balancer operations fail: the cloud has no Octavia, or its default provider does not support the TCP listener and SOURCE_IP_PORT algorithm the check uses.
Backup deletion is slow or fails while a restored instance exists: on copy-on-write storage such as Ceph RBD, volumes restored from a snapshot depend on it, and the storage refuses to delete it until they are gone. The check deletes the restored instance first for this reason.
Extending an attached volume fails while its instance is stopped: a known Waldur issue when live volume resize is off on the offering. Run with --live-volume-resize to check the in-use extend instead, if the cloud's block storage supports it.
Rescue fails with "No space left on device": the compute host copies the rescue image to its local disk, which needs room for it.
Rescue is skipped: no rescue image is visible to the tenant. A rescue image needs hw_rescue_device or hw_rescue_bus set, and must be public or shared with the tenant.