💰 OpenStack Chargeback and Rating with CloudKitty and AI

Nothing focuses a finance team’s attention like the question “which team is actually spending all this compute?” — and for a long time my honest answer on our private OpenStack cloud was “no idea.” We had usage data scattered across Ceilometer and Gnocchi, but turning it into a number a project owner would believe was a manual spreadsheet nightmare. OpenStack CloudKitty is the rating-as-a-service project that fixed this: it collects metrics, applies pricing rules, and produces per-tenant cost reports you can actually send to someone.

CloudKitty is one of those projects where the concepts are simple but the configuration is dense — hydra-table mapping rules, collectors, fetchers. That density is exactly where an AI assistant helps: I describe the pricing policy in English, the model drafts the rating rules, and I verify every threshold before it influences a single invoice. The model is a fast junior engineer, not the CFO.

Confirming CloudKitty Is Collecting

Before you rate anything, you need data flowing. CloudKitty pulls from a collector (usually Gnocchi) and a fetcher (usually Keystone, to enumerate projects). Check the basics:

openstack rating module list
openstack rating info config get collect

The module list shows which rating modules are enabled — typically hashmap and maybe pyscripts. If hashmap is disabled, no rules apply and every cost comes out zero, which is the single most common “CloudKitty is broken” complaint I hear.

Enable it:

openstack rating module enable hashmap

Building HashMap Rating Rules

The HashMap module is the workhorse. You create a service (like compute or volume.size), then map field values or thresholds to a per-unit price. A small example: charge by instance flavor.

openstack rating hashmap service create instance
openstack rating hashmap field create <service-id> flavor_id
openstack rating hashmap mapping create 0.05 \
  --field-id <field-id> --value <flavor-uuid> --type flat

That says: every hour an instance of that flavor exists, add 0.05 to the bill. Thresholds work similarly for things like volume size — charge per GB above a tier.

This is the part I now hand to AI first. I give it our flavor list and the target hourly prices, and ask for the full set of mapping create commands. It produces them in seconds, correctly formatted, with the right --type flags. I then check each price against the agreed rate card. A misplaced decimal here means a 10x invoice, so this review is non-negotiable.

Pro Tip: Ask the AI to also generate a teardown script that deletes every mapping it created, keyed by the service name. When you are iterating on pricing, being able to wipe and re-seed the rules cleanly saves you from accumulating ghost mappings that quietly double-charge.

Reading the Reports

Once rules are live and a collection cycle has run, pull a summary:

openstack rating dataframes get -b <begin> -e <end>
openstack rating summary get --groupby project_id

The summary grouped by project is what goes to team leads. If a project you expect to see is missing, it almost always means CloudKitty’s fetcher could not enumerate it, or Gnocchi has no metrics for that period.

Debugging the “Everything Is Zero” Problem

Zeros are the classic CloudKitty failure, and there are only a few causes. I work through them in order, and I lean on AI to interpret the config dump:

1. The rating module is disabled (checked above).
2. The collector has no data — verify Gnocchi actually has the metrics CloudKitty expects.
3. The mapping references a field value that never appears in real usage (a typo’d flavor UUID).

openstack rating hashmap mapping list -s <service-id>
gnocchi metric list | head

I paste the mapping list plus a sample of Gnocchi metrics into a session with Claude and ask it to cross-check which mapped values actually occur in the data. It catches the dead mappings fast — that is genuinely the kind of tedious cross-referencing AI is good at. When a zero-cost report turns into a real incident (finance is waiting), I track the dig through my incident response dashboard so the root cause is recorded.

Handling Multiple Resource Types

A real cost model rates more than instances. You charge for volume GB-hours, floating IPs, network egress, object storage, and image storage — each its own CloudKitty service with its own mapping. Listing them confirms what you are actually rating:

openstack rating hashmap service list

The temptation is to rate everything from day one, which produces a confusing invoice nobody trusts. I start with the two or three resources that dominate cost — usually compute and block storage — and add the rest once the numbers are believed. When I do expand, I describe the new service and its rate to the AI, it generates the service create, field create, and mapping create chain, and I verify each price against the rate card. The model is good at producing the full command sequence consistently; I am the one who owns whether 0.01 per GB-hour is the right number. Getting the set of rated resources right is as important as getting each price right — an unrated resource is a silent subsidy.

Showback Versus Chargeback

Two modes, and the distinction matters politically more than technically. Showback publishes costs without billing anyone — great for changing behavior. Chargeback actually moves money. I always start a new CloudKitty deployment in showback for a month so teams can dispute the numbers before any invoice is real. Your rating rules are identical; only the downstream consumer changes.

Keeping the Human in the Loop

CloudKitty is read-only with respect to your cloud — it never provisions or deletes — so the blast radius is smaller than something like Mistral. But the trust radius is huge: people make budget decisions off these numbers. So my guardrails are about correctness, not destruction:

• The AI drafts rating rules and report queries; it never holds production Keystone credentials.
• Every price change is reviewed against a signed rate card.
• I diff the new ruleset against the old one before applying — a script the model is happy to generate.

I keep my vetted CloudKitty prompts in the prompt workspace and the reusable templates in the OpenStack prompt pack. When I am wiring rules into config files, GitHub Copilot handles the inline completion nicely.

Where This Leaves You

With CloudKitty configured and an AI helping draft the rating math, our monthly cost conversation went from a guessing match to a one-command report. The pattern is the same one I use everywhere on this cloud: describe intent in English, let the model expand the tedious configuration, then review like the numbers matter — because here, they really do.

The cultural payoff outlasts the technical one. Once teams can see their own spend, behavior changes on its own — idle instances get deleted, oversized volumes get trimmed, and nobody has to send a scolding email. CloudKitty gives you the numbers; the AI makes producing and validating those numbers fast enough that you actually keep doing it month after month instead of letting the rate card rot. A cost model that is maintained is worth ten times one that was perfect once and then abandoned.

If you want CloudKitty stood up properly against a real chargeback model, work with me, or keep reading through the OpenStack category and the broader prompt library.