Support ticket evidence collection
Support ticket evidence collection
When a problem is not self-resolvable and you need to escalate to Quake AI support, collecting the right evidence upfront reduces back-and-forth and speeds up resolution. This page provides a reusable checklist that works across compute, network, storage, and Kubernetes incidents.
Before you start#
- Have the OpenStack CLI installed and authenticated (
source openrc.sh) - Note the UTC timestamp when the problem first occurred; this is the most important piece of context for the support team
- If possible, keep the affected resources in their current state until you have gathered evidence; do not delete or recreate resources before capturing diagnostics
General evidence checklist#
Collect these items regardless of incident type:
| Item | Command | Why it matters |
|---|---|---|
| Project ID | openstack project show YOUR_PROJECT -c id | Identifies your project in platform logs |
| Timestamp (UTC) | Record when the problem started | Allows support to correlate with platform events |
| Quota usage | openstack quota show --usage | Rules out resource exhaustion |
| Token validity | openstack token issue | Confirms your CLI session is authenticated |
| Recent changes | Note any security group, network, or configuration changes made before the issue | Identifies potential self-inflicted causes |
Compute evidence#
| Item | Command |
|---|---|
| Instance ID and status | openstack server show YOUR_INSTANCE -c id -c status -c fault |
| Console log (last 50 lines) | openstack console log show YOUR_INSTANCE --lines 50 |
| Instance details | openstack server show YOUR_INSTANCE |
| Key pair used | openstack server show YOUR_INSTANCE -c key_name |
Network evidence#
| Item | Command |
|---|---|
| Network ports | openstack port list --server YOUR_INSTANCE |
| Port details | openstack port show YOUR_PORT -c security_group_ids -c fixed_ips -c status |
| Security group rules | openstack security group rule list YOUR_SECURITY_GROUP |
| Floating IP details | openstack floating ip show YOUR_FLOATING_IP |
| Router details | openstack router show YOUR_ROUTER |
Block storage evidence#
| Item | Command |
|---|---|
| Volume ID and status | openstack volume show YOUR_VOLUME -c id -c status -c attachments |
| Snapshot status | openstack volume snapshot show YOUR_SNAPSHOT -c id -c status |
| Volume list | openstack volume list |
Object storage evidence#
| Item | How to get it |
|---|---|
| Access key (not the secret) | openstack ec2 credentials list -c Access |
| Endpoint URL used | The value of AWS_ENDPOINT_URL or --endpoint-url in your client configuration |
| Full error response | Copy the complete error message or XML/JSON response from your client |
| Request details | Note the HTTP method, URL, and any special headers used |
Kubernetes evidence#
| Item | Command |
|---|---|
| Cluster ID and status | openstack coe cluster show YOUR_CLUSTER -c uuid -c status -c status_reason |
| Heat stack ID and status | openstack stack show STACK_ID -c stack_status -c stack_status_reason |
| Failed stack resources | openstack stack resource list STACK_ID --filter status=FAILED |
| Master instance console log | openstack console log show MASTER_INSTANCE --lines 100 |
| kubectl output (if cluster is reachable) | kubectl get nodes -o wide and kubectl cluster-info |
Data hygiene before sharing#
Before including evidence in a support ticket, redact or remove:
- Passwords and secrets: never include passwords, private keys, or secret keys in a ticket
- EC2 secret keys: share only the access key, not the secret key
- Application credential secrets: share only the credential name or ID
- Personal data: redact usernames, email addresses, or other personal information that is not relevant to the issue
- Environment variables: if sharing shell output, verify that no credentials leaked into the output
Filing the ticket#
Include in your support ticket:
- One-sentence summary of the problem
- UTC timestamp when it started
- Affected resource IDs (instance, volume, cluster, network, as applicable)
- What you already tried: steps taken and their results
- Evidence from the checklists above
- Reproduction steps if the issue is repeatable
File tickets through the Quake AI support portal.
See also#
- Troubleshooting overview
- Auth token diagnostics: 401/403 errors, token expiry, credential scope
- Quota and limits troubleshooting: quota exhaustion across compute, network, and storage
- Instance connectivity troubleshooting
- Instance lifecycle troubleshooting
- Volume troubleshooting
- Object storage access troubleshooting
- Kubernetes cluster troubleshooting
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
For the full policy, see Usage Guidelines.
Last validated: 02.06.2026