Skip to content

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, while most policy actions react to facts after the fact within a period (this month's spend, this quarter's CPU-hours, this year's storage).

The one exception is the block_creation_of_new_resources action on cost policies: it is also evaluated synchronously at order submission, so an order that would push the projected period total above the limit is rejected with 400 Bad Request before any resource or order row is persisted. The other actions (notify, terminate, throttle, …) still run from the post-invoice trigger.

Model

OrganizationProjectOfferingPolicyTrigger(invoice item, usage report)Period(month / quarter / year / total)NotifyBlock further ordersTerminate resources attached toevaluated byscoped to
OrganizationProjectOfferingPolicyTrigger(invoice item, usage report)Period(month / quarter / year / total)NotifyBlock further ordersTerminate resources attached toevaluated byscoped to

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. Enforced synchronously at order submission — including update_limits and switch_plan orders that would increase cost.
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

  1. Staff (or organization owner, for project-scoped policies) defines a policy: scope, trigger, limit, period, actions.
  2. Waldur evaluates the policy each time a new trigger arrives (e.g. an invoice item is written, a SLURM usage report is ingested).
  3. When the threshold is crossed, the configured actions execute. A has_fired flag prevents repeated firing in the same period.
  4. At the next period boundary the flag resets.
  • 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.