Policies
Overview
Policies are automated reactions to events on marketplace resources — typically to cap cost, cap usage, or terminate a misbehaving resource. They run alongside quotas: a quota refuses an action up front, a policy reacts to facts after the fact within a period (this month's spend, this quarter's CPU-hours, this year's storage).
Model
Key concepts
| Concept | One-liner |
|---|---|
| Policy | A rule attached to a project, customer, or offering scope. |
| Trigger | The signal that evaluates the policy — typically a new invoice item or usage report. |
| Period | The window the trigger sums data over — month, quarter, year, or total. |
| Action | What happens when the policy fires. |
| Action type | Threshold (warn at N%, fire at 100%) or immediate (act the moment a condition is met). |
Action catalogue
| Action | Effect |
|---|---|
| Notify project / customer | Email the project members or organization owners. |
| Block creation of new resources | Refuse new orders on the affected scope. |
| Terminate resources | Cancel running resources to stop the bleeding. |
| Block SLURM jobs | (HPC) Pause new job submissions until consumption drops. |
| Custom | Any action wired in via the policy plugin interface. |
A single policy can attach multiple actions.
Lifecycle
- Staff (or organization owner, for project-scoped policies) defines a policy: scope, trigger, limit, period, actions.
- Waldur evaluates the policy each time a new trigger arrives (e.g. an invoice item is written, a SLURM usage report is ingested).
- When the threshold is crossed, the configured actions execute. A
has_firedflag prevents repeated firing in the same period. - At the next period boundary the flag resets.
Related concepts
- Quotas — up-front bounds; pair with policies for defence in depth.
- Marketplace — what policies guard.
- Billing — invoice items are the primary trigger for cost policies.
- Lifecycle — the resource state transitions an "immediate" policy can drive.