How to customize a template's image and flavor
Coming from another cloud?
▸AWS·EC2 AMI Selection, Instance Types
Instance Types
- Fixed predefined configurations only; no custom flavor creation.
- Extensive families for GPU/HPC/ARM etc.
- InstanceType as string param in API, not ID reference.
- Tied to specific hardware generations (Nitro/Xen).
▸Google Cloud·Machine types
Machine types
- Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
- Custom types +5% premium for N/E series; no such billing in OpenStack.
- Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.
How to customize a template's image and flavor
Change the operating system image or hardware size on an OpenTofu template you already deployed. This guide applies to any template under Automation templates that exposes image_name and flavor variables in variables.tf. Image and flavor names must match Quake AI catalog literals; see Authoring IaC templates for Quake AI for the full naming rules and template conventions.
Prerequisites
- ConsoleLogged in to the Quake AI console
- CLIOpenStack CLI installed and authenticated (
clouds.yamloropenrcsourced) - TerraformOpenTofu installed with Quake AI provider configured
Windows: CLI examples use bash. Set up a Linux CLI environment on Windows before proceeding.
- You deployed a template from
iac/templates/(or copied its HCL into your own project) and rantofu initin that directory - OpenTofu or Terraform installed and Quake AI credentials configured (see Get started with IaC)
- Enough project quota for the target flavor (run
openstack limits show --absoluteif you are sizing up)
Locate the image and flavor variables#
Open variables.tf in your template directory. Every compute-backed template declares an image_name variable and at least one flavor variable. The flavor variable name differs by template:
| Template | Flavor variable(s) | Default image |
|---|---|---|
| simple-vm, edge-reverse-proxy, containerized-app | flavor_name | Ubuntu-24.04 |
| wordpress-mysql | wp_flavor, db_flavor | Ubuntu-24.04 |
| full-stack-app, three-tier-app | web_flavor, app_flavor, db_flavor | Ubuntu-24.04 |
| k8s-cluster | cp_flavor, worker_flavor | Ubuntu-24.04 |
| dev-environment | flavor_name, bastion_flavor | Ubuntu-24.04 |
The simple-vm template wires these variables into a Glance data source and the instance resource:
data "openstack_images_image_v2" "os" {
name = var.image_name
most_recent = true
}
resource "openstack_compute_instance_v2" "vm" {
flavor_name = var.flavor_name
# ...
block_device {
uuid = data.openstack_images_image_v2.os.id
# ...
}
}The wordpress-mysql template uses one shared image_name for both instances but separate flavor variables:
resource "openstack_compute_instance_v2" "wordpress" {
flavor_name = var.wp_flavor
# ...
}
resource "openstack_compute_instance_v2" "mysql" {
flavor_name = var.db_flavor
# ...
}Templates look up images by name, so the value you set must match a Glance image name exactly (for example Ubuntu-24.04, not Ubuntu 24.04).
Choose an image and flavor#
Set the new image or flavor#
Pick one override mechanism. Use the same approach for every subsequent change so your team knows where values live.
Option A: terraform.tfvars (recommended)#
Create or edit terraform.tfvars in the template directory:
image_name = "Rocky-9"
flavor_name = "c2a.large"For wordpress-mysql:
image_name = "Ubuntu-22.04"
wp_flavor = "s1a.medium"
db_flavor = "m2a.large"OpenTofu loads terraform.tfvars automatically on every plan and apply.
Option B: -var on the command line#
tofu plan \
-var 'image_name=Rocky-9' \
-var 'flavor_name=c2a.large'Repeat each -var flag for every flavor variable your template defines.
Option C: edit the default in variables.tf#
Change the default attribute on the variable block. This works for a personal fork but makes upstream merges harder, so prefer terraform.tfvars for values you change often.
Plan and apply the change#
From the template directory:
tofu plan
tofu applyRead the plan carefully:
- Image change: OpenTofu marks affected
openstack_compute_instance_v2resources with-/+orforces replacementbecause the boot volume is rebuilt from the new Glance image. Plan for brief downtime and a new root volume. - Flavor change: A larger flavor usually updates in place. Downgrading RAM may require replacement depending on the instance state; the plan output shows
forces replacementwhen OpenTofu cannot resize in place.
If the plan fails with Your query returned no results, the image or flavor name does not match the catalog. Re-run openstack image list or openstack flavor list and copy the name exactly.
Verify the new image and flavor#
After tofu apply completes, confirm the running instances match your overrides.
openstack server list -f table -c Name -c Flavor -c ImageFor a single instance:
openstack server show INSTANCE_NAME -c flavor -c image -f yamlIf the template exposes addresses in outputs.tf (as simple-vm does), retrieve them with:
tofu outputSSH to the instance and check the OS when you changed image_name. Replace YOUR_USER with the default SSH user for your image. See default usernames by distribution.
ssh -i ~/.ssh/YOUR_KEY YOUR_USER@FLOATING_IP cat /etc/os-releaseSee also#
- Authoring IaC templates for Quake AI
- Automation templates: reference pages for all 13 templates
- Flavors: category overview and sizing guidance
- Images CLI reference: full
openstack imagecommand set - Flavors CLI reference: full
openstack flavorcommand set - How to manage multiple environments with OpenTofu: per-environment tfvars files
- How to debug Terraform errors: data-source name mismatches and quota errors
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: 26.06.2026