Learn OpenStack - Core Services & Inter-Component Communication

#Introduction

Episode 1 described OpenStack as an orchestration of four types of nodes. Episode 2 goes one level deeper: who are the players inside that orchestration? Each service has its own project name, its own role, and its own communication flow. Understanding this map keeps you from getting lost when reading logs or running commands in the following episodes.

Episode 2 covers the six core services — Keystone, Glance, Nova, Neutron, Cinder, and Horizon — and closes with how they communicate: message queue, database, and RESTful APIs.

#Identity, Image & Compute

#Keystone: Identity and Authentication

Keystone is the main gateway. It provides authentication, authorization, and the service catalog. Every request to any service must go through a token issued by Keystone. Keystone also manages domains, projects, users, groups, and roles — the foundation of RBAC, which we'll dissect in episode 3.

openstack service show identity

openstack service show identity displays the endpoint details and service type of Keystone.

#Glance: Image Management

Glance is the Image Service. It stores and manages OS templates for instances — Ubuntu Cloud Image, CentOS GenericCloud, or Cirros for testing. Glance stores images in formats such as QCOW2 and RAW, plus metadata like hw_firmware_type. We'll cover the full details in episode 4.

#Nova: Compute Lifecycle

Nova is the heart of compute. It manages the instance lifecycle: create, start, stop, reboot, resize, and snapshot. Its architecture consists of many components — API server, scheduler, conductor, and the compute agent that runs on each compute node.

nova-api → nova-scheduler → nova-conductor → nova-compute (per node)
                                        ↓
                              KVM/QEMU hypervisor

When you run openstack server create, the request flows through this entire chain before the instance is born.

#Networking, Storage & Dashboard

#Neutron: Software-Defined Networking

Neutron is the Networking Service. It provides virtual networks — networks, subnets, ports, routers, floating IPs, and security groups — with an SDN approach. Behind it sits the ML2 plugin with mechanism drivers such as Open vSwitch and LinuxBridge. Neutron will be the focus of episodes 6-7.

#Cinder: Block Storage

Cinder is the Block Storage Service. It provides persistent volumes that can be attached to instances like external hard disks. These volumes can be detached and moved between instances, snapshotted, and backed up. Cinder supports many backends — LVM for the lab, Ceph RBD for production.

#Horizon: Web Dashboard

Horizon is OpenStack's official web interface. Through Horizon, you can manage projects, instances, networks, volumes, and identity without touching the CLI. This dashboard is only a client of the APIs — anything you can do in Horizon, you can definitely do via the CLI.

openstack service list

The output of openstack service list in your DevStack lab shows all the services above with their project names in the first column. This is the fastest way to verify all components are running.

#Inter-Service Communication

#Message Queue: RabbitMQ/AMQP

When Nova Compute wants to tell Cinder to attach a volume, the instruction isn't sent directly. They use RabbitMQ, an AMQP broker, as an intermediary. Services send messages to a queue, and other services pick them up. This makes communication asynchronous and decoupled.

sudo rabbitmqctl list_queues name messages

rabbitmqctl list_queues name messages shows the queue names and the number of waiting messages — useful for diagnosing buildup issues in episode 19.

#Database: MariaDB/Galera

Each service stores its state in MariaDB (in production: a multi-node Galera Cluster). The nova, neutron, cinder, and keystone service tables store the active resources. This database is the source of truth for the cluster.

#RESTful API Between Services

Besides the message queue, services also call each other directly through RESTful APIs. For example: when creating an instance, Nova calls the Glance API to fetch the image, the Neutron API to create a port, and the Cinder API for volumes. Each of these calls is authenticated with a Keystone token.

#Instance Creation Flow Diagram

1. user → Keystone        : request token
2. user → Nova API        : create server + token
3. Nova  → Glance API     : fetch image
4. Nova  → Neutron API    : create network port
5. Nova  → RabbitMQ       : send task to scheduler
6. Scheduler → RabbitMQ   : select compute node
7. Nova Compute → KVM     : spawn instance
8. Nova  → DB (MariaDB)   : save state

This pattern repeats for almost every operation. Once you understand one flow, the others are just variations on the same theme.

#Summary

Episode 2 introduced the six core OpenStack services and how they communicate. Keystone manages identity, Glance manages images, Nova brings instances to life, Neutron builds networks, Cinder provides block storage, and Horizon serves as the dashboard. Their communication is supported by RabbitMQ, MariaDB/Galera, and RESTful APIs.

Key takeaways:

• Keystone is the authentication gateway for all services.
• Nova manages the instance lifecycle; Glance provides its images.
• Neutron and Cinder provide networking and block storage.
• Horizon is a web client of the APIs, not a separate engine.
• Inter-service communication goes through RabbitMQ, the database, and RESTful APIs.
• All operations are authenticated with a token from Keystone.

In episode 3, we'll cover Keystone in depth — domains, projects, users, groups, roles, Fernet tokens, and LDAP and SSO integration. This is the identity and authorization foundation that keeps OpenStack secure for multi-tenancy. Make sure you're comfortable with openstack service list before continuing.