# Ansible on Quake AI

Source: https://docs.quake.ai/docs/automation/concepts/ansible
Markdown: https://docs.quake.ai/docs/automation/concepts/ansible.md

---

# Ansible on Quake AI

[Ansible](https://docs.ansible.com/) is the configuration-management layer for Quake AI infrastructure. Where [OpenTofu](/docs/automation/concepts/iac-comparison) 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](https://docs.ansible.com/ansible/latest/collections/openstack/cloud/) 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:

<Figure size="md" caption="Day 0 / Day 1 / Day 2: OpenTofu provisions, Ansible configures and operates.">

```d2
direction: down

day0: Day 0: Provision {
  tofu: OpenTofu
  resources: VMs, networks, volumes,\nsecurity groups, floating IPs
  tofu -> resources
}

day1: Day 1: Configure {
  ansible1: Ansible
  config: Users, packages, services,\nconfig files, SSH hardening
  ansible1 -> config
}

day2: Day 2: Operate {
  ansible2: Ansible
  ops: Deploy releases, rotate secrets,\npatch OS, run audits
  ansible2 -> ops
}

day0 -> day1: hand off provisioned hosts
day1 -> day2: re-run for ongoing changes
```

</Figure>

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

| | OpenTofu | Ansible |
|---|---|---|
| **Primary purpose** | Provision infrastructure | Configure hosts |
| **Lifecycle phase** | Day 0 | Day 1 and Day 2 |
| **Language** | HCL | YAML |
| **State** | Persistent state file | Stateless |
| **Plan step** | `tofu plan` shows diff before apply | None; tasks apply directly |
| **Drift detection** | Built in | Manual; re-run playbook to converge |
| **Transport** | OpenStack API | SSH to managed host |
| **Best at** | Declarative resource graphs, multi-environment fleets | Imperative host configuration, application deploys, OS hardening |
| **Quake AI status** | **Recommended for provisioning** | **Recommended for configuration** |

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`](https://docs.ansible.com/ansible/latest/collections/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:

| Component | Version requirement |
|---|---|
| `openstack.cloud` collection | `>= 2.2.0` (latest stable, currently 2.5.0) |
| `openstacksdk` Python library | `>= 1.0.0` |
| `ansible-core` | `>= 2.13` |
| Python | `>= 3.6` |

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](/docs/automation/how-to/ansible-provision-instance) 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](/docs/automation/how-to/ansible-opentofu-workflow). 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`:

```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](/docs/tools/generate-app-credentials).



Application credentials are scoped, rotatable, and do not embed your account password. Use them in any automation that runs unattended (CI pipelines, scheduled jobs, shared runners) and rotate them on a schedule.



## See also

- [How to get started with Ansible on Quake AI](/docs/automation/how-to/getting-started-ansible)
- [How to use Ansible with OpenTofu on Quake AI](/docs/automation/how-to/ansible-opentofu-workflow)
- [IaC on Quake AI: OpenTofu and Terraform](/docs/automation/concepts/iac-comparison)
- [How to get started with Infrastructure as Code](/docs/automation/how-to/getting-started-iac)
- [Generate app credentials](/docs/tools/generate-app-credentials)
- [`openstack.cloud` collection documentation](https://docs.ansible.com/ansible/latest/collections/openstack/cloud/)