Understand
Architecture, research, and technical guides that explain how the stack behaves.
- Architecture explainers
- Original research
- Technology deep dives
AI engineering · Infrastructure · Operations
Engineering guides, production infrastructure, hands-on labs, and AI-powered operations tools for the systems behind modern AI.
The map
Every layer assumes something about the layer below it, and production is the process of finding out which assumption broke. Select a layer to see what it owns and where it fails.
The AI Stack
8 layers · select one
L8 · AI Engineering
The product surface. Agent loops, tool calling, and orchestration — where non-determinism meets a user who expects a correct answer.
The workbench
Not a dashboard full of green checkmarks. A real diagnostic path: signals, correlation, a specific hypothesis, and the commands that confirm or kill it.
Reported problem
Volume creation fails immediately. Every new volume lands inerror state.
Service health
Evidence
$ openstack volume service list
+------------------+---------------+---------+
| Binary | Host | State |
+------------------+---------------+---------+
| cinder-scheduler | ctl1 | up |
| cinder-volume | ctl1@ceph | down |
+------------------+---------------+---------+
$ docker logs --tail 3 cinder_scheduler
WARNING cinder.scheduler.host_manager
No backend capabilities reported for ctl1@ceph
ERROR cinder.scheduler.filter_scheduler
No valid backend was found. Exceeded max scheduling
attempts 3 for volume 8f2c...Probable root cause
The scheduler has no candidate backends. cinder-volume stopped reporting capacity, so capacity filtering returns zero valid candidates and every request fails scheduling rather than provisioning.
The API is healthy and the scheduler is running, which is why dashboards stay green. The failure is a silent one: a service that is up but no longer participating.
What to check, in order
Next
The analyzer runs entirely in your browser. Pasted output never leaves your machine.
What you can do here
Four modes of work, each backed by real material rather than a marketing category.
Architecture, research, and technical guides that explain how the stack behaves.
AI engineering, automation, infrastructure, and deployment practice you can apply directly.
Incident response, monitoring, runbooks, and the diagnostic method behind them.
Academy learning paths, hands-on labs, and validated progression.
AI operations workbench
Paste a Terraform plan, a Dockerfile, or command output and get back an analysis. Nothing you paste leaves your machine, which is also why these work without an account.
Find destructive and high-risk changes in a Terraform plan before you apply it.
Terraform · OpenTofu
Check a Dockerfile against production-readiness rules.
Docker · OCI · Containers
Turn service and agent listings into a ranked view of what is actually broken.
OpenStack · Nova · Neutron
Generate Prometheus alerting rules that will not page you for nothing.
Prometheus · Alertmanager · Grafana
A searchable library of engineering prompts, kept inside the application.
LLM · Incident Response · Kubernetes
Incident Analyzer, Infrastructure Review, Runbook Assistant — these need server-side inference we have not stood up. They are listed so the roadmap is visible, not because they work.
Inside The AI Stack Academy
Academy tracks are sequenced: objectives, architecture, commands, failure modes, a hands-on exercise, and a validation step you can actually run. We launch a track when it is complete, not when its landing page is.
A sequenced learning path for engineers who operate OpenStack in production — architecture, service-by-service depth, deployment, and troubleshooting under pressure.
A service crash-looping after a routine config change, with logs that show a normal startup and no error anywhere. Work out what is killing it.
Instances stopped building on a cloud with visible free capacity. Work the evidence, form hypotheses, and find why the scheduler has no candidates.
Operate
Runbooks written to be followed under pressure, and labs that drop you into the failure before telling you the answer.
Diagnose and remediate OpenStack volume creation failures caused by the scheduler having no candidate backends, including the case where the API reports healthy.
A structured procedure for a pod that will not stay running, covering exit-code classification, probe-induced restarts, OOM kills, and validation that the fix held.
Find what is consuming a full filesystem, reclaim space safely including the deleted-but-open-file case, and validate before the host causes wider failures.
A service crash-looping after a routine config change, with logs that show a normal startup and no error anywhere. Work out what is killing it.
Instances stopped building on a cloud with visible free capacity. Work the evidence, form hypotheses, and find why the scheduler has no candidates.
A routine-looking Terraform pull request. Find the changes that would destroy data before you approve it, and work out which one is not what it appears to be.
Cornerstone resources
Deep, consolidated guides rather than a page per keyword. Each one is intended to be the last thing you need to read on its topic.
Building container images for production: reproducible builds, correct signal handling, non-root runtime, layer strategy, and keeping secrets out of image history.
What determines accelerator performance in production: memory capacity versus bandwidth, interconnect topology, and the checks that find a misplaced workload.
Operating OpenStack in production: service state versus status, the message bus, placement disagreements, and the quiet failures that keep dashboards green.
AI infrastructure
Accelerators, interconnects, storage, and the private cloud control planes underneath them — written from the operator's side.
Collective communication, RDMA, and rail topology explained from the operator's side, including why adding nodes to a training job can make it slower.
What determines accelerator performance in production: memory capacity versus bandwidth, interconnect topology, and the checks that find a misplaced workload.
How Kolla-Ansible actually structures an OpenStack deployment, where configuration comes from, and how to make changes without discovering them during an outage.
Research
Research is published with its methodology, its environment, and its raw data. Projects that have not been run yet are listed as exactly that — announced, not pretended.
A planned survey of how teams actually operate AI infrastructure in production — what breaks, what is measured, and where engineering time goes. Not yet conducted.
A planned recurring measurement of accelerator pricing across cloud providers, normalised so the comparison is meaningful. Methodology published before data collection begins.
Why trust this
We have no customer logos to show you and will not invent any. What we can show is how we work.
Author, reviewer, published date, updated date, and last-verified date on every technical resource. Where a procedure was executed, the exact versions are listed. Where it was not, we say so on the page.
How we test →A URL becomes indexable only after passing a ten-point editorial gate. Most of what we hold stays inside the application, searchable here and absent from the sitemap. Database size is not sitemap size.
Editorial policy →AI helps with research organisation, drafting, and editing. No technical content is published as reviewed without a human engineer reviewing it, and pages awaiting review say so in a banner.
AI use policy →Newsletter
A practical weekly briefing on AI engineering, infrastructure, production operations, and the technologies powering the AI stack.
One email a week. No sponsorship placements inside the technical sections. Unsubscribe in one click.
Pro
Everything in the Academy, advanced labs, the full runbook library, and saved investigations once accounts ship. Free access covers the guides, the working tools, and the introductory labs.