AWX Automation

The Query Builder reads state out of ACI. AWX Automation is the other direction: pushing configuration in, using the playbooks you've already written. Fabrik doesn't replace Ansible — it sits in front of your existing AWX or Ansible Tower deployment and turns "launch this job template with these variables" into a guided, validated, auditable flow.

What Fabrik adds on top of AWX

AWX is excellent at running playbooks. It's less excellent at the user-facing side of a multi-tenant operations team: spreadsheet-style input, per-row validation, approval chains, searchable execution history. Fabrik fills that gap.

• Structured input — spreadsheet-like tables with typed columns instead of free-form extra_vars JSON.
• Reusable validation — regex patterns, static allowed-value lists, or live APIC queries, shared across templates.
• Approval workflow — optional per-template approver gate before execution.
• Bulk execution — all rows go to AWX in one job launch; no manual per-row babysitting.
• Live monitoring — real-time playbook output streamed back into the browser via WebSocket.
• Per-host outcomes — the rows that succeeded and the rows that failed, surfaced after the run.
• Audit trail — who launched what, with what data, from which IP, and what AWX ultimately did.

Fabrik never holds device credentials. The AWX credential you pick at launch stays inside AWX's own vault — Fabrik just references it by ID. See Connections for the details.

The four moving parts

AWX automation in Fabrik is four objects that chain together.

The one-line mental model: Connection is where AWX lives. Template is what to run. Request is a specific "run this." Execution is the AWX job itself.

Bulk execution, end to end

When a user submits a request, Fabrik:

1. Validates every row against the template's rules (regex / static list / query list).
2. Freezes a snapshot of the template config onto the request (so later edits don't change what runs).
3. Either queues the request for approval, or hands it straight to a Celery worker.
4. The worker launches one AWX job with all rows embedded as structured extra_vars.
5. A job-events poller streams AWX output into JobOutputChunk rows and pushes it over WebSocket.
6. When the job finishes, per-host outcomes are parsed from AWX artifacts and written back to the execution.

Per-row and hybrid execution modes existed historically and were removed — bulk is now the only mode. All rows, one job, one set of extra_vars, one execution record.

When to reach for AWX automation

Typical signals:

• You already have Ansible playbooks. AWX automation lets non-Ansible users launch them safely. No new tooling to learn on the operations side.
• The operation is bulk. Creating 50 tenants, adding 200 static paths to EPGs, rolling out a config change across many devices. The spreadsheet input model fits.
• Input validation matters. Tenant name conventions, VLAN ranges, leaf node IDs — things that are painful to catch in the playbook itself but trivial to catch at the form.
• You need an audit trail. Who ran what, when, from where, against which APIC, with which data. Request metadata + execution history covers it.

And when not to:

• You're just reading state. Use the Query Builder. AWX isn't the right tool for a fact-gathering task you don't need to repeat at scale.
• You want one-off ad-hoc commands. AWX templates are the unit of work. Bypass Fabrik and use AWX directly if you just want to launch something without building a schema.

Continue reading

---

Start with Connections — nothing in this section works without at least one AWX server hooked up.