Marketplace
Overview
The Waldur Marketplace is the catalog and order pipeline through which projects request resources from service providers. It connects the platform primitives (users, organizations, projects) to backend systems (OpenStack, SLURM, Rancher, remote Waldur instances, and others) through a uniform offering → order → resource flow.
Architecture
The four boxes correspond to four Django apps: structure, marketplace, marketplace.processors, and invoices.
Key concepts
| Concept | One-liner | Reference |
|---|---|---|
| Offering | A service published by a service provider (VM family, HPC allocation, ticket queue, ...). | Glossary |
| Plan | One pricing and limits option attached to an offering. | Glossary |
| Order | A request to provision, modify, or terminate a resource. | Lifecycle |
| Resource | The provisioned instance produced by a fulfilled order. | Lifecycle |
| Plugin | The backend integration that an offering binds to (OpenStack, SLURM, ...). | Plugins |
| Invoice item | The billing record generated from a resource's usage. | Billing |
Offering requirements
An offering becomes orderable once it has:
- A category (controls where it appears in the catalogue).
- One or more plans (defines pricing and limits).
- Components (the metered or billed units — vCPU, GB-month, CPU-hours, ...).
- A plugin type and matching service settings.
- Visibility rules (public, per-customer, per-project).
Custom request-form attributes are optional.
Plugins
The Marketplace is plugin-driven. Plugins shipped with Waldur include:
| Plugin | What it provisions |
|---|---|
openstack |
Tenants, VMs, volumes, networks, floating IPs |
slurm |
HPC allocations (CPU/GPU hours, storage) |
rancher |
Kubernetes clusters via Rancher |
azure, vmware |
VMs on the respective backend |
openportal |
Federated HPC accounts via the OpenPortal protocol |
remote |
Resources hosted on another Waldur instance |
support |
Ticket-backed offerings |
script |
Arbitrary scripted provisioning |
site-agent |
Anything brokered by waldur-site-agent |
Service providers can add new plugins by implementing the marketplace processor interface — see the developer guide.
Approval and policies
Orders may be auto-approved, gated by an organization owner, or vetoed by a policy (cost limit, usage limit, blacklist). Per-project auto-approval is configurable.
Resource lifecycle
Orders and resources have their own state machines — see the dedicated Lifecycle page.
Related concepts
- Platform — users, organizations, projects.
- Call management — proposal-driven allocation that ends in marketplace orders.
- Lifecycle — order and resource state machines.
Examples
Requesting a VM
- Open the Marketplace and filter by Virtual Machines.
- Pick an OpenStack offering and a plan.
- Fill in the request form (name, SSH key, flavor).
- Submit. After approval, the VM appears in the project.
HPC allocation
- Open the SLURM allocation under the project.
- Check current CPU-hour and storage usage.
- Modify the resource to request more hours if needed.
Cost control
Use policies to cap monthly spend per project rather than relying on after-the-fact invoice review.