OSISM: The Open Source Infrastructure Manager for Sovereign Clouds

Digitale Souveränität: Kontrolle über Infrastruktur, Daten und Abhängigkeiten

Was digitale Souveränität bedeutet und wie Unternehmen und Entwickler ihre Infrastruktur, Daten und AI-Systeme unabhängig gestalten können

OSISM (Open Source Infrastructure as a Service Manager) is the deployment and operations platform behind the Sovereign Cloud Stack (SCS) — Europe's answer to hyperscaler lock-in. It orchestrates the full lifecycle of a private cloud built from OpenStack, Ceph, and Kubernetes, all managed through a single Ansible-driven control plane. OSISM 10, released in March 2026, ships with multi-version support for both OpenStack (2025.1 and 2025.2) and Ceph, decoupling the OSISM release cadence from individual component versions for the first time.

This article covers what OSISM is, how its components fit together, and the step-by-step installation routine from bare metal to a running cloud pod.

The Cloud Pod Model

Every OSISM deployment is called a cloud pod — a self-contained private cloud environment with its own compute, storage, networking, and management planes. The architecture is layered:

The cloud pod is not a hypervisor product. It is an integration framework that takes proven open-source projects and wires them into a cohesive, auditable, upgradeable platform. Every configuration change flows through a single Git repository — there is no "click-ops" console for the operator.

Core Components

OSISM Manager

The Manager is the central control node and the operator's single point of entry. Every task — deploying OpenStack services, upgrading Ceph, bootstrapping nodes, running health checks — is dispatched through it via the osism CLI.

Internally, the Manager runs as a set of containers orchestrated by Docker Compose on the manager node. The architecture consists of:

osismclient / python-osism — The container providing the osism CLI. All operator interactions go through this command. The backing Python library is python-osism, which also exposes a programmatic API.

Celery + Redis job queues — The Manager uses Celery backed by a Redis instance (manager-redis) to dispatch Ansible tasks asynchronously. The same Redis doubles as the Ansible facts cache, so all Ansible containers share gathered host facts. Five dedicated queues run in parallel:

Parallel queues mean an OpenStack deployment and a Ceph rolling upgrade can run simultaneously without blocking each other.

Ansible containers — Each workload type has its own container image, each containing the relevant Ansible code and dependencies:

• kolla-ansible — OpenStack service lifecycle (container-image-kolla-ansible)
• ceph-ansible — Ceph deployment and day-2 management (container-image-ceph-ansible)
• osism-ansible — Node bootstrapping, network configuration, supporting services (container-image-osism-ansible)
• osism-kubernetes — Kubernetes cluster provisioning and lifecycle (osism-kubernetes)

inventory-reconciler — The only container that writes to the shared /ansible/inventory volume. It merges the configuration repository with NetBox data (if used) into a single reconciled inventory. All Ansible containers mount this volume read-only, guaranteeing every workload sees the same consistent view of hosts and variables.

Configuration volume (/opt/configuration) — Mounted read-only into every Ansible container. This is the Git configuration repository — the single source of truth for inventory, group variables, host variables, and secrets.

OSISM MetalBox

The MetalBox is a hardware-provisioning toolkit built around OpenStack Ironic. It provisions bare-metal servers and switches, and bundles every component needed to bootstrap a cloud pod offline:

The MetalBox also handles SONiC ZTP (Zero Touch Provisioning) for network switches. Switches with ONIE boot into install mode, discover the MetalBox via DHCP, fetch their per-switch SONiC image and configuration, install both, and reboot into a fully configured network operating system — no console interaction required.

Configuration Repository

The Git configuration repository is the single source of truth for the entire environment. It holds:

• Inventory definitions (hosts, groups, host variables)
• Kolla/OpenStack configuration overrides
• Ceph configuration parameters
• Network topology (for NetBox integration)
• Secrets (encrypted with Ansible Vault)
• TLS certificates and NTP/DNS server lists

The repository is created from a Cookiecutter template on a local workstation or dedicated VM (called the seed node), then transferred to the Manager. After initial deployment, updates flow through osism apply configuration.

NetBox

NetBox provides the DCIM (data centre infrastructure management) layer — hardware inventory, IP address management (IPAM), cabling, rack positions, VLANs, and custom fields. The local NetBox instance is populated from the configuration repository and serves as the authoritative data source for both the Manager and the MetalBox.

Storage: Ceph

Ceph provides the unified storage backend — block storage (RBD) for Cinder, object storage (RGW) with S3-compatible APIs, and file storage (CephFS). In OSISM 10, ceph-ansible is deprecated in favour of cephadm for new deployments; existing clusters can migrate in-place via cephadm adopt.

Networking: SONiC + OVN

The network plane uses SONiC (Software for Open Networking in the Cloud) on leaf-spine switches with BGP-unumbered host-based routing. Traditional concepts like MLAG, Spanning Tree, and bonding are replaced by BFD, BGP, and ECMP. Virtual networking within the pod is handled by OVN (Open Virtual Network), which provides overlay networks for tenant isolation.

The Six-Step Installation Routine

OSISM follows a strict sequential deployment process. Each step builds on the previous one, and the seed node is discarded once the Manager is operational.

Step 1: Create the Configuration Repository

The starting point is not a server — it is a Git repository. On a local workstation (the seed node), create the configuration repository from the Cookiecutter template:

pip install cookiecutter
cookiecutter https://github.com/osism/cookiecutter-configuration.git
cd output/configuration
git init && git add -A && git commit -m "init: configuration repository"

Before the repository is usable, six things must be customised:

1. TLS certificates — place your CA and server certs in environments/manager/files/certificates/
2. NTP servers — edit environments/manager/configuration.yml
3. DNS servers — edit environments/manager/configuration.yml
4. Global inventory — replace the example node01 with your actual hostnames in environments/manager/hosts
5. Manager inventory — add the manager node to the manager group in environments/manager/hosts
6. Secrets — the secrets/ directory contains the SSH deploy key for the repository

Push the repository to GitHub, GitLab, or your internal Git server.

Step 2: Prepare the Seed Node

The seed node is a temporary VM (or your workstation) that performs the initial bootstrap of the Manager. It needs Docker or Podman, SSH access to the future Manager node, and a clone of the configuration repository.

cd environments/manager

All subsequent commands run from this directory. The run.sh script auto-detects the container engine and pulls the registry.osism.tech/osism/seed:latest container when available.

Step 3: Deploy the Manager Node

This is the most involved step, broken into five sub-steps:

3a — Create the operator user

The operator user dragon is created on every node. All OSISM containers run as this user, and Ansible uses it for SSH access.

ANSIBLE_BECOME_ASK_PASS=True \
ANSIBLE_ASK_VAULT_PASS=True \
ANSIBLE_ASK_PASS=True \
ANSIBLE_USER=osism \
./run.sh operator

ANSIBLE_USER is the initial provisioning user (e.g. osism on the node image, or ubuntu for manual installs). After this step, all further commands use dragon.

3b — Apply network configuration

./run.sh network

Backup existing network configs before running this. The network role applies the configuration from environments/manager/configuration.yml. A reboot is required afterwards to ensure the configuration survives a restart.

3c — Bootstrap the manager node

./run.sh bootstrap
./run.sh reboot

This installs Docker, the OSISM container images, and prepares the node for the Manager service.

3d — Deploy the manager service

./run.sh configuration   # Transfer the config repo
./run.sh traefik         # Optional: reverse proxy
./run.sh netbox          # Optional: DCIM inventory
./run.sh manager         # Deploy the Manager containers

3e — Set the vault password

ssh -i id_rsa.operator dragon@YOUR_MANAGER_NODE
osism set vault password

The seed node is no longer needed after this step.

Step 4: Provision Bare-Metal Nodes

If using the MetalBox, bare-metal servers are provisioned through Ironic via virtual media and Redfish. The provisioning flow:

1. Hardware inventory and cabling data is entered into NetBox via the netbox-configuration repository
2. The Manager reads from NetBox and creates Ironic nodes
3. Ironic mounts the IPA boot image over the out-of-band management network
4. The ironic-python-agent writes the deploy image to disk over the data network
5. PXE is not used — no DHCP/TFTP requirements on the data network

For environments without the MetalBox, nodes are provisioned manually (Ubuntu 24.04 LTS install) and added to the configuration repository inventory.

Step 5: Bootstrap the Bare-Metal Nodes

Once nodes have an operating system and network access, bootstrap them from the Manager:

ssh dragon@YOUR_MANAGER_NODE
osism apply bootstrap
osism apply network
osism reboot

Step 6: Deploy Services

Services are deployed in a strict order. Each command can optionally pre-pull container images first:

osism pull <service-list>
osism apply <service-list>

The recommended deployment order:

1. Clustered infrastructure — HAProxy, MariaDB, RabbitMQ, Redis, Elasticsearch
2. Infrastructure — OpenvSwitch, Memcached, etcd, Kibana
3. Ceph — monitors, managers, OSDs, crash, client
4. Basic OpenStack — Keystone, Horizon, Placement, Glance, Cinder, Neutron, Nova
5. Extended services — Heat, Gnocchi, Ceilometer, Barbican, Designate (as needed)
6. Kubernetes — K3s, Gardener, or Cluster API (as needed)

Before deploying, validate network connectivity:

osism validate kolla-connectivity
osism validate ceph-connectivity   # if using Ceph

Cloud in a Box: The Quick Path

For evaluation, development, and training, OSISM provides Cloud in a Box (CIAB) — a single-node deployment that installs a complete Kubernetes cloud (or a full OpenStack + Ceph + K8s stack) from a bootable USB image.

Minimum hardware: 4 cores, 32 GB RAM, 1 TB disk (at /dev/sda or /dev/nvme0n1), one NIC with DHCP internet access.

Automated installation:

1. Download ubuntu-autoinstall-cloud-in-a-box-1.iso (or -2.iso for NVMe)
2. Flash to USB with balenaEtcher or dd
3. Boot from USB — Ubuntu 24.04 installs, then the system shuts down
4. Remove USB, connect network, boot from disk
5. Deployment runs automatically (~1 hour), then the system shuts down again
6. Boot one final time — login via SSH as dragon / password

The CIAB exposes a WireGuard VPN configuration at /home/dragon/wireguard-client.conf for secure access to all web interfaces (Horizon, Grafana, NetBox, Netdata, ARA, Ceph Dashboard).

Key Design Decisions

GitOps by default. Every configuration change is a Git commit. The Manager reads from the mounted repository, not from ad-hoc console commands. This makes audits, rollbacks, and disaster recovery straightforward — clone the repo, point the Manager at it, and re-apply.

Containerised Ansible. Instead of running Ansible directly on the manager node, each workload type runs in its own container with pinned versions. The osism apply command dispatches to the correct container through Celery. This isolation means kolla-ansible and ceph-ansible can run different Ansible versions simultaneously.

Multi-version support (OSISM 10+). An OSISM 10 deployment can run OpenStack 2025.1 or 2025.2, and Ceph Quincy, Reef, or Squid. The version is selected in the configuration repository rather than being tied to the OSISM release. This is a significant shift from earlier versions where the entire stack was pinned to a single OpenStack release train.

Operator user model. The dragon user is both the SSH user for Ansible and the runtime user for all containers. This simplifies permissions — no mixing of root and non-root contexts, and the SSH key pair (id_rsa.operator) provides consistent access across all nodes.

Further Resources

• OSISM Documentation
• GitHub Organisation
• Sovereign Cloud Stack (SCS)
• OSISM Release Notes (10.0.0)
• Cloud in a Box Repository