Configuration Reference
This document provides a complete reference for configuring Waldur Site Agent. It's a reference, not a tutorial — if this is your first setup, start with the Quickstart instead and come back here once something needs a field this page covers but the Quickstart didn't.
Required in every offering, regardless of backend: name,
waldur_api_url, waldur_api_token,
waldur_offering_uuid, a *_backend setting for each process you run
(e.g. order_processing_backend), and at least one entry under
backend_components. Everything else on this page — global settings,
event processing, resource management, backend-specific backend_settings, and the ~15 optional
component fields — has a working default and can be added when you actually need it.
Configuration File Structure
The agent uses a YAML configuration file (waldur-site-agent-config.yaml) with the following structure:
1 2 3 4 5 | |
Global Settings
sentry_dsn
- Type: String
- Description: Data Source Name for Sentry error tracking
- Default: Empty (disabled)
- Example:
"https://key@sentry.io/project"
elastic_apm_server_url
- Type: String
- Description: Elastic APM server URL. When set, enables Elastic APM monitoring with automatic instrumentation.
- Default: Empty (disabled)
- Example:
"https://apm-server.example.com:8200"
timezone
- Type: String
- Description: Timezone for billing period calculations
- Default: System timezone
- Recommended:
"UTC" - Examples:
"UTC","Europe/Tallinn","America/New_York"
Note: Important when agent and Waldur are deployed in different timezones to prevent billing period mismatches at month boundaries.
Offering Configuration
Each offering in the offerings array represents a separate service offering.
Basic Settings
name
- Type: String
- Required: Yes
- Description: Human-readable name for the offering
waldur_api_url
- Type: String
- Required: Yes
- Description: URL of Waldur API endpoint
- Example:
"http://localhost:8081/api/"
waldur_api_token
- Type: String
- Required: Yes
- Description: Token for Waldur API authentication
- Permissions: The token user must have OFFERING.MANAGER role on the offering specified by
waldur_offering_uuid. This grants the permissions needed for order processing, usage reporting, membership sync, and event subscriptions. - Security: Keep this secret and secure
verify_ssl
- Type: Boolean
- Default:
true - Description: Whether to verify SSL certificates for Waldur API
waldur_offering_uuid
- Type: String
- Required: Yes
- Description: UUID of the offering in Waldur
- Note: Found in Waldur UI under Integration -> Credentials
- Supported offering types: Waldur accepts an agent identity only for an offering whose type
is
Waldur site agent(Marketplace.Slurm),Script(Marketplace.Script),Basic(Marketplace.Basic) orOpenStack tenant(OpenStack.Tenant). Point an agent at any other type — a service desk offering, say — and identity registration is refused with a misleading400 Object with uuid=... does not exist, even though the offering is there. The agent logs a warning and carries on syncing without agent telemetry; see Agent Identity Registration Is Refused. The set of accepted types is a property of the Waldur server, so it can differ between Waldur versions.
Backend Configuration
backend_type
- Type: String
- Required: Yes for legacy configurations
- Values:
"slurm","moab","mup" - Description: Type of backend (legacy setting, use specific backend settings instead)
Backend Selection
Configure which backends to use for different operations:
1 2 3 4 | |
Available backends (via entry points):
"slurm": SLURM cluster management"moab": MOAB cluster management"mup": MUP portal integration"waldur": Waldur-to-Waldur federation"base": Basic username management"rancher": Direct Rancher REST API integration (single offering = one cluster)"ceph_s3": Ceph S3 storage (croit and RadosGW flavours)"digitalocean": DigitalOcean droplets"azure": Azure virtual machines. Seeplugins/azure/README.md."rancher-kc-crd": CRD-driven Rancher + Keycloak management via therancher-keycloak-operator. Membership-sync only; targets multiple clusters per offering by readingcluster_idfrom each Resource'sbackend_id. Seeplugins/rancher-kc-crd/README.md.- Custom backends via plugins
Note: If a backend setting is omitted, that process won't start for the offering.
Event Processing
stomp_enabled
- Type: Boolean
- Default:
false - Description: Enable STOMP-based event processing
stomp_membership_sync_enabled
- Type: Boolean or null
- Default:
null(inheritsstomp_enabled) - Description: Controls whether membership sync uses STOMP events or HTTP
polling. When
stomp_enabledistruethis defaults totrueas well. Set tofalseto keep HTTP polling for membership sync while using STOMP for order processing. - Note: Setting this to
truewhilestomp_enabledisfalseleaves membership sync with no runner at all — the polling agent skips it (assuming STOMP owns it) and the STOMP consumers never start. The agent logs aMISCONFIGURATIONwarning on startup if it sees this combination.
websocket_use_tls
- Type: Boolean
- Default:
true - Description: Use TLS for websocket connections
Resource Management
resource_import_enabled
- Type: Boolean
- Default:
false - Description: Whether to expose importable resources to Waldur
preserve_unmanaged_backend_users
- Type: Boolean
- Default:
false - Description: Controls how membership sync treats backend users who are
not on the Waldur resource team. When
false(default), any such user is removed. Whentrue, users Waldur has ever known as offering users of this offering (any state, includingDELETEDand restricted) are removed once they leave the team; accounts Waldur has never seen — for example people the service provider added locally because Waldur validation blocked their offering user — are kept. Applies to every local-username backend (SLURM, MOAB, MUP, OKD, Harbor, …). Ignored for identity-bridge / Waldur-to-Waldur federation.
Common Backend Settings
These settings can be used in backend_settings for any backend type.
check_backend_id_uniqueness
- Type: Boolean
- Default:
false - Description: Enable checking that the generated backend ID is unique across offering history before creating a resource. When enabled, the agent queries Waldur to verify uniqueness and retries with a new ID on collision.
check_all_offerings
- Type: Boolean
- Default:
false - Description: When
check_backend_id_uniquenessis enabled, check uniqueness across all customer offerings instead of only the current offering.
backend_id_max_retries
- Type: Integer
- Default:
50 - Description: Maximum number of retry attempts when generating a unique
backend ID. Applies when
check_backend_id_uniquenessis enabled or theproject_slugaccount name generation policy is used. Set to a lower value if collisions are rare or a higher value for large deployments.
Account name generation vs. resource slug templates
The offering's account_name_generation_policy plugin option (set in Waldur,
not in the agent config) controls how the agent derives a resource's backend ID
(e.g. the SLURM account name):
- Unset (default) — the agent uses the resource's slug verbatim:
{allocation_prefix}{resource_slug}. If the offering also defines aresource_slug_template(e.g.{project_slug}-{counter}), the slug is already unique and is used as-is, with no extra suffix. project_slug— the agent ignores the resource slug and instead derives the backend ID from the project slug, appending an incrementing-{counter}on each collision to disambiguate multiple resources in the same project.
Warning:
account_name_generation_policy: project_slugandresource_slug_templateare two mutually exclusive ways to make backend IDs unique. If you set both, theproject_slugpolicy wins and appends its own counter on top of (and ignoring) your template — producing IDs likeprefix-test-prj-01-2-31. If you use aresource_slug_template, leaveaccount_name_generation_policyunset so the unique slug is used directly.
Backend-Specific Settings
SLURM Backend Settings
1 2 3 4 5 6 7 8 9 10 11 12 | |
MOAB Backend Settings
1 2 3 4 5 6 | |
MUP Backend Settings
1 2 3 4 5 | |
Waldur Federation Backend Settings
The target_api_token user must be a customer owner (can be a non-SP customer
separate from the offering's service provider) and an ISD identity manager
(is_identity_manager: true with managed_isds set). Access to the target
offering's users is granted via ISD overlap, not via OFFERING.MANAGER.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | |
Backend Components
Define computing components tracked by the backend:
1 2 3 4 5 6 7 8 9 10 11 12 | |
Component Settings
measured_unit
- Type: String
- Description: Unit displayed in Waldur
- Examples:
"k-Hours","gb-Hours","EUR"
unit_factor
- Type: Number
- Description: Factor for conversion from Waldur units to backend units
- Examples:
60000for CPU (60 * 1000, converts k-Hours to CPU-minutes)61440for memory (60 * 1024, converts gb-Hours to MB-minutes)
accounting_type
- Type: String
- Values:
"usage","limit", or"one" - Description: Controls billing type and backend behavior.
"usage"for usage-based tracking,"limit"for fixed allocation caps,"one"for prepaid ONE_TIME billing (automatically setsis_prepaid: truein Waldur).
label
- Type: String
- Description: Human-readable label displayed in Waldur
limit
- Type: Number
- Optional: Yes
- Description: Fixed limit amount for limit-type components
description
- Type: String
- Optional: Yes
- Description: Description of the component shown in Waldur
min_value
- Type: Integer
- Optional: Yes
- Description: Minimum allowed value for the component
max_value
- Type: Integer
- Optional: Yes
- Description: Maximum allowed value for the component
max_available_limit
- Type: Integer
- Optional: Yes
- Description: Maximum available limit for the component
default_limit
- Type: Integer
- Optional: Yes
- Description: Default limit value applied when creating a resource
limit_period
- Type: String
- Optional: Yes
- Values:
"annual","month","quarterly","total" - Description: Billing period for limit enforcement
article_code
- Type: String
- Optional: Yes
- Description: Article code for billing system integration
is_boolean
- Type: Boolean
- Optional: Yes
- Description: Whether the component represents a boolean (on/off) option
is_prepaid
- Type: Boolean
- Optional: Yes
- Description: Whether the component requires prepaid billing.
Automatically set to
truewhenaccounting_type: "one".
min_prepaid_duration
- Type: Integer
- Optional: Yes
- Description: Minimum initial prepaid duration in months. Only applies when
accounting_type: "one".
max_prepaid_duration
- Type: Integer
- Optional: Yes
- Description: Maximum initial prepaid duration in months. Only applies when
accounting_type: "one".
prepaid_duration_step
- Type: Integer
- Optional: Yes
- Description: Step size in months for initial duration.
If set, only multiples of this value
(starting from
min_prepaid_duration) are valid. For example,min_prepaid_duration: 3andprepaid_duration_step: 3allows 3, 6, 9, 12 months.
min_renewal_duration
- Type: Integer
- Optional: Yes
- Description: Minimum renewal duration in months.
max_renewal_duration
- Type: Integer
- Optional: Yes
- Description: Maximum renewal duration in months.
renewal_duration_step
- Type: Integer
- Optional: Yes
- Description: Step size in months for renewal.
Only multiples of this value
(starting from
min_renewal_duration) are valid.
Prepaid Billing
Prepaid billing allows customers to pay upfront for a fixed
capacity over a specified duration.
Prepaid components use accounting_type: "one" which maps
to Waldur's ONE_TIME billing type and automatically sets
is_prepaid: true.
When a component has accounting_type: "one",
the following flow applies:
- Ordering: Customer orders a resource with limits
and an
end_date. Waldur validates the duration against component constraints. - Upfront billing: Waldur creates a single invoice item for the full subscription period (limit × price × months).
- Backend enforcement: The site agent calculates
GrpTRESMins = limit × duration_months × unit_factorand sets it on the SLURM account. This gives SLURM a cumulative budget cap for the subscription period. - Limit changes: Customer can request more capacity. Waldur creates supplementary invoice items. The agent recalculates GrpTRESMins with the new limits and remaining duration.
- Renewal: Customer extends the subscription.
The agent detects the new
end_dateand recalculates GrpTRESMins with the extended duration. - Termination: When
end_dateis reached, Waldur automatically creates a TERMINATE order.
Backend-Specific Component Notes
SLURM: Supports cpu, mem, and other custom components
MOAB: Only supports deposit component
1 2 3 4 5 | |
Environment Variables
Override configuration values using environment variables:
Agent Timing
WALDUR_SITE_AGENT_ORDER_PROCESS_PERIOD_MINUTES: Order processing period (default: 5)WALDUR_SITE_AGENT_REPORT_PERIOD_MINUTES: Reporting period (default: 30)WALDUR_SITE_AGENT_MEMBERSHIP_SYNC_PERIOD_MINUTES: Membership sync period (default: 5)
Monitoring
SENTRY_ENVIRONMENT: Environment name for Sentry
Example Configurations
SLURM Cluster
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | |
MOAB Cluster
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | |
Event-Based Processing
1 2 3 4 5 6 7 8 9 10 | |
Waldur-to-Waldur Federation
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | |
Validation
Validate your configuration:
1 2 3 4 5 | |