1. Documentation
×

Infrastructure and cluster lifecycle management with the O-Cloud Manager

The O-Cloud Manager runs on a hub cluster to provide template-based lifecycle management for OKD clusters. It automates cluster provisioning, hardware management, Day 2 configuration, scaling, and upgrades through declarative custom resources built on Red Hat Advanced Cluster Management (RHACM) and the SiteConfig Operator.

The O-Cloud Manager also exposes REST APIs for programmatic access to inventory, provisioning, alarms, and monitoring operations.

The O-Cloud Manager is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Template-based cluster provisioning and management at scale

Managing bare metal OKD clusters at scale introduces challenges that grow with fleet size. As the number of sites increases, maintaining consistency across cluster configurations, coordinating hardware allocation, and executing lifecycle operations such as upgrades and scaling become increasingly complex and error-prone when handled manually or through bespoke automation.

The O-Cloud Manager addresses these challenges by providing template-based infrastructure and cluster lifecycle management through a GitOps-based workflow, with REST APIs for programmatic access.

The O-Cloud Manager implements the O-RAN Alliance O2 IMS specification through its REST APIs, which are designed for integration with Service Management and Orchestration (SMO) systems used in telecommunications environments. However, SMO integration is optional. The same REST APIs provide programmatic access to any external system. You can also manage the underlying custom resources directly, or through a GitOps workflow, without using the REST APIs. This enables the O-Cloud Manager to support any multi-cluster, bare metal deployment that benefits from template-based cluster provisioning and lifecycle management.

The O-Cloud Manager separates reusable cluster blueprints from site-specific deployment parameters:

  • Platform engineers define immutable ClusterTemplate resources that specify the cluster topology, hardware requirements, and configuration policies for a class of clusters.

  • Site engineers create ProvisioningRequest resources that reference a template and supply only the site-specific values such as network addresses and cluster names.

This separation means that platform-wide changes, such as a new firmware baseline or an updated network policy, can be rolled out by versioning a template rather than editing each cluster individually. The O-Cloud Manager validates each request against the template schema, allocates hardware from managed resource pools, and orchestrates the end-to-end lifecycle flow by using the SiteConfig Operator, Red Hat OpenShift GitOps, and the Topology Aware Lifecycle Manager.

All lifecycle operations, provisioning, configuration, scaling, and upgrades, are driven through the ProvisioningRequest custom resource, providing a single point of control for each managed cluster. The REST APIs provide programmatic access to the same operations to enable automation and integration with external management systems, such as SMO frameworks.

Additional resources

O-Cloud Manager key components

The O-Cloud Manager uses several custom resources (CRs) to manage the cluster lifecycle. You use these resources when configuring templates, provisioning clusters, and managing hardware.

ClusterTemplate CR

An immutable blueprint that defines the cluster topology, hardware defaults, and configuration policies for a class of clusters. Each ClusterTemplate CR references ConfigMap resources that supply cluster installation defaults and policy template defaults. These defaults are merged with site-specific values at provisioning time.

ProvisioningRequest CR

A mutable resource that represents the desired state of a single managed cluster. One ProvisioningRequest CR represents one cluster. Creating a ProvisioningRequest CR triggers provisioning. Updating it enables Day 2 operations such as configuration changes, scaling, and upgrades. Each ProvisioningRequest CR references a ClusterTemplate CR and supplies site-specific parameters or optional configuration overrides.

HardwareProfile CR

An optional resource that defines target firmware levels and BIOS settings for a class of servers. When specified in a ClusterTemplate CR, the O-Cloud Manager applies the hardware profile during initial provisioning or as a Day 2 update.

BareMetalHost CR

Represents a physical server registered in the hub cluster inventory. The Bare Metal Operator manages this resource, but the O-Cloud Manager uses the BareMetalHost CR for hardware selection. Each BareMetalHost CR includes metadata labels used for resource selection and defines a BMC connection for power management and hardware inspection.

ResourcePool CR

Groups bare metal resources at a site for allocation. When processing a ProvisioningRequest, the O-Cloud Manager selects hosts from the appropriate resource pool based on the resource selectors defined in the ClusterTemplate.

Location and OCloudSite CRs

Represent the infrastructure hierarchy. A Location CR identifies a geographic place where infrastructure is deployed. An OCloudSite CR represents a logical site that references a parent Location CR. One or more ResourcePool resources reference the OCloudSite CR to group bare-metal servers at that site.

O-Cloud Manager REST APIs

The O-Cloud Manager exposes REST APIs that provide endpoints for external systems to manage infrastructure and orchestrate the full cluster lifecycle through standard HTTP operations.

The REST API endpoints meet the O-RAN Alliance O2 IMS specification, which enables management by a Service Management and Orchestration (SMO) framework in telecommunications environments. However, SMO integration is optional. The same REST APIs provide programmatic access to any external system.

The REST APIs are served over a single route on the hub cluster.

Inventory API

O2ims_infrastructureInventory/v2 — Query the physical infrastructure including resource pools, individual resources, locations, sites, resource types, and deployment managers.

Artifacts API

O2ims_infrastructureArtifacts/v1 — List available cluster templates, query template parameter schemas, and retrieve preconfigured defaults.

Provisioning API

O2ims_infrastructureProvisioning/v1 — Create, update, and delete provisioning requests to drive cluster lifecycle operations including provisioning, scaling, configuration changes, and upgrades.

Cluster API

O2ims_infrastructureCluster/v1 — Query provisioned node clusters, cluster resources, and node cluster types. Manage cluster event subscriptions for notifications on cluster state changes.

Monitoring API

O2ims_infrastructureMonitoring/v1 — Query and acknowledge alarms raised by managed clusters. Manage alarm subscriptions for event-driven monitoring and alerting.

O-Cloud Manager architecture

The O-Cloud Manager runs on a hub cluster and integrates with several OKD and Red Hat Advanced Cluster Management (RHACM) components to manage the lifecycle of spoke clusters.

The O-Cloud Manager exposes REST API servers for programmatic orchestration of the cluster lifecycle.

You can create and manage ProvisioningRequest CRs by using the following methods:

  • Use the Provisioning REST API to create or update the ProvisioningRequest CR through the provisioning server.

  • Use the GitOps approach to create or update the ProvisioningRequest CR in your Git repository. ArgoCD synchronizes the CR to the hub cluster.

In both cases, the controller manager watches the ProvisioningRequest CR and orchestrates the cluster lifecycle Operators to provision bare-metal servers and spoke clusters.

The Alarms server leverages the RHACM Observability stack for alarm management and subscriptions.
O-Cloud Manager architecture

Declarative hardware management for bare-metal servers

In large-scale deployments with heterogeneous hardware across multiple sites, manually tracking which servers meet the requirements for each cluster and ensuring consistent firmware baselines becomes challenging. The O-Cloud Manager automates hardware allocation and firmware configuration as part of the provisioning workflow, by using the infrastructure hierarchy of Location, OCloudSite, and ResourcePool resources to organize servers across your fleet.

Servers are registered in the hub cluster as BareMetalHost CRs with metadata labels that identify resource pool membership, server type, and other characteristics. The Bare Metal Operator connects to each host’s BMC and inspects the physical hardware. The O-Cloud Manager uses this inspection data to populate its own hardware allocation resources with CPU, memory, NIC, and storage details. This enables automatic hardware-aware selection without requiring manual intervention to verify server specifications at each site.

The HardwareProfile CR defines the firmware configuration for a class of servers. This eliminates manual BMC configuration across your fleet and ensures that every server of a given class runs a consistent, baseline configuration before cluster installation. The hardware manager applies the profile during initial provisioning or as a Day 2 update when firmware patching or performance tuning is required. A HardwareProfile is optional. You can provision servers without a profile if you manage firmware and BIOS settings manually.

When processing a ProvisioningRequest CR, the O-Cloud Manager selects servers from resource pools using a two-stage filtering process defined in the ClusterTemplate CR. This ensures the correct class of server is assigned to the correct node role without manual server-by-server assignment, even in racks with mixed hardware:

Label-based filtering

Selects BareMetalHost CRs by labels such as server type, location identifiers, or resource selector labels.

Hardware data filtering

Further filters hosts based on hardware inspection data, matching criteria such as CPU architecture, thread count, memory size, NIC speed and count, and storage type and capacity.

Together, these filtering stages and the optional HardwareProfile application automate the path from bare metal inventory to installation-ready hardware without manual intervention at each site.

O-Cloud Manager cluster lifecycle workflow

The O-Cloud Manager manages bare-metal clusters from initial environment preparation through ongoing operations. All post-provisioning operations are configured through updates to the ProvisioningRequest custom resource (CR).

Prepare

Install the O-Cloud Manager on the hub cluster, configure the GitOps repository, and define ClusterTemplate CR resources with cluster installation defaults, configuration policies, and hardware management settings. Optionally, define HardwareProfile resources for firmware and BIOS management.

Onboard

Register bare-metal servers in resource pools by creating BareMetalHost resources with resource selector labels that identify server type, location, and hardware characteristics. The Bare Metal Operator connects to each host’s BMC, inspects the physical hardware, and populates a HardwareData CR used for resource selection during provisioning.

Provision

Create a ProvisioningRequest that references a validated ClusterTemplate and supplies site-specific parameters. The O-Cloud Manager allocates matching hardware from the resource pool, applies any specified firmware and BIOS settings, renders a ClusterInstance resource, and orchestrates the cluster installation through the SiteConfig Operator. For single-node OKD clusters, image-based installation (IBI) is supported as an alternative provisioning method. After installation, configuration policies are applied and monitored for compliance.

Operate

Update the ProvisioningRequest to drive Day 2 operations on the running cluster, including configuration changes, firmware and BIOS updates, worker node scaling, and cluster upgrades.