How Quake AI uses OpenStack

Quake AI runs on OpenStack Antelope (2023.1). Each public Quake AI service (compute, networking, storage, automation, and Kubernetes) maps to an OpenStack project. The standard OpenStack CLI, APIs, and Terraform provider work with these public services. If you have existing OpenStack experience, it transfers directly.

You do not need to understand OpenStack to use Quake AI. The documentation uses Quake AI terms, and you can provision and manage infrastructure entirely through the Console, CLI, or Terraform without learning the underlying project names first. The project names appear in CLI commands, API endpoints, Terraform resources, and parts of the Console UI. This page explains the relationship so those names make sense when you encounter them.

What Quake AI deploys#

Each Quake AI service maps to one or more OpenStack projects. The table below shows the primary mapping, what each project handles, and the API endpoint pattern.

The Compute API runs version 2.1 (microversion ceiling 2.93). The Identity API runs version 3. For the full endpoint list with clouds.yaml configuration, see Service Endpoints.

Audience#

New to cloud#

You can skip the rest of this page. Follow the Quickstart and use whichever interface you prefer: the Console, the CLI, or OpenTofu (each is available as a tab on step 3).

When you see names like "Nova" or "Neutron" in a CLI command or error message, they refer to the OpenStack projects listed in the table above. The mapping is stable: Compute always means Nova, and Network always means Neutron, so you can treat the names as interchangeable labels for the same service.

Experienced with OpenStack#

Everything works as expected. The CLI is python-openstackclient, installed with pip. Authentication uses openrc.sh with application credentials (generate credentials). Heat templates use standard HOT syntax with resource types like OS::Nova::Server and OS::Neutron::Net. The Terraform provider is openstack, with resources like openstack_compute_instance_v2 and openstack_networking_secgroup_v2.

Quake AI-specific details to note:

• Console UI: the Console is built on upstream OpenStack Skyline with Quake AI-specific layout, navigation, and form customizations. Customer documentation refers to it as the Console or "Cloud Console", not "Skyline". The Console hostname is sky.{region}.rumble.cloud; the embedded VNC viewer is served from sky-console.{region}.rumble.cloud.
• API rate limits: OpenStack removed built-in rate limiting in Rocky (2018). The Nova and Cinder /limits endpoints return "rate": [] on Antelope. Any rate limiting in front of the APIs sits at the openresty gateway and does not return RateLimit-* or Retry-After headers. If you receive HTTP 429, implement exponential backoff. HTTP 413 on this platform indicates quota exhaustion.
• Resource tiers: Quake AI uses a tier-based quota model. Your resource tier sets your project's vCPU, RAM, and storage limits. Individual instance launches do not raise the cap.
• Default image: Ubuntu 24.04 with cloud-init pre-configured. See Images for the full public catalog.
• Default key algorithm: ED25519. Quake AI also accepts RSA.
• Networking: Projects include PublicEphemeral (direct-attach for testing) and PublicStatic (routed via private networks for production). See Networks for the topology model.
• Object storage: S3-compatible via the Swift S3 gateway. Standard S3 SDKs work with --endpoint-url. Native Swift ACLs apply. See the S3 feature compatibility matrix for supported and unsupported S3 features.

Migrating from another cloud#

If you are coming from AWS, GCP, Azure, Hetzner, or another provider, the core concepts map to OpenStack projects with different names:

Platform differences:

• Databases: deploy PostgreSQL, MySQL, or Redis on instances using automation templates.
• Authorization: Keystone provides admin, member, and reader roles at the project level. IAM-style resource policies are absent; use project isolation for separate trust boundaries.
• Billing model: your resource tier sets the quota ceiling; individual instance launches do not incur separate charges.
• Terraform provider change: replace hashicorp/aws (or equivalent) with terraform-provider-openstack/openstack. Resource names change (aws_instance becomes openstack_compute_instance_v2). See Introduction to Terraform on Quake AI.

Migration guides for object storage are available at Object storage migration.

Where OpenStack terms appear#

You will encounter OpenStack project names in CLI output, API references, Terraform resources, and troubleshooting docs. This is by design: the tooling runs on OpenStack, and masking the names would make troubleshooting and external documentation harder to use.

• CLI commands: OpenStack CLI commands use the openstack prefix: openstack server create, openstack network list, openstack volume show
• API endpoints: the base URLs use OpenStack service names: compute.{region}.rumble.cloud (Nova), network.{region}.rumble.cloud (Neutron)
• Terraform resources: all resource types use the openstack_ prefix: openstack_compute_instance_v2, openstack_networking_secgroup_v2, openstack_blockstorage_volume_v3
• Heat templates: resource types use the OS:: namespace: OS::Nova::Server, OS::Neutron::Net, OS::Cinder::Volume
• Console UI: the Automation section displays Heat Stacks as a menu item; the API dashboard lists OpenStack service names alongside Quake AI service names
• Error messages: API errors reference the originating service: a network conflict returns a Neutron 409, a quota exceeded error references Nova or Cinder

When you search for help with an error, using both the Quake AI service name and the OpenStack project name improves your results. For example, searching "Neutron security group rule conflict" finds upstream OpenStack documentation that applies directly to Quake AI.

OpenStack services Quake AI does not offer#

Quake AI does not offer the following OpenStack projects as public services:

If your workload depends on one of these services, you can self-host the equivalent on Quake AI instances. The automation templates provide validated starting points for common self-managed deployments.

See also#

• Service Endpoints: published service base URLs, clouds.yaml example, endpoint discovery
• OpenStack CLI: install and configure the openstack command-line client
• Install OpenStack client: detailed installation for all platforms
• Application credentials: authenticate CLI and API access
• Quickstart: first steps with Quake AI
• Introduction to Terraform on Quake AI: IaC with the OpenStack provider
• OpenStack upstream documentation: official project docs for all OpenStack services