What is OpenStack?

The core projects map directly onto the services a cloud must offer:

• Compute - the API that creates and destroys virtual machines.
• Block storage - persistent volumes attached to those machines.
• Object storage - a scalable store for images, backups and unstructured data.
• Networking - virtual networks, routing and isolation between tenants.
• Identity - who may create what, which underpins quota and tenancy.

Beyond the core, the surrounding ecosystem fills in the edges - load balancing, DNS, bare-metal provisioning, telemetry - so a deployment grows services the way it grows capacity: incrementally, and only where the need has actually shown up.

Under the APIs, a boot request is a relay between services rather than one program starting a machine. The compute API validates the request and asks the scheduler which host has room; the scheduler answers from its view of resources; the chosen host starts the virtual machine through the hypervisor, while identity confirms the caller was allowed to ask at all.

Storage and networking join by attachment: a volume is created in the block service and connected to the instance, a port is allocated on the virtual network, addresses are handed out. The services coordinate through the message bus and database, which is why they are deployed, upgraded and monitored as a set rather than as independent tools.

Because the flow crosses service boundaries, failure modes do too: a request can fail after authentication but before scheduling, or come up running while a volume attachment fails later. Operators debug this by correlating across services - which is why request identifiers are threaded through every log line in between.

The two are often named together because they layer cleanly: KVM is the kernel-level hypervisor that actually runs virtual machines on Linux, while OpenStack is the cloud control plane that exposes those machines as an API with tenancy, images, networks and quota around them. KVM is to OpenStack what an engine is to a fleet-management system - necessary underneath, insufficient alone to be a cloud. A KVM host becomes cloud infrastructure when OpenStack (or something equivalent) gives it self-service, metering and lifecycle.

OpenStack is a natural anchor for the private half of a hybrid architecture: it holds the steady-state and sensitive workloads, while rented capacity covers peaks and specialised needs. The integration question is how the OpenStack side and the external side are operated together - which is the open source hybrid cloud problem, and why adapter layers that speak to OpenStack natively matter more than another dashboard.

Operating the stack well is mostly discipline around change. Services release together but may lag each other within a supported window, upgrades must preserve running instances, and the control plane itself needs redundancy - API, scheduler and database sit on the critical path of every request.

• Upgrade sequencing with compatibility checks before the first service moves.
• Control plane components deployed redundantly - they are the critical path.
• Quota and scheduling policy tuned so one noisy tenant cannot starve the fleet.
• Telemetry kept on, because capacity planning without usage data is guessing.

Distributions package the same services together with their own upgrade tooling and tested paths; whichever route an operator takes, the operational profile above does not change.

For a provider, an OpenStack cloud is already a cloud - the missing piece is reach. Waldur documents an OpenStack provider integration, and through the provider daemon that control plane connects to VirtEngine: offerings are published, orders become leases, usage is metered and settlement happens on-chain. The cluster keeps its operational model; the demand side stops being limited to whoever already knows about it.