Skip to content

Cluster Workflows

Cluster workflows are the pipelines that drive the Cluster Lifecycle. They follow the same structural patterns as Universal Workflows but operate at the cluster level, coordinating actions across a group of machines rather than a single machine.

Standard Cluster Workflow Chain

DRP provides two standard cluster workflow entry points:

  • universal-cluster-provision — Creates and provisions a new cluster
  • universal-cluster-destroy — Destroys an existing cluster and releases its machines

These workflows use universal-start / universal-destroy entry points internally and execute cluster-specific stages in addition to per-machine tasks.

Provisioning Flow

  1. A Cluster object is created with a workflow set to universal-cluster-provision
  2. The cluster workflow requests machines from a Resource Broker, which allocates them from a Pool
  3. Each allocated machine is registered in DRP with the cluster's tracking profile (cluster/tags)
  4. Per-machine pipelines run on each member (discovery, OS install, application deployment)
  5. Cluster-level stages run to finalize cross-machine configuration (e.g., Kubernetes control plane setup)
  6. On completion, WorkflowComplete is set on the Cluster object

Destroy Flow

  1. The cluster workflow is set to universal-cluster-destroy
  2. Cluster-level teardown stages run (e.g., drain nodes, remove from platform API)
  3. The Resource Broker releases each machine back to its Pool
  4. Pool release transitions run on each machine (wipe, re-image, or return to free state)

Reuse of Machine Lifecycle Patterns

Cluster workflows deliberately reuse machine-level pipeline elements:

  • Each cluster member runs the same universal-discover or universal-start workflow as standalone machines
  • Classification and FlexiFlow extension points work identically
  • Hardware configuration, OS installation, and application deployment stages are shared

The cluster layer adds coordination: waiting for quorum, sequencing control-plane vs. worker provisioning, and managing cluster-level state across members.

WorkOrder Mode After Provisioning

Once provisioned, a cluster is typically placed in WorkOrder Mode. In this mode, the cluster no longer processes workflows and instead accepts WorkOrders for ongoing operations:

  • Kubernetes application deployments
  • Cluster resize (add/remove nodes via Resource Broker)
  • Rolling updates

See Work Order Mode for the execution model.

See Also