Skip to main content

Concepts

This section explains OSISM's architecture, the components that make up a cloud pod, and the design principles that guide technology choices.

Architecture overview​

OSISM overview

The diagram above shows an overview of a fully open source OSISM-managed cloud pod. It illustrates the key orchestration, network, compute and storage components of it and how these interact. Each of the core components and their functions are described in the section below.

Core components​

OSISM Manager​

The OSISM Manager is the central control point of every OSISM deployment and the operator's single point of entry for deploying, configuring, and operating all services in a cloud pod. The entire environment is orchestrated through the osism CLI: all tasks are handed to the manager, which reads the configuration options from the local Git configuration repository and applies them with Ansible against the inventory generated from NetBox. All Ansible-based automation — for OpenStack, Ceph, infrastructure, and Kubernetes — runs through the manager's job queue system.

See the OSISM Manager page for a detailed breakdown of the manager's components.

OSISM MetalBox​

The OSISM MetalBox is a hardware-provisioning toolkit built around OpenStack Ironic that provisions both servers and switches. From the cabling and IPAM data in NetBox, the SONiC configuration is generated and pushed to the switches via ZTP, while server installation is orchestrated through the integrated Ironic using Redfish and virtual-media images. The MetalBox bundles every component required to install an OSISM environment offline — NetBox as the source of truth, an OSISM Manager, a container registry, an APT repository, and an HTTP server for the deploy images.

See the OSISM MetalBox page for a detailed breakdown of the MetalBox's components.

Configuration repository​

The Git configuration repository serves as the single source of truth for the entire environment. It holds all configuration options for Kolla as well as the IPAM and cabling information that forms the basis for NetBox. Following the GitOps principle, all changes are made here first and then rolled out through the OSISM Manager or the MetalBox.

NetBox​

NetBox provides the cabling, the roles of the individual components, and IPAM. The local instance is populated from the configuration repository and serves as the source of information for the OSISM Manager and the MetalBox. Because NetBox provides documentation and configuration at the same time, any config drift is avoided.

SONiC​

The network is provided through BGP-unnumbered host-based routing. The entire configuration is generated by the MetalBox and rolled out to the switches via ZTP and to the servers through Ironic. Concepts such as MLAG, Spanning Tree, or bonding are fully replaced by BFD, BGP, and ECMP. Details about the network design can be found in the Cluster Network section.

OpenStack​

The IaaS layer is provided by OpenStack. Underlying shared services like MariaDB, Redis, RabbitMQ, and Memcache, as well as OpenStack itself, are provisioned via the OSISM Manager with Kolla Ansible to the respective servers. The selection and configuration of the OpenStack services happen in the Git configuration repository. The assignment of control, compute, network, and monitoring roles is controlled by NetBox.

Storage​

Ceph is installed and initially configured as the open-source storage backend through the OSISM Manager. Further management, upgrades, and performance tuning are handled through cephadm. Integration with OpenStack is enabled by importing the Ceph keyrings into the Git configuration repository.

Components in a cloud pod​

Release Cadence​

OSISM cuts one major release per year, anchored on the spring SLURP (YYYY.1) OpenStack release, and supports the current release plus the one before it. The Release Cadence chapter explains the release timing, which OpenStack releases OSISM ships, and how long each release is maintained.

Technology Adaptability​

OSISM integrates proven open source projects into a cohesive cloud platform. As technology evolves, OSISM adapts by evaluating and adopting new approaches while providing controlled migration paths. Read more in the Technology Adaptability chapter.

Cluster Layout​

See the Cluster Layout page for recommended node counts and the impact of cluster size on quorum and data replication.

Bill of Materials​