Skip to content

Zero Touch Operations Overview

Zero Touch Operations automates bare metal provisioning without manual intervention. Systems boot, get discovered, classified, and configured automatically from hardware through OS to application deployment.

DRP uses Infrastructure Pipelines to combine Universal Workflows, automatic classification, and declarative configurations. This removes manual steps like console access, interactive installers, and repetitive configuration. Works for single machines or entire racks. After deployment, use WorkOrders, Blueprints, and Triggers for ongoing operations.

What is Zero Touch Operations?

Zero Touch Operations takes systems from bare metal to production-ready applications without operator intervention. Traditional provisioning needs manual steps—selecting boot options, answering installer prompts, configuring BIOS. Zero touch handles these automatically based on pre-defined policies and classification rules.

Key Characteristics

  • Automation: Systems boot, discover hardware, and go through firmware updates, OS install, and app config without operator interaction
  • Scale: Single machines to entire racks
  • Consistency: Same declarative definitions every time, no config drift
  • Flexibility: Multiple hardware vendors, OSes, and app stacks via profile-based config
  • Team Collaboration: Hardware, OS, and app teams work independently on their parts

When to Use Zero Touch Operations

Use zero touch for:

  • Large-scale data center deployments (manual provisioning doesn't scale)
  • Edge sites that need remote deployment
  • Standardized infrastructure with many systems
  • Teams split by hardware, OS, and application
  • On-premises bare metal that should feel like cloud

Skip zero touch for:

  • One-off custom systems
  • Dev/test where you want to explore interactively
  • Special configs that don't fit standard patterns

The Zero Touch Lifecycle

Zero touch covers three phases: Day 0 (planning), Day 1 (deployment), and Day 2 (operations). Day 0 is where you design classification rules and profiles, and optionally specify rack definitions before machines arrive. Day 1 runs from discovery through firmware/BIOS/RAID/OOBM configuration, OS install, and app deployment. Day 2 uses WorkOrders, Blueprints, and Triggers for ongoing management.

Day 0: Planning and Configuration

Before provisioning systems, operators and content developers set up the zero touch environment:

Day 0 work sets up the policies and configs that drive automated decisions during Day 1 and Day 2. For batch deployments, use the rack content pack to pre-configure entire racks before machines arrive. Use IPMI Scanning to automatically discover BMCs via Redfish across IP ranges, create machines, and optionally power on and PXE boot systems—enabling true lights-out rack provisioning.

Day 1: Initial Deployment

Day 1 is system deployment from bare metal to production-ready apps.

Discovery

Systems boot via PXE (or other boot mechanisms) into the Sledgehammer discovery environment—a minimal Linux environment that inventories hardware without altering the target system. For rack-scale deployments, IPMI Scanning can scan BMC IP ranges via Redfish to create machines and trigger PXE boot before operators touch hardware.

DRP collects hardware information including:

  • Manufacturer and product model details (via DMI/BIOS data)
  • CPU, memory, and storage configurations
  • Network interfaces and LLDP neighbor information
  • IPMI/BMC controller details and capabilities
  • BIOS mode (UEFI vs Legacy) and firmware versions
  • RAID controller presence and configuration

The universal-discover workflow runs inventory stages that populate machine parameters with this data. The data then drives automatic classification.

Learn more: Discovery Operations, Discovery Architecture, Inventory

Classification

Classification assigns profiles to machines based on discovered hardware, operator-defined bill-of-materials (BoM) groupings, and target application states. Operators and content developers write the classification rules and create the profiles.

The classification system generates profile names by combining:

  • Hardware identifier: Auto-generated from inventory data (e.g., Supermicro-SYS-E300-9D-8CN8TP-legacy-bios-rc0)
  • BoM grouping: Operator-defined hardware scenarios (e.g., universal-bom-smgen1)
  • Application target: End-state definitions (e.g., universal-application-proxmox-8)

The classifier searches for profiles following naming conventions like universal-bom-{bom}-{hardware}-{application} and universal-hw-{hardware}-{application}, applying any matches found. Different teams can maintain separate profile sets that get combined automatically.

The universal-discover-classification stage runs the classify task to do this.

Learn more: Automatic Machine Classification

Hardware Management

After classification, systems go through hardware setup where firmware, BIOS, and RAID configs get applied. The universal-hardware workflow handles:

  • Firmware Updates: Flashing firmware to standardized versions defined in hardware profiles
  • BIOS Configuration: Setting boot order, virtualization extensions, power management policies, and other BIOS parameters
  • RAID Setup: Creating and configuring hardware RAID arrays according to specifications
  • BMC Configuration: Configuring baseboard management controllers including network settings and certificates

Hardware gets configured consistently before OS install starts.

Learn more: Hardware Lifecycle Management

Operating System Installation

The universal-linux-install workflow deploys the OS using Kickstart, Preseed, or image-based methods. Config includes:

  • OS distribution and version selection
  • Disk partitioning and filesystem layout
  • Package selection and installation
  • Network configuration (addressing, DNS, routing)
  • User account and authentication setup
  • Post-installation scripts and customizations

When universal/application is set, workflows chain automatically from hardware through OS install. System reboots into the new OS and registers with DRP.

Learn more: Universal Linux Provision, Linux Install Workflow, KB-00061: Deploying Linux with Universal Workflows

Application Configuration

After OS install, systems move to app config where cluster software and workloads get deployed. The universal-runbook workflow handles:

  • Container runtime installation
  • Kubernetes or orchestration platform deployment
  • Application-specific software installation
  • Configuration management tool integration
  • Service startup and validation
  • Integration with external systems (monitoring, logging, backup)

App config ranges from simple package installs to complex multi-node clusters, all customizable through profiles.

Learn more: Runbook Processing

Day 2: Ongoing Operations

After Day 1 deployment hits target state, systems enter Day 2 where DRP manages ongoing operations. The universal-complete workflow marks Day 1 done.

Day 2 operations use WorkOrders, Blueprints, and Triggers rather than traditional workflows:

  • WorkOrders: Execute defined task sets for specific operational actions without changing system context or boot environment
  • Blueprints: Reusable definitions of task lists, parameters, and profiles that form the basis for WorkOrders
  • Triggers: Create WorkOrders automatically based on schedules (CronTrigger) or events (EventTrigger), or even webhooks from external systems

Machine as Service Model: Systems are placed in WorkOrderMode after initial provisioning. In this mode, systems no longer process workflows but instead execute WorkOrders, enabling:

  • Maintenance Operations: Applying updates, patches, or configuration changes
  • Monitoring and Validation: Running health checks and compliance validation
  • Configuration Management: Adjusting system parameters and settings
  • Lifecycle Actions: Decommissioning, reprovisioning, or system migration

Common Day 2 Patterns:

  • Scheduled Maintenance: CronTrigger executes Blueprints at defined intervals for updates or health checks
  • Event-Driven Actions: EventTrigger responds to system events (failures, threshold alerts) by creating WorkOrders
  • Batch Operations: Execute WorkOrders across multiple systems simultaneously for coordinated updates, configuration changes, or validation checks using the batch content pack for scaled operations
  • Orchestrated Operations: Triggers with QueueMode distribute WorkOrders across available systems matching filter criteria

Systems can be transitioned back to workflow mode for major changes requiring context switches or reprovisioning.

Learn more: WorkOrders, Blueprints, Triggers, Maintenance Mode Patterns

Key Components

Infrastructure Pipelines are the framework for zero touch. These components work together:

Universal Workflows

Universal Workflows are standardized, chainable sequences covering discovery, hardware config, OS install, app deployment, and decommissioning. Set the universal/application parameter and workflows chain automatically—no manual progression needed.

Key workflows include universal-discover (bare metal discovery), universal-start (existing systems), universal-hardware (firmware/BIOS/RAID), universal-linux-install (OS deployment), universal-runbook (application configuration), and universal-complete (final state).

Learn more: Universal Workflow Operations, Universal Workflow Architecture

Classification System

Classification assigns profiles to machines based on hardware inventory (universal/hardware), operator-defined BoM groupings (universal/bom), and app targets (universal/application).

The classifier searches for profiles using naming like universal-bom-{bom}-{hardware}-{application} and universal-hw-{hardware}-{application}, applying matches it finds. Hardware, OS, and app teams can maintain separate profiles that combine automatically.

Learn more: Automatic Machine Classification

Infrastructure Pipelines

Infrastructure Pipelines are declarative end-state definitions. Say "this system should be a Proxmox 8 hypervisor" and DRP figures out the workflow chain to get there. Combines profiles, Universal Application references, and parameters.

Pipeline profiles follow universal-application-{application} naming. Entry points: universal-discover (bare metal), universal-start (existing systems), universal-evaluate (inventory only).

Learn more: Pipeline Architecture

Rack Objects

Rack objects enable batch processing of entire racks through a single data structure. Pre-prime expected machines before arrival, apply common parameters via MachineParams, and import definitions from CSV. Rack objects integrate with classification by setting universal/bom or universal/application parameters automatically.

Learn more: Rack Model

Common Zero Touch Patterns

Single Machine: Boot via PXE, set universal-discover workflow, apply universal-application-{application} profile, let workflows chain. Good for testing and small deployments.

Rack-Scale: Create Rack object with expected machines, set MachineParams with universal/bom and universal/application. Use IPMI Scanning to scan BMC IP ranges, create machines, and trigger PXE boot across entire rack. Pre-prime before arrival, import rack definitions from CSV.

Hybrid Cloud: Use universal-start for existing systems (VMs, cloud, brownfield) without PXE or reprovisioning. Install DRP runner, run specific workflows.

Environment Requirements

Zero touch needs three integrated environments: content, network, and hardware management.

Content Architecture: Zero touch builds on layered content packs. Universal provides core workflow orchestration and chainable stages. Task-library lets you insert custom automation without forking workflows. Classifier implements automatic profile matching from hardware discovery data. Callback and validation connect to external systems and add quality gates.

Network Architecture: Machines PXE boot and discover themselves. As DRP runs its own DHCP, it can provide TFTP, HTTP, and DNS services directly. Allowing it to serve kernel parameters, initrds, OS images dynamically on a per-machine basis.

Hardware Management Architecture: IPMI/Redfish/BMC access enables lights-out provisioning. Power on remotely, change boot order, configure BIOS. The IPMI plugin supports IP range scans to discover BMCs and create machine objects before hardware arrives.

Operator Knowledge: Zero touch builds on DRP core concepts. Pipelines chain workflows, workflows chain stages, stages run tasks, machines represent baremetal, profiles stack parameters. Knowing boot environments, parameter inheritance, and networking basics helps customize and troubleshoot.

Initial Deployment Architecture

Zero touch integrates with DRP's discovery and boot systems through several components:

Content Installation: Universal content pack and dependencies populate DRP with workflow definitions, stage sequences, task implementations, and parameter schemas. This establishes the automation framework.

Default Workflow Configuration: DRP's defaultWorkflow and unknownBootEnv preferences control what happens when unknown machines boot. Set to universal-discover and discovery to route systems into zero touch automatically. Machines boot Sledgehammer and enter discovery without manual steps.

Network Boot Architecture: DHCP directs booting systems to DRP's TFTP and HTTP endpoints. Systems download boot loaders and Sledgehammer, run discovery workflows, and register with DRP.

Application Profile Selection: Infrastructure Pipelines activate via universal-application-{application} profiles. These profiles combine declarative end-state definitions with Universal Application references. Apply a profile to a machine or set it in classification—either way triggers the workflow chain to target state.

Workflow Progression: Once universal/application is set (usually by the pipeline itself), workflows chain automatically. Hardware config, OS install, app deployment—all run in sequence. Monitor via RackN Portal or CLI, no intervention needed at each stage.

For step-by-step procedures, see KB-00061: Deploying Linux with Universal Workflows or the Provision view in the RackN Portal.

Advanced Topics

IPMI Scanning: Use IPMI Scanning to discover BMCs via Redfish across IP ranges, automatically create machines, and trigger PXE boot. Combine with Triggers to power on discovered systems immediately.

Custom Classification: Modify universal/discover-classification-base-data to add custom profile search patterns or hook up external classification (CMDB, inventory databases).

External Service Integration: Use Callback plugin to trigger ServiceNow tickets, update CMDB records, register monitoring, coordinate network automation.

Validation Framework: Add quality gates with Validation content pack to check system state (firmware versions, BIOS settings, network) before workflows continue.

FlexiFlow Customization: Insert custom tasks into universal workflows without forking.

Day 2 Maintenance: Use WorkOrders, Blueprints, and Triggers for scheduled maintenance (CronTrigger), event-driven ops (EventTrigger), Machine as Service (WorkOrderMode), orchestrated actions (QueueMode), and batch processing (batch).