Ansible on Quake AI

Ansible is the configuration-management layer for Quake AI infrastructure. Where OpenTofu provisions instances, networks, and volumes, Ansible installs software, deploys applications, and manages OS state on the hosts that OpenTofu created. OpenTofu owns Day 0 provisioning; Ansible owns Day 1 and Day 2 configuration on those hosts.

This page explains how Ansible fits into the Quake AI automation toolchain, when to reach for it instead of OpenTofu, and what the openstack.cloud Ansible collection does on the platform.

What Ansible does#

Ansible is an agentless configuration-management tool. It runs on your workstation or a CI runner, connects to managed hosts over SSH, and applies tasks declared in YAML playbooks. No daemon runs on managed hosts; Ansible reaches them with the same SSH credentials you would use yourself.

Three primitives make up most Ansible workflows:

• Inventory: the list of hosts to manage. Static inventory is a hand-maintained file; dynamic inventory is generated from a live API.
• Playbook: a YAML file describing a sequence of tasks to apply against an inventory.
• Module: a unit of work invoked by a task. The standard library covers package installation, file management, services, users, and templating; collections such as openstack.cloud add cloud-specific modules.

Ansible is procedural and idempotent. A well-written task converges a host to the desired state regardless of starting point and is safe to rerun.

Where Ansible fits on Quake AI#

The Quake AI automation toolchain splits into three layers, each with a primary tool:

OpenTofu writes a state file that tracks which resources exist. Ansible has no equivalent: it connects to a host, applies tasks, and disconnects. That difference drives the boundary. Use OpenTofu when you need a plan-and-apply workflow with drift detection over a fleet of resources; use Ansible when the work is host-centric configuration that does not need a state file to be safe.

Ansible vs. OpenTofu#

The two tools are not substitutes. Provisioning a VM with Ansible is possible (the openstack.cloud.server module supports it) but trades away OpenTofu's state file, plan step, and drift detection. Configuring a VM with OpenTofu is possible via remote-exec provisioners but is widely considered an anti-pattern. Use each tool where it is strongest.

The openstack.cloud collection#

Ansible's OpenStack integration ships through the openstack.cloud collection, maintained by the OpenStack project. It provides modules for compute, network, storage, identity, Magnum (Kubernetes), and Heat (orchestration), plus a dynamic inventory plugin that queries running instances directly from Keystone.

The collection is under active development and tracks OpenStack releases. For Quake AI (running OpenStack Antelope, 2023.1), pin to the 2.x series:

The 1.x series of the collection requires older openstacksdk (< 0.99) and is incompatible with Antelope. Install from the 2.x series.

Provisioning from Ansible alone is supported but carries trade-offs. See How to provision a Quake AI instance with Ansible for the all-in-one pattern and the boundary callouts.

OpenTofu plus Ansible together#

A typical Quake AI workflow uses both tools in sequence:

1. Provision infrastructure with OpenTofu. Tag instances with metadata (environment, role) so Ansible can group them.
2. Discover the new hosts via the openstack.cloud.openstack dynamic inventory plugin. The plugin queries Keystone, returns running instances, and groups them by metadata.
3. Configure the hosts with Ansible playbooks. Re-run the playbook whenever configuration changes.

The complete walk-through lives in How to use Ansible with OpenTofu on Quake AI. It covers both the dynamic inventory plugin and the alternative tofu output -json pattern for teams that prefer version-controlled inventory files.

Authentication on Quake AI#

Ansible uses the same authentication chain as OpenTofu and the OpenStack CLI: application credentials sourced from a clouds.yaml file or OS_* environment variables. No separate Ansible credential format exists.

For day-to-day work, configure a named cloud in ~/.config/openstack/clouds.yaml:

clouds:
  quakeai:
    auth_type: v3applicationcredential
    auth:
      auth_url: https://keystone.rumble.cloud/v3
      application_credential_id: YOUR_APPLICATION_CREDENTIAL_ID
      application_credential_secret: YOUR_APPLICATION_CREDENTIAL_SECRET
    region_name: us-east-1
    interface: public
    identity_api_version: 3

Ansible modules and the dynamic inventory plugin both read this file. If you already have an openrc.sh from the OpenTofu setup, the same file works: source openrc.sh populates the OS_* variables Ansible needs.

For the credential creation flow, see Generate app credentials.

See also#

• How to get started with Ansible on Quake AI
• How to use Ansible with OpenTofu on Quake AI
• IaC on Quake AI: OpenTofu and Terraform
• How to get started with Infrastructure as Code
• Generate app credentials
• openstack.cloud collection documentation