Versions & Microversions
Quake AI runs OpenStack Antelope (2023.1). Some services support microversions: incremental API extensions you can opt into per-request. Quake AI has a microversion ceiling per service: requests above the ceiling return 406 Not Acceptable.
Per-service version ceilings
| Service | OpenStack project | API version | Max microversion on Quake AI | Current upstream (Epoxy) |
|---|---|---|---|---|
| Compute | Nova | v2.1 | 2.95 | 2.100 |
| Block Storage | Cinder | v3 | 3.70 | 3.71 |
| Network | Neutron | v2.0 | No microversions (extension-based) | |
| Object Storage | Swift | v1 | No microversions | |
| Automation | Heat | v1 | Template version 2021-04-06 | |
| Kubernetes | Magnum | v1 | K8s 1.25–1.27 | |
Using microversions
Include the OpenStack-API-Version header to request a specific microversion. Omit the header to use the base version.
# Request Nova Compute API microversion 2.95 curl -s \ -H "X-Auth-Token: $TOKEN" \ -H "OpenStack-API-Version: compute 2.95" \ https://compute.us-east-1.rumble.cloud/v2.1/servers
Key limitations vs. upstream
- Nova: The
os-volumes_bootAPI is not deprecated on Quake AI yet; upstream deprecated it in Caracal (microversion 2.96). - Cinder:
os-extend_volume_completionis not available; it requires microversion 3.71. - Heat: Heat is not deprecated on Quake AI yet but is deprecated upstream in Epoxy. Plan for a CAPI (Cluster API) migration for orchestration workflows that depend on Heat long term.
- Swift S3 compatibility: No lifecycle policies, no S3 notifications, no IAM-style ACLs, and limited versioning compared to AWS S3.
What happens above the ceiling
If you request a microversion above the service ceiling, the API returns 406 Not Acceptable. The response body includes the maximum supported version:
HTTP/1.1 406 Not Acceptable
Content-Type: application/json
{
"choices": [{
"id": "v2.1",
"status": "CURRENT",
"version": "2.95",
"min_version": "2.1"
}]
}