Skip to content

Resource lifecycle

Overview

Every marketplace order moves through a fixed state machine; once an order succeeds, the resource it creates has its own state machine. Operators and integrators rely on these two state machines to interpret webhook events, debug stuck provisioning, and write policies.

Order states

pendingconsumerpendingproviderpendingprojectpendingstart dateexecutingdoneerredcanceledrejected consumer approvesconsumer rejectsprovider approvesprovider rejectsproject approvesstart date reacheduser cancels
pendingconsumerpendingproviderpendingprojectpendingstart dateexecutingdoneerredcanceledrejected consumer approvesconsumer rejectsprovider approvesprovider rejectsproject approvesstart date reacheduser cancels
State Code Meaning
pending-consumer 1 Awaiting approval from the consumer organization.
executing 2 Backend provisioning in progress.
done 3 Resource provisioned successfully.
erred 4 Provisioning failed; admin or retry needed.
canceled 5 User canceled before processing.
rejected 6 Approval denied.
pending-provider 7 Awaiting approval from the service provider.
pending-project 8 Awaiting in-project approval (when configured).
pending-start-date 9 Approved but waiting for the configured start date.

Resource states

CreatingOKErredUpdatingTerminatingTerminated modify orderterminate orderretry
CreatingOKErredUpdatingTerminatingTerminated modify orderterminate orderretry
State Code Meaning
Creating 1 Initial provisioning underway.
OK 2 Steady state; usage being reported.
Erred 3 Last operation failed; resource is in an inconsistent state.
Updating 4 A modify order is being applied.
Terminating 5 Cleanup in progress.
Terminated 6 Resource removed from the backend; record retained for billing.

Resource status badge

Resource lists and the resource page show a status badge next to each resource's name. The badge draws on up to three sources:

Source Set for Values
Resource state Every resource The states in the table above.
Backend state Resources managed through a built-in plugin, such as OpenStack, VMware and Rancher Waldur's record of the provider-side object: OK, ERRED, CREATING and so on, or Deleted once the object is gone.
Runtime state The same resources What the provider reports, in its own words: ACTIVE, SHUTOFF or ERROR for an OpenStack instance, in-use or error_extending for a volume, POWERED_OFF for a VMware VM.

Resources managed through a site agent have no backend or runtime state, so their badge shows the resource state.

The badge shows the first of these that applies:

  1. Erred, in red, when any source reports a failure.
  2. Terminated, or Deleted when the provider-side object has been removed.
  3. The runtime state, such as Active, Shutoff or Powered off: grey for a stopped resource, green otherwise. Without a runtime state, the badge shows the backend or resource state, for example OK.

Hover over an Erred badge to see which source failed:

Tooltip Cause
The provider reports this resource as state. The runtime state is an error, such as an instance in ERROR or a volume in error_extending.
An operation on the provider side failed. The backend state is ERRED.
The last operation on this resource failed. The resource state is Erred, for example after a failed order.

When more than one source has failed, the tooltip names the first in this table. The resource's error message follows, when there is one.

Erred takes precedence even when the provider reports the resource as running: the last operation failed, so the resource may not match what was ordered. If the provider-side object recovers, Waldur's next sync with the provider returns the resource to OK. Otherwise, retry the failed operation, or a staff user or the service provider can set the resource back to OK.

A spinner on the badge means Waldur is still working on the resource: an order is creating, updating or terminating it, or a provider-side operation has not finished. When the provider reports which operation it is running, the tooltip names it.

Recovering an erred order

A staff user can retry an erred order from the UI or via the API. Retry locks the row, re-checks the state inside a transaction, and re-enqueues the backend operation — see the backend concurrency guidance for the implementation detail.

  • Marketplace — where orders originate.
  • Policies — automated reactions to state changes (e.g. terminate on overspend).
  • Call management — proposals that produce orders on approval.