Skip to content

Provisioning Pipeline

The Provisioning Pipeline is the core automation engine of Digital Rebar Provision. It defines how machines are driven from any state to a desired end state through composable, reusable workflow components.

In This Section

Execution engine — the primitives:

  • Pipeline Architecture — Pipelines, Universal Applications, entry/exit points, execution phases, and naming conventions
  • Workflow Mode — How Tasks, Jobs, Stages, and Workflows work together; the agent state machine
  • Work Order Mode — Task-mode WorkOrders: Machine as Service, Orchestrated Tasks, CI/CD pipelines
  • WorkOrder Workflow Mode — Workflow-mode WorkOrders: Pipeline lifecycle, restart-via-successor, batch fan-out
  • Runner Modes Overview — Comparison of Workflow and WorkOrder execution modes

Convention layer — programming the engine:

  • Universal Workflow — The Universal Workflow convention layer: naming, layout, chaining, classification, and defaults used by content packs to compose the primitives above into reusable applications

See Also

Pipeline Architecture

This document provides an architectural overview of Digital Rebar Provision (DRP) Pipelines and Universal Applications, covering their design principles, components, and implementation patterns.

Pipelines

A Pipeline defines a machine's target end state and the multi-phase chain used to reach it. DRP is moving toward expressing this as a first-class typed Pipeline object: a declarative object that carries the phase-workflow lists for each phase (in its Params) but holds no run state, timing, or history, inherits from parent Pipelines through its Pipelines field (a child overrides its parents), and is tracked as the single active Machine.Pipeline.

This typed object is the direction of travel and coexists with the established delivery model, in which a Pipeline is a Profile linked to a Universal Application whose parameters define the target state. The two are not in conflict: the typed Pipeline embeds profile data and carries the same intent. Most shipped content still selects a Universal Application through the profile model, while the typed object is introduced for new pipelines. Content authored either way drives the same phase execution described below.

Universal Applications

Universal Applications are created with safe default values and provide the flow of work to achieve an end state. That flow is organized into sequential phases (an opt-in prepare phase followed by discover, hardware, OS install, and application) described under Pipeline Execution Phases. Pipelines most often add to or override these defaults to provide a customized end state. For example if a Universal Application has the workflows to install a Linux operating system the Pipeline might have parameters to set the specific distribution, version and source.

Universal Application Workflow Entry Points

Universal Applications are designed with standardized entry points to ensure consistent behavior across different infrastructure machines, for example physical or virtual. Understanding these entry points is crucial for Pipeline architecture because they determine how your automation workflows begin execution.

DRP provides several universal workflows that can serve as these entry points:

  • universal-prepare - Runs the prepare phase before discover, for out-of-band setup (for example powering a machine on and bringing it to PXE) that must execute in a separate Context rather than on the machine itself. The phase is opt-in and skipped by default: set universal/prepare-phase-context to the Context and populate universal/prepare-phase-workflows with the prepare work to enable it.

  • universal-discover - Used for new or redeployed infrastructure that needs to boot into the Sledgehammer discovery environment before installing an operating system. This is commonly used for bare metal systems, PXE boot scenarios, or complete system rebuilds.

  • universal-start - Used for systems that already have an operating system installed and can execute workflows locally. This is typically used for existing infrastructure, virtual machines, or systems that have already been provisioned.

  • universal-evaluate - Used for system discovery, classification, and inventory collection. Expects Sledgehammer boot environment (though not enforced) and runs minimal, OS, and full inventory stages to gather comprehensive system information without making changes.

Universal Application Workflow Exit

  • universal-complete - A minimal pipeline element that indicates completion and has no tasks. This workflow serves as a standardized termination point for Universal Applications, providing a clean exit state that can be monitored and tracked. It ensures consistent completion behavior across different pipeline implementations.

  • universal-prepare-complete - Exit workflow for the prepare phase. It runs after the prepare-phase workflows and hands control back to the chain, which advances to the discover phase.

Pipeline Execution Phases

Once discovered, machines move through sequential phases:

  1. Prepare — Runs the universal-prepare workflows to stage the machine and its environment before discovery and hardware configuration begin.
  2. Discover — Applies classification rules to determine what the machine should become and assigns the appropriate pipeline.
  3. Hardware — Applies BIOS, firmware, and RAID configurations from the DRP Hardware Developer's profiles to bring the machine to the required hardware state.
  4. OS Install — Installs and configures the operating system, handling the provisioning-to-production network transition.
  5. Application — Applies post-OS configuration, completes any remaining setup tasks, and marks the machine complete.

Design Guidelines

When designing Universal Applications, always plan to start from either universal-start or universal-discover. This approach ensures your Universal Applications integrate properly with DRP's workflow chaining system and maintain compatibility with the broader automation ecosystem. Advanced users may choose alternative starting points for specialized use cases, but these fall outside standard Pipeline architecture patterns.

Naming Conventions and Architecture

Pipelines and Universal Applications use naming conventions to automatically connect components. These conventions provide automatic discovery, modularity, extensibility, and maintainability by enabling components to find and link to each other through predictable naming patterns.

Universal Application Naming

Universal Application names serve as the foundation for component discovery and workflow chaining. The chosen name becomes the identifier that connects Profiles, Workflows, Stages, and Parameters across the entire application.

Naming Requirements: - Must be unique within your DRP environment - Should be descriptive and meaningful to the operator - Will be used as a prefix for related workflows and components - Cannot contain spaces or special characters (use hyphens for word separation)