Quota and limits troubleshooting

Quake AI enforces per-project quotas on compute, network, and storage resources. When a quota is exhausted, resource creation fails immediately with an error that names the exhausted resource. This page covers how to diagnose which quota is hit, how to free capacity, and when to request an increase.

Symptom patterns by service#

Diagnosis#

Check overall quota usage#

openstack quota show --usage

This shows each resource type, its limit, and current usage in one view.

You can also check quotas programmatically via the API /limits endpoint. The Compute API returns quotas at GET /v2.1/limits and the Block Storage API at GET /v3/{project_id}/limits. Both return an absolute object with maxTotal* limits and total*Used counters. See the Compute API reference and Block Storage API reference for the full response shape.

View quotas in the portal#

Skyline has no dedicated Quotas or Limits page. The Dashboard (the default page after sign-in, left-nav label Dashboard, route /base/overview) is the quota surface: its panels show per-resource Limit against In Use for Compute, Network, Block Storage, and Object Storage. Navigate by the left-nav label rather than the URL, which can change between Skyline releases.

Identify the exhausted resource#

openstack quota show --usage returns four columns: Resource, Limit, In Use, and Reserved. Look for resources where In Use equals or exceeds Limit. The Status column below is a reader annotation; the CLI does not emit it.

The public_ip row covers the floating-IP and public-IP quota family. Its In Use count includes router external gateway IPs, not floating IPs alone, so floating IPs and router gateways draw on the same quota. The CLI also reports a separate floating_ips row whose In Use count can differ from public_ip; run openstack floating ip list for the authoritative floating-IP count.

Portal label translation#

The CLI and the Skyline Dashboard name the same quota differently. When you cross-reference a CLI error against the Dashboard, translate the resource name:

Service-specific quota checks#

Compute resources:

openstack server list --status ACTIVE
openstack server list --status SHUTOFF
openstack server list --status ERROR

Instances in SHUTOFF and ERROR states still consume quota for instances, cores, and RAM.

Floating IPs:

openstack floating ip list

Floating IPs that are allocated but not associated to any instance still consume quota.

Volumes:

openstack volume list
openstack volume list --status available
openstack volume list --status error

Volumes in available and error states consume both volumes and gigabytes quota.

Snapshots:

openstack volume snapshot list

Each snapshot consumes snapshots quota and contributes to gigabytes usage.

Remediation#

Work through this cleanup sequence, checking quota after each step.

Step 1: delete ERROR-state resources#

These are the safest to remove; they are already non-functional:

openstack server list --status ERROR
openstack server delete ERROR_INSTANCE_ID

openstack volume list --status error
openstack volume delete ERROR_VOLUME_ID

Step 2: delete unused SHUTOFF instances#

Instances that are stopped still consume quota:

openstack server list --status SHUTOFF
openstack server delete UNUSED_SHUTOFF_INSTANCE

Step 3: Release unassociated floating IPs#

openstack floating ip list --status DOWN
openstack floating ip delete UNUSED_FLOATING_IP

A floating IP with status: DOWN is allocated but not associated with any port.

Step 4: Delete unused volumes and old snapshots#

openstack volume list --status available
openstack volume delete UNUSED_VOLUME

openstack volume snapshot list
openstack volume snapshot delete OLD_SNAPSHOT

Step 5: Verify freed capacity#

openstack quota show --usage

Confirm the exhausted resource now has available capacity, then retry your original operation.

Requesting a quota increase#

If cleanup does not free sufficient capacity, request a quota increase:

1. Check your current plan tier on the account dashboard
2. File a request through the support portal with:
   • Which resource(s) need increased limits
   • Current usage and requested new limit
   • Business justification (brief)
3. Quota increases are subject to platform capacity and plan tier availability

Verification#

After cleanup or quota increase, verify the operation that originally failed:

openstack quota show --usage

Then retry the original resource creation.

Prevention#

• Run openstack quota show --usage as a pre-flight check before large deployments or batch operations
• Clean up test and development resources after use
• Delete ERROR-state resources on a schedule; they consume quota without providing value
• Monitor quota utilization proactively; do not wait for creation failures
• Use openstack server list --all-projects (if you have admin access) to audit resource usage across projects

Quota CLI commands#

Show quota usage for the current project#

openstack quota show --usage

This is the primary diagnostic command. It shows each resource type, its limit, and current usage in one table.

Show quota limits without usage#

openstack quota show

Returns the configured limits without current usage counts.

List quotas across projects (admin only)#

openstack quota list --compute
openstack quota list --network
openstack quota list --volume

Show API rate and resource limits#

openstack limits show --absolute

Returns the same data as the /limits API endpoint. The --absolute flag shows resource quotas. See API rate limits for details on the /limits response.

See also#

• API rate limits: quotas vs. rate limits, the /limits endpoint
• Instance lifecycle troubleshooting
• Volume troubleshooting
• Troubleshooting overview
• Support ticket evidence collection