Eikon Architecture¶

Eikon leverages pipelines and tasks to configure storage and deploy images to a machine using a declarative approach. It abstracts the complexities of disk management, image handling, and boot configuration into a streamlined workflow that can be easily defined in an eikon/plan.

Main Features¶

• Leverages DRP universal pipelines to configure, classify and validate BMC, BIOS, Hardware RAID and other OS deployment prerequisites. This also allows task injection before during and after image deployment.
• Storage Configuration supports device partitioning and formatting filesystems on disks using LVM, software RAID and most common filesystems.
• Image deployment supports both raw disk images and rootfs archives while preserving extended attributes such as security attributes and ACLS.
• For raw images, supports multiple compression formats including gzip, bzip2, xz and zstd.
• For rootfs images Eikon will managed updating grub, initramfs, and fstab configurations supporting RHEL and Debian-based distributions.
• Optional cloud-init configuration for automated post-deployment initialization.
• For windows deployments, supports cloudbase-init configuration for automated post-deployment initialization.

Pipeline Objects¶

Eikon ships a Pipeline for each supported cloud image. Each inherits the phase chain from universal's default Pipeline and binds two profiles: eikon-os-phase, which replaces the OS phase with universal-image-deploy and carries Eikon's flexiflow task lists, and a per-OS profile supplying the image.

A Pipeline-bound profile overrides the value default sets for the same param. That is what lets eikon-os-phase replace the OS phase without an intermediate Pipeline between default and each per-OS one. Bind eikon-os-phase to a Pipeline of your own when you are supplying the image yourself.

The profile is named eikon-os-phase rather than eikon-image-deploy because that name already belongs to a task, a stage and a deprecated workflow.

Each Pipeline also binds the profile that supplies its image. This matters because the image URL is what actually decides which OS lands on the disk. If the image lived in a profile an operator attached separately, the OS a Pipeline names and the OS a machine receives could disagree, and nothing would catch it. Binding the profile puts that decision inside the Pipeline, so the OS a Pipeline names is the OS it writes. Universal uses the same arrangement: its ubuntu-24.04 Pipeline binds universal-application-ubuntu-24.04 to set the install bootenv.

Phase progression is driven by universal's ucw-pipe.* templates, which read universal/{phase}-phase-workflows from the assigned Pipeline. They never consult universal/workflow-chain-map, so eikon-os-phase omits universal/application and universal/workflow-chain-index-override.

Operators keep control of the image without replacing the Pipeline. eikon/image-url and eikon/image-checksum set on the machine, or on a profile attached to it, both outrank the Pipeline's bound profile. For a whole endpoint, eikon/image-base-url redirects every per-OS profile to a local mirror — see Redirecting Pipeline Images to a Mirror.

Relationship to universal-application¶

Before Pipeline objects, Eikon ran through the universal-application-eikon-image-deploy profile. That profile drives the same flexiflows through the older chain-map path, walked by ucw-ua.* templates using universal/application and universal/workflow-chain-index-override. It declares nothing about which OS is being installed; the operator supplies the image.

Both paths remain supported and reach the same deployment work. The universal-application profile is unchanged, as is the deprecated eikon-image-deploy stage and workflow.

Eikon Pipeline¶

A high level overview of the Eikon deployment task flow is illustrated below:

graph TD
  us[universal-start]
  ur[universal-runbook]
  us --> ui --> ur
  subgraph ui[universal-image-deploy]
    direction TB
    p[callback, classify, flexiflow]
    e1[ensure sledgehammer]
    e2[prepare storage]
    e3[eikon deploys image]
    pd1[install agent]
    rf1[rootfs install packages, updates initramfs, grub and fstab]
    raw1[raw windows images installs agent and stages config script]
    ral1[raw linux image installs agent]
    pd1[kexec or reboot]
    pd2[classify, validate, callback]
    p --> e1 --> e2 --> e3 --> rf1 --> pd1
    e3 --> raw1 --> pd1
    e3 --> ral1 --> pd1
    pd1 --> pd2
  end

Storage Setup¶

During image deployment, Eikon is capable of performing a wide range of storage operations, including:

• Physical disk operations (partitioning, formatting)
• Logical Volume Management (LVM)
• Software RAID configurations (mdadm)

When you configure your storage layout in an eikon/plan, the storage manager orchestrates all the necessary operations in the correct order. For example, in a complex configuration with RAID and LVM, it knows to:

• Create physical partitions first
• Build RAID arrays if specified
• Initialize LVM physical volumes
• Create volume groups and logical volumes
• Create and mount filesystems

Image Deployment¶

Eikon supports two types image formats:

Raw Disk Images (known as raw images):

• Uncompressed (dd-raw)
• Compressed with gzip (dd-gz), bzip2 (dd-bz2), xz (dd-xz), zstd (dd-zst)
• Archived raw images: tar (dd-tar), tar+gzip (dd-tgz), tar+xz (dd-txz), tar+bzip2 (dd-tbz)
• QCOW2 virtual disk images (qcow)

Filesystem Archives (known as rootfs images):

• Uncompressed tar with attribute preservation (tar)
• Compressed archives: tar+gzip (tgz), tar+xz (txz), tar+bzip2 (tbz), tar+zstd (tar-zst)
• All archive types preserve:
  • Numeric UIDs/GIDs
  • Extended attributes
  • ACLs
  • SELinux contexts

Post storage configure and image deployment, the pipeline is able to determine what is needed to boot the system. For raw images, typically not much else is needed, however rootfs images require additional configuration to enusre the system is bootable. Eikon will handle:

• Installing necessary packages for the target distribution to ensure the system can boot successfully.
• Installing and managing bootloaders for RHEL and Debian-based systems.
• Updating initramfs and fstab configurations to ensure the system can boot successfully after deployment.

Deployment Methods¶

Eikon provides two distinct ways to deploy systems:

1. Raw Image Deployment - Best for pre-configured systems requiring exact replication
2. Rootfs Archive Deployment - Best for systems requiring custom partition layouts or RAID/LVM configurations

Raw Image Deployment¶

In this method, Eikon writes a complete system image directly to the target disk. It is ideal for quickly deploying preconfigured systems where the image already contains the desired partition layout, filesystems, and boot configuration. Eikon does not attempt to resize storage configurations. Using flexiflow, or leveraging universal pipelines, it's possible to provide post-deployment tasks that could manage resizing partitions, filesystems, and updating network, ssh access or other post-deployment configurations necessary to complete the deployment.

Rootfs Archive Deployment¶

This method supports granular control over storage configurations. It requires more configuration manipulation during deployment to ensure the system is bootable, but it allows for custom partition layouts. Eikon will handle installing necessary packages, configuring the bootloader, and updating initramfs and fstab to ensure the system can boot successfully after deployment. This method is ideal for deployments that require specific storage configurations such as RAID or LVM, or when you want to deploy a base filesystem and customize it during deployment using flexiflow or universal pipelines.