Introduction to OpenStack 16

OpenStack is the de facto platform for the private cloud market and stands as one of the most popular
open-source projects driven by a global community. Over 500 companies utilize OpenStack for their
cloud infrastructure needs. It serves as the main building block for Network Function Virtualization
(NFV), making it particularly valuable in telecommunications and networking environments.

Research from Technavio in January 2017 forecasted huge growth for both OpenStack and Hadoop
platforms, despite existing skills gaps in the market. The global Hadoop market was predicted to grow
at a compound annual growth rate (CAGR) exceeding 53% over the subsequent four years. Factors
driving this growth included data explosion in enterprises and demand for cost-effective solutions to
meet big data analytics needs. Similarly, Technavio researchers projected that the global cloud
management for OpenStack market would grow at a CAGR exceeding 30-40% over multiple years. As
of 2024, the market size reflects this growth trajectory. The global OpenStack service market was
valued at approximately USD 7.18 billion in 2024 and is projected to reach over USD 56 billion by
2033, with a compound annual growth rate (CAGR) exceeding 25%. This substantial growth is
attributed to increasing demand for cloud services and a push for digital transformation across various
industries.

Key Drivers of OpenStack Adoption

Several factors drive organizations to adopt OpenStack:

Cost Efficiency: OpenStack serves as a cost-effective alternative to proprietary cloud platforms,

making it particularly appealing to small and medium-sized enterprises (SMEs) and large corporations
seeking to control cloud spending. By eliminating expensive licensing fees associated with proprietary
solutions, organizations can allocate resources more effectively while maintaining robust cloud
capabilities.

Avoidance of Vendor Lock-in: As an open-source platform, OpenStack allows organizations to

avoid being tied to a single cloud provider. This independence offers greater flexibility and choice in
technology decisions, enabling organizations to switch providers, customize implementations, and
maintain control over their infrastructure without being constrained by proprietary ecosystems.

Hybrid and Multi-Cloud Strategies: OpenStack plays a key role in hybrid and multi-cloud
architectures by providing the on-premise foundation that can seamlessly integrate with public clouds
like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). This
capability allows organizations to maintain sensitive data on-premises while leveraging public cloud
resources for scalability and specific workloads, creating flexible and resilient infrastructure
architectures.

472
Integration with Kubernetes: OpenStack and Kubernetes are increasingly used together to manage
modern, containerized applications. OpenStack serves as the foundational infrastructure layer for
deploying scalable Kubernetes clusters, providing the compute, storage, and networking resources that
Kubernetes orchestrates. This combination enables organizations to run cloud-native applications
efficiently while maintaining infrastructure-level control.

Industry-Specific Use Cases: OpenStack is the preferred choice in industries requiring high levels
of data security and control, such as telecommunications, finance, banking, and government sectors.
These industries often face strict regulatory requirements and need to maintain complete control over
their data and infrastructure, making OpenStack's open-source, self-hosted model particularly
attractive compared to public cloud alternatives.

Cloud Service Models

Private Cloud (On-Premise): In the private cloud model, the organization manages all layers of the
technology stack internally. This includes applications, runtimes, security and integration, databases,
servers, virtualization, server hardware, storage, and networking. The organization has complete
control and responsibility for every component, represented by blue boxes indicating "Managed by
you" for all layers. This model provides maximum control but requires significant expertise and
resources.

Infrastructure as a Service (IaaS): IaaS represents a shared responsibility model where the cloud
provider manages the foundational infrastructure components while the customer manages higher-
level components. The provider handles servers (represented in gray for "Managed by vendor"),
virtualization, server hardware, storage, and networking. The customer remains responsible for
managing applications, runtimes, security and integration, and databases (shown in blue). OpenStack
primarily operates as an IaaS platform, providing these infrastructure-level services.

Platform as a Service (PaaS): PaaS extends the vendor-managed components further up the stack.
In this model, the provider manages runtimes, security and integration, databases, servers,
virtualization, server hardware, storage, and networking. The customer only needs to manage their
applications (shown in blue). This model reduces operational overhead significantly, allowing
developers to focus primarily on application development rather than infrastructure management.

Software as a Service (SaaS): SaaS represents the most abstracted model where the provider manages
the entire technology stack. All components including applications, runtimes, security and integration,
databases, servers, virtualization, server hardware, storage, and networking are managed by the vendor
(all shown in gray). Users simply consume the application without any infrastructure or platform
management responsibilities.

OpenStack Architecture
High-Level Architecture Components
OpenStack functions as a cloud operating system built on standard hardware. The architecture consists
of several interconnected components that work together to provide comprehensive cloud services.
At the top level, applications interact with OpenStack through APIs, which serve as the interface
between user workloads and the underlying cloud infrastructure. The OpenStack Cloud Operating

473
System sits on a foundation of standard hardware and comprises three primary service categories:
Compute (represented by a yellow-green cube icon), Networking (shown with a purple cube icon), and
Storage (depicted with a light blue cube icon). These three core services are accessible through APIs
and are managed through the OpenStack Dashboard, which provides a unified user interface for all
operations. Below these core services lies the OpenStack Shared Services layer, which provides
common functionality required by multiple components. This shared services layer ensures consistent
behavior across the platform and reduces code duplication. The entire system operates on top of
standard hardware infrastructure, emphasizing OpenStack's ability to run on commodity hardware
rather than requiring specialized, proprietary equipment.

Access Methods to OpenStack Components

OpenStack provides three distinct methods for accessing and managing cloud resources, offering
flexibility to users with different preferences and requirements:

The Horizon Dashboard: Horizon provides a web-based graphical user interface for OpenStack.
The dashboard presents a visual interface where users can launch instances, manage networks,
configure storage, and perform other cloud operations through point-and-click interactions. The
interface includes forms for specifying instance details such as instance name, source images,
availability zones, network configurations, security groups, key pairs, and server groups. This method
is ideal for users who prefer graphical interfaces and occasional interactions with the cloud
environment.

The Command Line Interface (CLI): OpenStack offers command-line tools for programmatic
access and automation. Users can execute commands directly from a terminal to manage cloud
resources. For example, creating a server instance can be accomplished with a command like:

openstack server create --image centos-7-x86_64-st --flavor 1 --nic net

id=4528135f59f84c31b268f3503e1a3766 appserver12

This command creates a server named "appserver12" using a CentOS 7 image with a specific flavor
(size) and network configuration. The CLI provides greater efficiency for repetitive tasks, scripting,
and automation compared to the graphical interface. It enables administrators and developers to
integrate OpenStack operations into scripts, configuration management tools, and continuous
integration/continuous deployment (CI/CD) pipelines.

The API: OpenStack exposes RESTful APIs that can be accessed programmatically using HTTP
requests. Applications and scripts can interact with OpenStack services by making API calls with
proper authentication. For example, retrieving flavor information can be done using a curl command:

curl -s -H "X-Auth-Token: $OS_TOKEN" \

$OS_COMPUTE_API/flavors \
| python -m [Link]

This command sends an HTTP GET request to the compute API endpoint with an authentication
token, retrieves the list of available flavors (instance sizes), and formats the JSON response for
readability using Python's [Link] module. The API method enables deep integration with custom
applications, third-party tools, and automation frameworks, providing the most flexible and
programmatic approach to OpenStack management.

474
System Requirements for OpenStack Deployment
Host Machine Requirements
Deploying OpenStack requires careful consideration of hardware specifications to ensure stable
operation. The basic requirements include:

Operating System: OpenStack requires one physical or virtual host machine running CentOS,
RedHat, or Fedora Linux distributions. A clean OS installation is highly recommended to avoid
conflicts with existing software packages and configurations. This machine serves as the foundation
on which all OpenStack cloud components will be installed and executed.

Memory Requirements: A minimum of 16 GB of RAM is required for basic OpenStack operation.

This memory supports the various OpenStack services and allows for running a limited number of
virtual machine instances. Organizations planning to run more instances or deploy additional services
after the initial setup should provision more memory accordingly to maintain performance and
stability.

Disk Space: A minimum of 20 GB disk space is recommended for the base OpenStack installation.
However, this is a baseline figure. Organizations planning to deploy multiple virtual machine instances
or create numerous storage volumes after deployment should allocate significantly more disk space.
Storage requirements grow based on the number and size of virtual machine images, instance
snapshots, and persistent volumes required.

Processor Requirements: The host machine must have a 64-bit x86 processor with support for Intel
64 or AMD64 CPU extensions. Critically, the processor must have hardware virtualization extensions
enabled, specifically AMD-V for AMD processors or Intel VT for Intel processors. These
virtualization extensions allow the hypervisor to create and manage virtual machines efficiently with
near-native performance. Without these extensions enabled in the BIOS, OpenStack's compute
functionality will not operate correctly.

OpenStack Core Components

Component Architecture
OpenStack consists of multiple integrated components, each with a specific role in the cloud
infrastructure. The architecture diagram shows six core components arranged horizontally with the
Horizon Dashboard above them and Keystone Identity Service on the right. Each component
connects to others as needed, with Keystone providing authentication for all services. The six core
components from left to right are Nova (Compute Node), Glance (Image Service), Swift (Object
Store), Neutron (Networking), and Cinder (Volume Service). Each component has a distinct icon
representing its function: Nova uses a hexagonal pattern representing compute resources, Glance
shows a disc representing images, Swift displays a document icon representing objects, Neutron shows
a network node diagram, and Cinder depicts stacked discs representing volumes. Keystone, positioned
on the right, displays a padlock icon representing security and identity management.

Additional OpenStack Services:

Beyond the core components, OpenStack includes numerous additional services that extend its
functionality: The ecosystem includes Sahara for data processing capabilities, Zaqar for messaging

475
services, Trove for database management as a service, Designate for DNS services, and Barbican for
key management and secrets storage. Heat provides orchestration capabilities for automating
deployment and management of cloud applications. Congress offers governance services for policy
management across the cloud. Manila provides shared filesystems as a service, Ceilometer handles
telemetry and monitoring data collection, and Mistral provides workflow services for automating
complex multi-step processes. Horizon serves as the web-based dashboard interface, Murano provides
an application catalog for deploying applications, and Ironic enables bare-metal provisioning for
deploying operating systems directly on physical hardware without virtualization. Magnum provides
container orchestration services for deploying and managing containerized applications.

Component of OpenStack

Keystone - Identity Service

Keystone serves as the identity service for OpenStack, functioning as the common authorization
framework for the entire platform. It manages authentication, authorization, and service discovery for
all OpenStack components.

Core Functions: Keystone manages users, tenants (also called projects), and roles within the
OpenStack environment. Users represent individual accounts that can access the cloud, tenants
represent organizational units or projects that contain resources, and roles define permissions and
access levels. When a user attempts to access any OpenStack service, Keystone verifies their identity
and determines what operations they are authorized to perform based on their assigned roles within
specific tenants.

Pluggable Backend Architecture: Keystone features a pluggable backend architecture, meaning it

can integrate with various authentication and identity storage systems. Supported backends include
SQL databases for storing identity information directly, PAM (Pluggable Authentication Modules) for
integrating with local system authentication, LDAP (Lightweight Directory Access Protocol) for
enterprise directory services, and IDM (Identity Management) systems. This flexibility allows
organizations to integrate OpenStack with their existing identity management infrastructure rather than
creating a separate identity silo.

Position in Architecture: In the component diagram, Keystone appears on the right side and
connects to all other components. Every service including Nova, Glance, Swift, Neutron, and Cinder
provides authentication through Keystone before processing requests. This central authentication
model ensures consistent security policies across the entire OpenStack deployment and simplifies
management by providing a single point for identity and access control.

Nova - Compute Service

Nova represents the core compute service of OpenStack, responsible for managing the lifecycle of
virtual machine instances.

Architecture and Components: Nova consists of multiple components working together to provide
compute services. Compute Nodes are hypervisors that run virtual machines. These physical servers
execute the virtualization software and host the actual virtual machine instances. Nova supports
multiple hypervisor technologies including KVM (Kernel-based Virtual Machine), Xen, LXC (Linux

476
Containers), Hyper-V, and ESX, providing flexibility in virtualization technology choices based on
organizational requirements and existing infrastructure. Distributed controllers handle scheduling, API
calls, and other management functions. When a user requests a new virtual machine instance, the Nova
scheduler determines which compute node should host the instance based on resource availability,
placement policies, and other constraints. The Nova API service receives and processes requests from
users and other services. Nova Compute runs on each compute node and manages the hypervisor
directly, creating, starting, stopping, and destroying virtual machine instances as needed.

API Compatibility: Nova provides both a native OpenStack API and an Amazon EC2-compatible
API. This dual API approach allows applications designed for Amazon Web Services to run on
OpenStack with minimal or no modification. The EC2 compatibility layer translates EC2 API calls
into equivalent Nova operations, facilitating cloud portability and reducing vendor lock-in concerns.

Use Case Example: When a user wants to launch a virtual machine, they interact with Nova through
one of the three access methods (Dashboard, CLI, or API). Nova receives the request, consults Glance
to retrieve the specified virtual machine image, works with Neutron to configure networking, and may
interact with Cinder to attach persistent block storage volumes. Nova then instructs the appropriate
compute node's hypervisor to create and start the virtual machine with the specified configuration.

Glance - Image Service

Glance provides image services for OpenStack, managing the repository of virtual machine disk images
used to create instances.

Primary Functions: Glance stores and retrieves disk images, which serve as templates for creating
virtual machines. These images contain operating systems and potentially pre-installed software,
allowing rapid deployment of standardized environments. When Nova needs to create a new virtual
machine instance, it retrieves the appropriate image from Glance and uses it as the basis for the new
instance.

Supported Image Formats: Glance supports multiple disk image formats to accommodate different
virtualization technologies and use cases. Supported formats include Raw (unformatted disk images),
QCOW (QEMU Copy-On-Write format version 1), VMDK (Virtual Machine Disk format used by
VMware), VHD (Virtual Hard Disk format used by Microsoft), ISO (CD/DVD image format), OVF
(Open Virtualization Format), and AMI/AKI (Amazon Machine Image formats for EC2
compatibility). This broad format support ensures compatibility with images from various sources and
enables migration from other virtualization platforms.

Backend Storage Options: Glance can store images in various backend storage systems depending
on deployment requirements. Options include local filesystem storage on the Glance server, Swift
(OpenStack's object storage service) for distributed and redundant storage, GlusterFS (a distributed
filesystem), and Amazon S3 (providing hybrid cloud capabilities). The choice of backend affects
scalability, reliability, and performance characteristics of the image service.

Integration with Nova: The diagram shows Glance positioned between Nova and Swift, indicating
its role in the workflow. When Nova needs to launch an instance, it queries Glance for the specified
image, retrieves it (potentially from Swift object storage), and uses it to boot the virtual machine on a

477
compute node. Glance stores not only the image data but also metadata about each image, including
its format, size, properties, and access permissions.

Swift - Object Storage

Swift provides object storage services within OpenStack, designed for storing and retrieving arbitrary
unstructured data.

Design Philosophy: Swift is modeled after Amazon's S3 service, providing a similar object storage
interface and functionality. Object storage differs from block storage (provided by Cinder) and file
storage in that it stores data as objects with unique identifiers rather than in a hierarchical file system
or as raw block devices. This design makes Swift particularly suitable for storing large amounts of
unstructured data such as images, videos, backups, archives, and static web content.

Core Capabilities: Swift provides simple services for storing and retrieving arbitrary data objects.
Each object consists of the data itself plus metadata describing the object. Objects are stored in
containers (similar to S3 buckets), which provide organizational structure. Users can create, read,
update, and delete objects through Swift's RESTful API.

API Compatibility: Swift offers both a native OpenStack API for object storage operations and an
S3-compatible API. The S3 compatibility allows applications designed to use Amazon S3 to work with
Swift with minimal modifications, reducing the effort required to migrate applications from AWS to
OpenStack or develop applications that can work with both platforms.

Use Cases: Swift excels at storing data that needs to be highly available, durable, and accessible from
multiple locations. Common use cases include storing virtual machine image files (working in
conjunction with Glance), storing backup data, serving static website content, archiving logs and
historical data, and storing large media files. Swift's distributed architecture provides redundancy and
scalability, making it suitable for petabyte-scale deployments.

Neutron - Networking Service

Neutron provides comprehensive networking services for OpenStack, enabling Software Defined
Networking (SDN) capabilities.

Core Functions: Neutron serves as the network service component, managing all networking aspects
of the OpenStack cloud. It creates and manages virtual networks, subnets, routers, load balancers,
firewalls, and VPNs. Neutron enables tenants to create complex network topologies without requiring
physical network reconfiguration, providing network isolation and flexibility.

Software Defined Networking Framework: Neutron provides a framework for implementing

Software Defined Networking, which decouples the network control plane from the data plane. This
separation allows dynamic, programmatic network configuration and management. Network
administrators can define network policies and topologies through APIs or the dashboard rather than
manually configuring physical network devices.

Plugin Architecture: Neutron features a plugin architecture that allows integration of hardware and
software-based network solutions. This flexibility enables organizations to choose networking
technologies that best fit their requirements. Supported solutions include Open vSwitch (a popular

478
open-source virtual switch), Cisco UCS (Unified Computing System), Standard Linux Bridge (built into
the Linux kernel), and Nicira NVP (Network Virtualization Platform, now part of VMware NSX).
Additional plugins enable integration with various commercial and open-source SDN controllers and
network appliances.

Network Services: Neutron manages several types of network services. It creates virtual networks
(L2 segments) that provide connectivity between instances. It provides router services (L3 routing) to
connect different networks and provide external connectivity. Neutron manages floating IP addresses,
which allow external access to instances on private networks. It provides load balancing services to
distribute traffic across multiple instances, implements security groups for firewall rules, and can
establish VPN connections for secure remote access.

Cinder - Block Storage Service

Cinder provides block storage services for OpenStack, managing persistent volumes that can be
attached to virtual machine instances.

Core Functionality: Cinder manages volumes, which are virtual block devices similar to physical hard
drives that can be attached to virtual machine instances. Unlike instance ephemeral storage (which
disappears when an instance is terminated), Cinder volumes persist independently of instances. Users
can create volumes, attach them to instances for use as additional storage, detach them, attach them to
different instances, and delete them when no longer needed.

Volume Operations: Cinder supports several key operations. Users can create volumes of specified
sizes, choosing from various volume types that may offer different performance characteristics.
Volumes can be attached to running instances, appearing as additional block devices (similar to
/dev/vdb, /dev/vdc, etc. on Linux). After formatting and mounting, instances can use these volumes
as persistent storage. Volumes can be detached from instances and later reattached to the same or
different instances, enabling data portability and shared storage scenarios.

Snapshot Capabilities: Cinder provides volume snapshot functionality, allowing point-in-time copies
of volumes. Snapshots capture the current state of a volume, enabling backup, disaster recovery, and
template creation workflows. Users can create snapshots of volumes, create new volumes from
snapshots (cloning), and revert volumes to previous snapshot states.

Backend Integration: Cinder features a driver-based architecture that supports multiple storage
backends. While Cinder itself manages the volume lifecycle and API, the actual storage can be provided
by various systems. Supported backends include local storage on compute nodes, Ceph (a distributed
storage system), LVM (Logical Volume Manager) on Linux systems, and numerous enterprise storage
arrays from vendors like NetApp, EMC, HP, and IBM. This flexibility allows organizations to integrate
OpenStack with existing storage infrastructure investments.

479
Horizon Dashboard - Web Interface
Horizon provides the web-based dashboard interface for OpenStack, serving as the primary graphical
user interface for cloud management. It sits at the top of the component architecture, providing a
unified interface to all underlying services.

Unified Interface: The dashboard provides a single web application through which users can access
and manage all OpenStack services. Rather than learning separate interfaces for Nova, Glance, Swift,
Neutron, and Cinder, users can manage compute instances, networks, storage volumes, images, and
other resources through a consistent web interface. This unified approach significantly reduces the
learning curve for new users and improves operational efficiency.

Service Integration: Horizon integrates with all core OpenStack components. It provides UI
elements for Nova to launch and manage instances, for Glance to upload and manage images, for Swift
to manage object storage containers and objects, for Neutron to create and configure networks and
routers, and for Cinder to create and attach volumes. The dashboard communicates with these services
through their APIs, acting as a user-friendly frontend to the programmatic interfaces.

Authentication Integration: Horizon integrates with Keystone for authentication and authorization.
When users log into the dashboard, Keystone verifies their credentials and determines which projects
and resources they can access based on their roles. The dashboard then presents only the operations
and resources appropriate for that user's permissions, ensuring security and preventing unauthorized
access.

Architecture
The comprehensive architecture diagram shows how all OpenStack components interconnect and
work together to provide cloud services. The diagram illustrates four main subsystems: OpenStack
Bare Metal Service, OpenStack Orchestration, OpenStack Compute, OpenStack Block Storage,
OpenStack Networking, OpenStack Telemetry, OpenStack Image Service, OpenStack Identity Service,
OpenStack Database Service, and OpenStack Object Storage.

Internet-Facing Components: At the top of the architecture, CLI clients (nova, cinder, neutron,
etc.), cloud management tools, and GUI tools connect from the Internet. These external interfaces
allow administrators and users to interact with the cloud from anywhere. The interfaces connect
through HTTPS for security, ensuring encrypted communication between clients and OpenStack
services.

User Interfaces: The left section shows two primary user interfaces. The OpenStack Dashboard
(Horizon) provides web-based access, and the Ironic Database stores information for the bare metal
provisioning service. The Ironic conductor and its queue component manage the provisioning
workflow, communicating with drivers to control physical hardware deployment.

Orchestration Layer: The OpenStack Orchestration section shows heat-api and heat-api-cfn
components, which provide REST APIs for template-based orchestration. A queue component
manages asynchronous operations, and heat-engine processes orchestration templates and executes the
workflows they define. Heat allows users to define entire cloud applications in templates that specify
instances, networks, storage, and their relationships, then deploy these applications automatically.

480
Compute Services: The OpenStack Compute section contains several components. The nova-api
receives requests from clients, nova-scheduler determines placement of new instances, and nova-
console provides console access to running instances. The Queue component enables asynchronous
messaging between Nova services. The nova-database stores compute metadata, including information
about instances, flavors, and availability zones. The nova-conductor mediates database access, nova-
consoleauth handles console authentication, and nova-compute runs on each compute node. Guest
agents run inside virtual machine instances, providing a communication channel between instances and
Nova. The Hypervisor layer shows where actual instances execute.

Identity Services: The OpenStack Identity Service section shows the keystone-all component, which
handles all identity operations. It connects to a Database for storing user and tenant information and
to LDAP for integrating with enterprise directory services. This demonstrates Keystone's pluggable
authentication backend architecture, allowing integration with existing identity management systems.

Image Services: The OpenStack Image service section includes glance-api for receiving image
requests, glance-store for managing image storage, and the Glance database for image metadata. The
glance-registry maintains the image registry, tracking available images and their properties.

Block Storage: The OpenStack Block Storage section shows cinder-api for handling volume requests,
Queue for asynchronous operations, the Cinder database for volume metadata, Volume provider for
the actual storage backend, and cinder-scheduler for determining volume placement. The cinder-
volume service manages volume operations on storage nodes.

Networking Services: The OpenStack Networking section displays neutron-server for handling
network API requests, Queue for message passing, Neutron database for network configuration,
Neutron L2 agent for layer 2 switching, neutron-dhcp-agent for providing DHCP services to instances,
and Neutron 3rd party plugin for integrating additional networking technologies. This architecture
enables flexible, software-defined networking capabilities.

Object Storage: The OpenStack Object Storage section shows swift-proxy-server receiving object
requests, trove-api for database services, Account Database for account information, Object Database
for object metadata, Container Database for container information, and swift-account-server, swift-
container-server, and swift-object-server for managing the actual stored data. This distributed
architecture enables scalable object storage.

Telemetry Services: The OpenStack Telemetry section includes ceilometer-collector for gathering
metrics, ceilometer-database for storing telemetry data, Queue for message distribution, and multiple
ceilometer-agent components (notification, compute, and central) for collecting data from various
sources. ceilometer-api provides access to collected metrics, and ceilometer-alarm-evaluator and
ceilometer-alarm-notifier enable threshold-based alerting.

Data Processing: The OpenStack Data Processing section shows sahara-all managing Hadoop cluster
deployments, Queue for workflow management, and sahara database for storing cluster configurations.
This enables big data processing capabilities within OpenStack.

481
Practical Implementation Considerations

Deployment Architecture
When deploying OpenStack, several architectural decisions must be made regarding how components
are distributed across physical or virtual machines.

All-in-One Deployment: For testing, development, or small-scale deployments, all OpenStack

services can run on a single host machine meeting the minimum requirements (16 GB RAM, 20 GB
disk, 64-bit processor with virtualization extensions). This configuration simplifies initial exploration
and learning but doesn't provide production-level reliability, performance, or scalability. The single
host runs the controller services (API endpoints, schedulers, databases), network services, storage
services, and also acts as a compute node running virtual machine instances.

Distributed Deployment: Production deployments typically separate OpenStack services across

multiple machines for reliability, performance, and scalability. A typical architecture includes controller
nodes (running API services, schedulers, databases, and management services), compute nodes
(dedicated to running virtual machine instances with hypervisors), network nodes (handling routing,
DHCP, load balancing, and VPN services), and storage nodes (providing block and object storage).
This separation allows independent scaling of different resource types and provides fault tolerance
through redundancy.

High Availability Considerations: Production environments require high availability to prevent

single points of failure. Controller services should be deployed across multiple nodes with load
balancing, ensuring API availability if a controller fails. Databases should use replication or clustering
for data protection. Message queues should be clustered for reliability. Network nodes should be
redundant to maintain connectivity. Storage systems should provide replication and redundancy.
Proper high availability design ensures that individual component failures don't cause cloud-wide
outages.

Network Architecture
OpenStack networking requires careful planning to ensure proper connectivity, security, and
performance.

Network Separation: OpenStack deployments typically use multiple physical or logical networks for
different purposes. The management network carries control traffic between OpenStack services and
should be isolated for security. The API network provides user and application access to OpenStack
services. The storage network carries traffic between compute nodes and storage systems, requiring
high bandwidth. The tenant network carries traffic between virtual machine instances belonging to
tenants. The external network provides connectivity to the internet or organizational networks.
Separating these networks improves security, performance, and reliability.

Network Technologies: Neutron can use various network technologies to implement virtual
networks. VLAN (Virtual Local Area Network) tagging can segregate traffic on shared physical
infrastructure, supporting up to 4096 isolated networks per physical network. VxLAN (Virtual
Extensible LAN) and GRE (Generic Routing Encapsulation) tunneling protocols can overlay virtual
networks on existing infrastructure, overcoming VLAN scaling limitations and enabling more flexible

482
network topologies. Flat and provider networks can map directly to physical network infrastructure
for specific use cases.

Storage Architecture
Storage architecture decisions significantly impact OpenStack performance, capacity, and reliability.

Storage Types: OpenStack uses three distinct storage types for different purposes. Ephemeral storage
is temporary instance root disk storage that exists only during an instance's lifetime, typically provided
by local disks on compute nodes for best performance. Block storage (Cinder) provides persistent
volumes that survive instance termination and can be moved between instances, suitable for databases
and applications requiring consistent storage. Object storage (Swift) provides scalable storage for large
amounts of unstructured data like images, videos, backups, and archives.

Storage Backend Selection: Organizations must choose appropriate storage backends based on their
requirements. Local storage on compute nodes provides excellent performance for ephemeral storage
but doesn't support instance migration. Ceph provides unified storage for ephemeral, block, and object
storage with excellent scalability and redundancy. Enterprise storage arrays offer proven reliability and
advanced features but may require specific drivers and configuration. NFS (Network File System)
provides simple shared storage but may have performance limitations. The choice depends on
performance requirements, capacity needs, budget, existing infrastructure, and operational expertise.

Identity Integration
Integrating OpenStack with organizational identity systems improves security and user management.

LDAP Integration: Many organizations use LDAP directory services like Active Directory for
centralized identity management. Keystone can integrate with LDAP to authenticate users against
existing organizational accounts, eliminating the need for separate OpenStack credentials. Users can
log into OpenStack using their corporate usernames and passwords. Group memberships in LDAP
can map to OpenStack roles, automating permission management. This integration simplifies user
onboarding and offboarding while maintaining consistent identity management across organizational
systems.

Federation and Single Sign-On: Keystone supports identity federation through protocols like SAML
(Security Assertion Markup Language) and OpenID Connect. Federation allows users from external
identity providers to access OpenStack without creating local accounts. Single sign-on capabilities
enable users to authenticate once and access multiple services without re-entering credentials. This
approach is particularly valuable in multi-organization scenarios or when integrating with public cloud
identity providers.

Security Considerations
Security must be addressed at multiple levels in OpenStack deployments.

Network Security: Security groups provide instance-level firewall rules, controlling inbound and
outbound traffic based on IP addresses, protocols, and ports. Network isolation ensures tenants cannot
access each other's networks without explicit configuration. Encryption can protect sensitive traffic,
with options for VPN connections, encrypted storage volumes, and TLS/SSL for API access. Proper
network segmentation limits the impact of potential security breaches.

483
Access Control: Role-based access control (RBAC) ensures users can only perform authorized
operations. Keystone manages authentication and authorization, verifying user identities and checking
permissions before allowing operations. Administrative access should be restricted and monitored.
API access can be limited by IP address or network. Regular security audits help identify and address
potential vulnerabilities.

Data Protection: Encryption at rest protects data stored on disks from unauthorized access if physical
media is compromised. Cinder supports encrypted volumes, Swift can encrypt objects, and Glance can
store encrypted images. Regular backups protect against data loss from failures or attacks. Access
logging and auditing track who accessed what data and when, supporting compliance requirements and
security investigations.

Operational Workflows

Instance Launch Workflow

Understanding the complete workflow for launching a virtual machine instance illustrates how
OpenStack components work together.

User Request: The process begins when a user requests a new instance through one of the three
access methods. Using the Horizon dashboard, the user fills out a form specifying the instance name,
image, flavor (size), network configuration, security groups, and SSH key pair. Using the CLI, the user
executes a command like:

openstack server create \

--image ubuntu-20.04 \
--flavor [Link] \
--network private-net \
--security-group default \
--key-name my-keypair \
my-instance

This command specifies all required parameters: the image to use (ubuntu-20.04), the flavor defining
CPU, RAM, and disk ([Link]), the network to attach (private-net), security group rules to apply
(default), the SSH key for access (my-keypair), and the instance name (my-instance).

Authentication: The request first goes to Keystone for authentication. The user's credentials
(username and password, or an existing authentication token) are verified. Keystone checks if the user
has permission to create instances in the specified project and returns an authentication token that will
be used for subsequent operations.

Nova Processing: Nova receives the authenticated request at the nova-api service, which validates
the parameters and ensures the requested resources (image, flavor, network) exist and are accessible.
The nova-scheduler then determines which compute node should host the new instance based on
available resources, placement policies, and any specified constraints like availability zones or host
aggregates.

484
Image Retrieval: Nova contacts Glance to retrieve the specified image (ubuntu-20.04 in this example).
Glance locates the image in its storage backend (filesystem, Swift, or other) and provides it to Nova.
The image is copied to the selected compute node, either directly or cached for future use.

Network Configuration: Nova contacts Neutron to allocate network resources for the instance.
Neutron creates a port on the specified network (private-net), assigns an IP address from the subnet,
applies the specified security group rules (default), and configures the virtual switch on the compute
node to connect the instance to the network.

Storage Provisioning: If the user requested additional block storage volumes, Nova contacts Cinder
to create and attach them. Cinder creates the volumes on the configured storage backend and connects
them to the compute node, making them available to the instance as additional block devices.

Instance Creation: With all resources prepared, Nova instructs the nova-compute service on the
selected compute node to create the instance. Nova-compute communicates with the local hypervisor
(KVM, Xen, or other) to define the virtual machine with the specified CPU, RAM, and disk resources.
It configures the network interface, attaches storage volumes if any, injects the SSH key for
authentication, and boots the instance using the retrieved image.

Status Updates: Throughout this process, Nova updates the instance status in its database,
progressing through states like BUILD, NETWORKING, SPAWNING, and finally ACTIVE. The
user can query instance status to monitor the launch process.

Volume Attachment Workflow

Attaching a Cinder volume to a running instance demonstrates inter-component coordination.

Volume Creation: First, a volume must be created if it doesn't already exist. Using the CLI:

openstack volume create \

--size 10 \
--type ssd \
my-volume

This command creates a 10 GB volume named "my-volume" of type "ssd" (which might be configured
to use SSD-backed storage for better performance). Cinder creates the volume on the appropriate
storage backend based on the specified type.

Volume Attachment: To attach the volume to an instance:

openstack server add volume my-instance my-volume

This command requests that Nova attach volume "my-volume" to instance "my-instance."

Coordination Process: Nova receives the request and contacts Cinder to reserve the volume for
attachment. Cinder verifies the volume is available (not already attached elsewhere) and marks it as in-
use. Nova then contacts the compute node hosting the instance and instructs it to attach the volume.
The compute node connects to the storage backend where the volume resides, maps the volume to a

485
block device (like /dev/vdb), and attaches it to the virtual machine. The hypervisor configuration is
updated to include the new volume.

Instance Access: Inside the instance, the new volume appears as a block device. The user or
administrator can then format it, mount it, and use it for storage:

# Inside the instance

sudo mkfs.ext4 /dev/vdb
sudo mkdir /mnt/data
sudo mount /dev/vdb /mnt/data

These commands format the volume with the ext4 filesystem, create a mount point, and mount the
volume so it can be used.

Snapshot Creation Workflow

Creating a snapshot of an instance or volume enables backup and recovery.

Instance Snapshot: To create a snapshot of an entire instance:

openstack server image create \

--name my-instance-snapshot \
my-instance

This command creates an image from the running instance "my-instance" named "my-instance-
snapshot." Nova coordinates with the hypervisor to create a snapshot of the instance's root disk. The
snapshot is uploaded to Glance as a new image, which can later be used to create new instances
identical to the original at the snapshot time.

Volume Snapshot: To create a snapshot of a Cinder volume:

openstack volume snapshot create \

--volume my-volume \
my-volume-snapshot

This command creates a snapshot of "my-volume" named "my-volume-snapshot." Cinder coordinates

with the storage backend to create a point-in-time copy of the volume. The snapshot is stored in the
same storage backend as the volume but is independent and can be used to create new volumes or
restore the original volume.

Orchestration with Heat

Heat provides orchestration capabilities for automating complex deployments.

Template-Based Deployment: Heat uses templates written in YAML (Yet Another Markup
Language) or JSON (JavaScript Object Notation) to define entire application stacks. A template
describes all required resources (instances, networks, volumes, security groups, etc.) and their
relationships. For example, a web application template might define a network, subnet, router, security
groups, database instance, multiple web server instances, and a load balancer, all with proper
connectivity and dependencies.

486
Example Template: A simple Heat template to create an instance:

heat_template_version: 2015-10-15

description: Simple template to deploy a single instance

parameters:
image:
type: string
description: Image to use for instance
default: ubuntu-20.04
flavor:
type: string
description: Flavor for instance
default: [Link]
key_name:
type: string
description: SSH key pair name
network:
type: string
description: Network ID for instance

resources:
my_instance:
type: OS::Nova::Server
properties:
image: { get_param: image }
flavor: { get_param: flavor }
key_name: { get_param: key_name }
networks:
- network: { get_param: network }

outputs:
instance_ip:
description: IP address of the instance
value: { get_attr: [my_instance, first_address] }

This template defines parameters that can be customized at deployment time (image, flavor, key_name,
network), creates a single Nova instance resource using those parameters, and outputs the instance's
IP address. The template can be deployed with:

openstack stack create \

-t [Link] \
--parameter key_name=my-keypair \
--parameter network=private-net-id \
my-stack

487
Stack Management: Heat manages the entire lifecycle of deployed stacks. It creates all defined
resources in the correct order based on dependencies, updates stacks when templates change (adding,
modifying, or removing resources as needed), and deletes entire stacks including all resources when no
longer needed. This capability significantly simplifies deploying and managing complex applications.

Telemetry with Ceilometer

Ceilometer provides monitoring and metering capabilities for OpenStack.
Metric Collection: Ceilometer collects metrics from all OpenStack services, including compute
resource usage (CPU utilization, memory consumption, disk I/O, network traffic), storage operations
(volume creation, deletion, attachment), network activity (bytes transferred, packets sent/received),
and API calls. Multiple ceilometer-agent components run throughout the cloud collecting this data:
ceilometer-agent-compute runs on compute nodes, ceilometer-agent-central runs centrally for polling
services, and ceilometer-agent-notification receives notifications from other services.

Data Storage and Retrieval: Collected metrics are stored in the ceilometer database (which can use
various backends including MongoDB, MySQL, or time-series databases like Gnocchi). The
ceilometer-api service provides access to stored metrics through RESTful APIs. Users and
administrators can query metrics to understand resource usage patterns, identify performance issues,
and track consumption for billing purposes.

Alarming: Ceilometer includes alarming capabilities through ceilometer-alarm-evaluator and

ceilometer-alarm-notifier components. Users can define alarms that trigger when metrics exceed
thresholds. For example, an alarm might trigger if an instance's CPU utilization exceeds 80% for 5
minutes. When alarms trigger, notifications can be sent via email, webhooks, or other mechanisms,
enabling proactive monitoring and automated responses to issues.

Container Services with Magnum

Magnum provides container orchestration for deploying containerized applications on OpenStack.

Cluster Management: Magnum enables users to deploy and manage container orchestration clusters
like Kubernetes, Docker Swarm, or Apache Mesos on OpenStack infrastructure. Users define cluster
templates specifying the orchestration engine, node count, flavor, network configuration, and other
parameters. Magnum then provisions the necessary Nova instances, configures networking with
Neutron, and installs and configures the container orchestration software.
Integration Benefits: By integrating container orchestration with OpenStack, Magnum provides
unified infrastructure management. Container clusters use OpenStack for compute (Nova), networking
(Neutron), storage (Cinder for persistent volumes), and load balancing. This integration ensures
containers benefit from OpenStack's multi-tenancy, security, and operational features while enabling
modern cloud-native application architectures.

Best Practices and Recommendations

Capacity Planning
Proper capacity planning ensures the OpenStack deployment can handle current and future workloads.

488
Resource Assessment: Organizations should assess their workload requirements before deploying
OpenStack. Estimate the number and size of instances needed, storage capacity requirements for
volumes and objects, network bandwidth needs, and expected growth rates. This assessment informs
hardware procurement and configuration decisions.

Overcommitment Ratios: OpenStack allows overcommitting resources, meaning allocating more

virtual resources than physical resources available. Common overcommitment ratios are 4:1 or 8:1 for
CPU (allocating 4-8 virtual CPUs per physical CPU core), 1.5:1 for RAM (allocating 1.5 GB virtual
RAM per 1 GB physical RAM), and 1:1 for storage (not overcommitting). Appropriate ratios depend
on workload characteristics; highly variable workloads benefit from higher overcommitment while
consistent workloads need lower ratios.

Performance Optimization
Several factors impact OpenStack performance and should be optimized.

Compute Performance: Use processors with hardware virtualization extensions (Intel VT-x/AMD-
V) and enable nested virtualization if needed. Configure appropriate CPU pinning for latency-sensitive
workloads. Use NUMA (Non-Uniform Memory Access) topology awareness to optimize memory
access. Choose appropriate instance flavors balancing CPU, RAM, and I/O resources.

Storage Performance: Use SSD storage for databases and high-IOPS workloads. Configure
appropriate RAID levels balancing performance and redundancy. Use dedicated storage networks with
sufficient bandwidth. Enable caching where appropriate. Choose storage backends suited to access
patterns (block storage for databases, object storage for archives).

Network Performance: Use SR-IOV (Single Root I/O Virtualization) or DPDK (Data Plane
Development Kit) for high-performance networking when needed. Implement appropriate network
segmentation to reduce broadcast domains. Use jumbo frames (MTU > 1500) on storage networks.
Configure appropriate Quality of Service (QoS) policies.

Operational Procedures
Establishing operational procedures ensures reliable OpenStack operation.

Backup and Recovery: Implement regular backups of OpenStack databases (Nova, Glance, Neutron,
Cinder, Keystone databases), configuration files across all nodes, and Glance images. Test recovery
procedures regularly to ensure backups are functional. Consider backup strategies for instance data
using Cinder snapshots or image creation.

Monitoring and Alerting: Deploy comprehensive monitoring covering infrastructure health (servers,
network devices, storage systems), OpenStack service status (API availability, service processes),
resource utilization (compute, storage, network capacity), and performance metrics (API response
times, instance launch times). Configure alerting for critical conditions enabling rapid response to
issues.

Upgrade Management: Plan upgrades carefully, testing in non-production environments first.

Follow the recommended upgrade paths between OpenStack releases. Understand that upgrades

489
typically require downtime or careful rolling procedures. Back up all data and configurations before
upgrades. Document rollback procedures in case issues occur.

Documentation and Knowledge Management

Maintaining documentation supports effective operations and knowledge transfer.

Architecture Documentation: Document the deployment architecture including network topology,

server inventory, service distribution, and configuration decisions. This documentation helps
troubleshooting, capacity planning, and onboarding new team members.

Operational Runbooks: Create runbooks for common operations like launching instances, creating
volumes, managing networks, adding compute nodes, responding to alerts, and performing backups.
Standardized procedures improve consistency and reduce errors.

Change Management: Document all changes to the environment including configuration

modifications, version upgrades, and architectural changes. Maintain a change log to track when
changes occurred and who made them, supporting troubleshooting and audit requirements.

Neutron (OpenStack Networking)

OpenStack Networking, known as Neutron, is responsible for creating and managing virtual
networking infrastructure within OpenStack cloud environments. This software-defined networking
solution provides comprehensive control over network resources and can adapt in real-time to
changing requirements. Neutron handles the creation and management of virtual networking
infrastructure elements including networks, subnets, and routers. Beyond basic connectivity, it
supports advanced services such as firewalls and virtual private networks (VPNs). The infrastructure
elements are entirely software-defined, meaning they exist as logical constructs that can be dynamically
created, modified, and destroyed without requiring physical hardware changes.

Deployment Flexibility: OpenStack Networking provides administrators with significant flexibility

in deployment architecture. All service daemons can run on a single physical host for evaluation or
testing purposes. However, in production environments, each service can be distributed across unique
physical hosts or replicated across multiple hosts to provide redundancy and high availability. This
flexibility allows organizations to scale their networking infrastructure according to their specific
requirements and resource constraints.

Software-Defined Advantages: Because OpenStack Networking operates as a software-defined

solution, it can react in real-time to changing network needs. This includes the dynamic creation and
assignment of new IP addresses as virtual machines are provisioned or network requirements change.
Traditional hardware-based networking would require manual intervention and physical configuration
changes, whereas Neutron handles these operations programmatically through API calls.

OpenStack Networking Components

Network Agent: The Network agent is a service that runs on each OpenStack node to perform local
networking configuration. Its primary responsibility is configuring networking for the virtual machines

490
running on that particular node. It also manages networking services such as Open vSwitch, which is
a software-based virtual switch that provides network connectivity between virtual machines and to
external networks. The agent runs locally on each compute node, ensuring that network configuration
is properly applied to the VMs hosted on that node.

neutron-dhcp-agent: The neutron-dhcp-agent is an agent component that provides DHCP (Dynamic

Host Configuration Protocol) services to tenant networks. When virtual machines boot up, they need
IP addresses and network configuration information. The DHCP agent automatically assigns IP
addresses from predefined pools and provides additional network configuration parameters such as
subnet masks, default gateways, and DNS server addresses. This eliminates the need for manual IP
address assignment and ensures consistent network configuration across tenant networks.

neutron-ml2: The neutron-ml2 component is a plug-in that manages network drivers and provides
routing and switching services for networking services. ML2 stands for Modular Layer 2, and this plug-
in architecture allows OpenStack to support multiple networking technologies simultaneously. It can
work with various networking backends such as Open vSwitch or Ryu networks. The ML2 plug-in
abstracts the underlying network implementation, allowing administrators to choose the most
appropriate networking technology for their deployment while maintaining a consistent API interface.

neutron-server: The neutron-server is a Python daemon that serves as the central management
component for OpenStack Networking. It manages user requests and exposes the Networking API,
which other OpenStack services and users interact with to create and manage network resources. The
default server configuration uses a plug-in architecture with a specific set of networking mechanisms
to implement the Networking API functionality. Within the neutron-server ecosystem, certain plug-
ins deserve special mention. The openvswitch and linuxbridge plug-ins use native Linux networking
mechanisms, leveraging the kernel's built-in networking capabilities. Meanwhile, other plug-ins can
interface with external devices or Software-Defined Networking (SDN) controllers, allowing
OpenStack to integrate with specialized networking hardware or advanced SDN platforms for
enhanced functionality.

neutron (CLI Client): The neutron component itself refers to the command-line client used to access
the Networking API. This tool allows administrators and users to interact with OpenStack Networking
from the terminal, creating networks, subnets, routers, and other networking objects through
command-line commands. The CLI provides scriptable access to all networking functionality, enabling
automation and integration with other tools.

OpenStack Networking Deployment Architecture

Physical Infrastructure: The deployment diagram shows three physical switches (Switch 1, Switch 2,
Switch 3) and a Router at the top layer. These physical devices provide the underlying connectivity for
the OpenStack infrastructure. Switch 1 connects to management and tenant network traffic, Switch 2
handles tenant network traffic, and Switch 3 connects to both tenant network and provider network
traffic. The Router provides connectivity to external provider networks.

Compute Nodes: The architecture includes two compute nodes (COMPUTE NODE 1 and
COMPUTE NODE 2). Each compute node runs Open vSwitch instances (Open vSwitch 1 and Open

491
vSwitch 2 respectively) that provide virtual switching capabilities. These virtual switches connect to
both management/tenant network and regular tenant network switches. Each compute node hosts
Virtual Machines (Virtual Machine 1 and Virtual Machine 2), which are connected through the Open
vSwitch instances. The compute nodes are where actual workloads run, and the networking
components ensure these VMs can communicate with each other and with external networks.

Network Node: The deployment includes a dedicated NETWORK NODE 1 that hosts several
critical networking components. This node contains Open vSwitch 3, which connects to both tenant
network and provider network switches. The network node also hosts the Neutron Router, which
provides routing capabilities between different networks. Additionally, it includes several important
services: The Provider Network component manages connectivity to external networks outside the
OpenStack environment. The Metadata proxy service provides a way for instances to access metadata
about themselves, which is crucial for cloud-init and similar configuration mechanisms. FWaaS
(Firewall as a Service) provides firewall functionality for securing network traffic. LBaaS (Load Balancer
as a Service) offers load balancing capabilities for distributing traffic across multiple instances.

Service Layer: At the bottom of the diagram, an OPENSTACK NETWORKING SERVICE layer
spans across all nodes, representing the coordinated networking functionality that ties all these
components together. This service layer ensures consistent network behavior across the entire
deployment and provides the API and management plane for all networking operations.

Neutron Networking Advantages

OpenStack Networking provides several significant advantages over traditional networking
approaches, particularly in terms of flexibility, scalability, and automation.

User Control and Flexibility: Users have extensive control over their network environment. They
can create networks, control traffic flow, and connect servers and devices to one or more networks as
needed. This self-service capability eliminates the need for manual intervention by network
administrators for routine networking tasks. The flexible networking models can adapt to varying
network volumes and multi-tenancy requirements, allowing different tenants to have isolated networks
with their own addressing schemes and policies.

IP Address Management: OpenStack Networking supports both dedicated and floating IP

addresses. Dedicated IP addresses are permanently assigned to specific instances, providing stable
addressing for long-running services. Floating IPs, however, can be dynamically reassigned between
instances, enabling use cases like dynamic traffic rerouting for high availability or blue-green
deployments. When one instance fails, its floating IP can be quickly reassigned to a standby instance,
minimizing downtime.

VLAN-Based Networks: When using VLAN (Virtual Local Area Network) networking, the system
can support a maximum of 4094 VLANs, which translates to 4094 separate networks. This number is
derived from the 12-bit VLAN ID header field, which provides 2^12 = 4096 possible values, minus 2
unusable reserved values (VLAN IDs 0 and 4095). This limitation is inherent to the IEEE 802.1Q
standard that defines VLAN tagging. While 4094 networks may seem like a large number, in massive
cloud deployments with many tenants each requiring multiple isolated networks, this can become a

492
constraint. Each tenant might need separate networks for production, development, testing, and DMZ
environments, quickly consuming available VLAN IDs.

VXLAN-Based Networks: To overcome VLAN limitations, OpenStack Networking supports

VXLAN (Virtual Extensible LAN) tunnel-based networks. VXLAN uses a 24-bit VNI (Virtual
Network Identifier) in its header, which provides 2^24 = 16,777,216 possible unique addresses or
networks. This massive increase in available network identifiers makes VXLAN particularly suitable
for large-scale cloud deployments with extensive multi-tenancy requirements. VXLAN operates by
encapsulating Layer 2 Ethernet frames within Layer 4 UDP packets, allowing virtual networks to span
across Layer 3 boundaries. This encapsulation also means VXLAN traffic can traverse existing IP
networks without requiring extensive reconfiguration of network infrastructure.

Cinder (Block Storage Service)

Architectural Context: The diagram shows Cinder positioned within the OpenStack service
ecosystem, displayed with a database icon representing volume storage. It sits alongside other core
services including Nova (Compute), Glance (Image Service), Swift (Object Store), Quantum
(Networking), Keystone (Identity Service), and is accessed through the Horizon Dashboard. This
positioning illustrates how Cinder integrates with the overall OpenStack architecture.
Functionality and Purpose: Cinder provides Block Storage (Volume) Service functionality, delivering
block storage for virtual machines in the form of persistent disks. Unlike ephemeral instance storage
that disappears when an instance is terminated, Cinder volumes persist independently of instance
lifecycle. This makes them ideal for storing data that must survive instance termination, such as
databases, application state, or user data. The service is conceptually similar to Amazon EBS (Elastic
Block Store) service, providing comparable functionality in the OpenStack ecosystem. Users can create
volumes of specified sizes, attach them to running instances, detach them, and reattach them to
different instances as needed.
Extensibility: Cinder employs a plugin architecture for vendor extensions, allowing storage vendors
to integrate their specialized storage solutions with OpenStack. For example, NetApp provides a driver
for Cinder that allows OpenStack to utilize NetApp storage systems. This plugin architecture ensures
that organizations can leverage their existing storage infrastructure investments while benefiting from
OpenStack's cloud management capabilities.

Horizon (Dashboard)
Horizon provides the web-based graphical interface for OpenStack, making cloud resources accessible
through a browser-based dashboard.

User Interface: The diagram shows Horizon positioned at the top of the OpenStack service stack,
represented by a control panel icon. This positioning reflects its role as the primary user interface layer
that sits above the core services. Horizon provides a simple self-service UI for end-users, allowing
them to manage their cloud resources without needing to learn command-line tools or write API calls.

Administrative Functions: Beyond end-user self-service, Horizon provides basic cloud administrator
functions that are essential for day-to-day operations. Administrators can define users, tenants
(projects), and quotas through the dashboard interface. Users represent individual accounts with
authentication credentials. Tenants (also called projects in newer OpenStack versions) provide resource

493
isolation, allowing different groups or customers to have separate resource pools. Quotas limit the
amount of resources each tenant can consume, preventing any single tenant from monopolizing cloud
resources.

Scope Limitations: Importantly, Horizon does not provide infrastructure management capabilities.
Physical server configuration, network switch management, storage array setup, and similar
infrastructure tasks must be performed through other tools. Horizon focuses exclusively on managing
the virtual resources and services that run on top of the infrastructure layer.

OpenStack Architecture Planes

OpenStack architecture is conceptually divided into two main planes that serve distinct purposes within
the overall system.

Control Plane
The Control Plane is responsible for the management and orchestration of cloud resources. This plane
includes components like Keystone for identity management, Horizon for the dashboard interface,
and the APIs of other core services. The control plane handles user authentication, service
coordination, and resource scheduling. It manages tasks such as user authentication, service
coordination, and resource scheduling. When a user requests a new instance, the control plane
processes this request by authenticating the user through Keystone, checking quotas, determining
where the instance should be placed, reserving necessary resources, and coordinating with various
services to fulfill the request. The control plane operates on a separate network from user data traffic,
often called the management network, ensuring that administrative traffic doesn't interfere with
production workloads.

Data Plane
The Data Plane handles the actual user data and workloads. It includes compute instances managed by
Nova, data stored in Swift and Cinder, and networking components managed by Neutron. This is
where real-time data processing and storage occur, ensuring that applications and services perform
efficiently. When an instance processes user requests, serves web pages, performs database queries, or
executes any application logic, all of this activity occurs in the data plane. Similarly, when instances
communicate with each other or with external networks, this traffic flows through the data plane
networking infrastructure. The data plane must provide high performance and low latency since it
directly affects user experience and application responsiveness. Unlike the control plane, which handles
relatively infrequent administrative operations, the data plane operates continuously with high
throughput requirements.

Interaction Between Components

OpenStack's true power emerges from how its components interact seamlessly to deliver a cohesive
cloud experience. Understanding these interactions is crucial for appreciating how OpenStack
functions as an integrated platform rather than a collection of independent services.

Nova and Neutron Interaction: Nova interacts extensively with Neutron to provision and manage
network resources for virtual machines. When Nova creates a new instance, it communicates with
Neutron to request network connectivity. Neutron responds by creating virtual network interfaces,

494
assigning IP addresses from the appropriate subnet, and configuring virtual switches to provide
connectivity. This interaction ensures proper network isolation between different tenants while
providing necessary connectivity for instances to communicate with each other and with external
networks. For example, when launching an instance attached to a specific network, Nova sends a
request to Neutron specifying which network the instance should connect to. Neutron then allocates
a port on that network, assigns an IP address, and configures the virtual networking infrastructure to
route traffic to and from that port. Nova receives the port details and configures the instance's virtual
network interface accordingly.

Cinder and Nova Interaction: When a virtual machine needs additional storage beyond its ephemeral
disk, Nova communicates with Cinder to attach block storage volumes. The user might request volume
attachment through Horizon or the command line, but behind the scenes, Nova coordinates with
Cinder to make this happen. Cinder creates or identifies the requested volume, prepares it for
attachment, and provides connection information to Nova. Nova then configures the hypervisor to
expose the volume to the instance as a block device, providing persistent storage for applications. For
instance, if a database instance needs a 100GB volume for storing data, the administrator creates a
volume in Cinder, then issues an attachment request. Nova coordinates with Cinder to establish the
connection, and the volume appears inside the instance as a device like /dev/vdb. The database
application can then format and mount this volume, ensuring data persists even if the instance is
terminated and recreated.

Keystone and All Services: Keystone integrates with all other OpenStack components to manage
authentication and authorization. Every API request to any OpenStack service must first be validated
by Keystone. When a user attempts an operation, the service receiving the request forwards the user's
authentication token to Keystone for validation. Keystone verifies the token is valid and checks
whether the user has permission to perform the requested operation in their specific tenant context.
This centralized authentication ensures consistent security policy enforcement. For example, if a user
attempts to delete a volume in Cinder, Cinder sends the user's token to Keystone. Keystone verifies
the token is valid and checks if the user has the admin or owner role for the tenant containing that
volume. Only if authorization succeeds does Cinder proceed with the deletion. This same pattern
repeats for every operation across all services, ensuring secure access management.

Glance and Nova Interaction: During the launch of new instances, Nova retrieves the required
images from Glance. When a user specifies which image to use for a new instance, Nova doesn't
directly access the image file. Instead, it requests the image from Glance, which locates the image in its
storage backend and streams it to the compute node where the instance will run. This ensures instances
boot with the correct configurations including the appropriate operating system, pre-installed packages,
and initial filesystem structure. The interaction typically involves Nova requesting image metadata from
Glance to verify the image meets the instance's requirements (sufficient disk space, compatible
architecture, etc.). Once validated, Nova requests the actual image data, and Glance streams it to the
compute node. The hypervisor then uses this image as the basis for creating the instance's root disk.

Integration for Cloud Management: By understanding the logical architecture of OpenStack and
how components interact, IT managers, system administrators, and cloud architects can better plan,
deploy, and manage their cloud environments. This knowledge enables informed decisions about
architecture design, capacity planning, troubleshooting, and optimization. Understanding that Nova
and Neutron must communicate helps administrators ensure proper network configuration between

495
compute and network nodes. Recognizing Keystone's central role emphasizes the importance of
securing and maintaining the identity service. Appreciating how Glance and Nova interact highlights
the need for adequate network bandwidth between image storage and compute nodes for efficient
instance provisioning. This comprehensive understanding ensures optimal performance and scalability,
allowing organizations to build cloud infrastructures that meet their specific requirements while
maintaining reliability, security, and efficiency.

OpenStack Cloud Platform Documentation

OpenStack is an open-source cloud operating system that controls large pools of compute, storage,
and networking resources throughout a datacenter, all managed through a dashboard or via APIs. The
platform allows organizations to build and manage private and public cloud computing platforms.

OpenStack Dashboard Interface

The document begins by showing the OpenStack login interface, which serves as the entry point for
users to access the cloud platform. The login screen features the OpenStack logo prominently and
contains two input fields: one for "User Name" and another for "Password." A "Sign In" button allows
users to authenticate and access the system. This web-based interface provides administrators and users
with a centralized location to manage all OpenStack resources.

Password Management
After logging in, users can access the password change functionality. The system provides a dedicated
"Change Password" page accessible through Settings. This page requires three inputs: the current
password for verification, the new password, and confirmation of the new password to prevent typing
errors. The interface includes a description stating "Change your password. We highly recommend you
create a strong one." This emphasizes security best practices. A "Change" button completes the
password update process. This functionality ensures users can maintain secure access to their cloud
resources by regularly updating their credentials.

Project Overview Dashboard

The Project Overview dashboard provides a comprehensive view of resource usage and limits within
the OpenStack environment. This dashboard is organized into several key sections that display both
compute and storage resources.

Limit Summary - Compute Resources The Limit Summary section displays resource utilization
through visual pie charts and numerical indicators. For compute resources, the dashboard shows:
Instances: Displays the number of virtual machines currently running versus the total allowed. The
example shows "Used 0 of 10," indicating no instances are currently active but the project has a quota
of 10 instances. VCPUs: Shows virtual CPU allocation with "Used 0 of 20," meaning no virtual CPUs
are currently allocated from a total quota of 20 vCPUs. RAM: Displays memory usage as "Used 0Bytes
of 50GB," showing that no RAM is currently allocated from the 50GB quota. These metrics help
administrators monitor resource consumption and ensure they stay within allocated quotas.

Limit Summary - Volume Resources The volume section tracks storage-related resources:
Volumes: Shows "Used 0 of 10," indicating no volumes are created from the allowed quota of 10

496
volumes. Volume Snapshots: Displays "Used 0 of 10," tracking snapshots of volumes for backup
purposes. Volume Storage: Shows "Used 0Bytes of 1000GB," indicating total storage capacity
available for volumes is 1000GB (1TB) with none currently used.

Limit Summary - Network Resources The network section provides visibility into networking
resource usage: Floating IPs: Shows "Allocated 0 of 50," indicating that no floating IP addresses
(public IPs that can be dynamically assigned to instances) have been allocated from the pool of 50.
Security Groups: Displays "Used 1 of 10," showing that one security group exists out of a maximum
of 10 allowed. Security groups act as virtual firewalls controlling traffic to instances. Security Group
Rules: Shows "Used 4 of 100," indicating that 4 firewall rules have been configured from a maximum
of 100 rules. Networks: Displays "Used 1 of 100," showing one network has been created from a
quota of 100 networks. Ports: Shows "Used 0 of 500," tracking network ports (connection points for
instances to networks). Routers: Displays "Used 0 of 10," showing no routers have been created from
the allowed quota of 10. Routers connect different networks together.

Usage Summary The Usage Summary section allows users to query resource usage over specific time
periods. Users can select a date range using a format like "2019-11-27" to "2019-11-28" and click
"Submit" to generate usage reports. The system displays metrics including:
● Active Instances: Number of running instances during the period
● Active RAM: Amount of RAM in use
● This Period's VCPU-Hours: Total CPU hours consumed
● This Period's GB-Hours: Total storage capacity used over time
● This Period's RAM-Hours: Total RAM consumption over time
This temporal tracking helps with capacity planning and cost analysis.

System Administration
The Admin section provides system-level information about the OpenStack deployment. Under
Admin > System > System Information, administrators can view comprehensive details about all
services running in the OpenStack environment.
Service Categories
The System Information page is organized into tabs:
● Services: Lists all core OpenStack services
● Compute Services: Shows compute-specific services
● Block Storage Services: Displays storage service details
● Network Agents: Lists networking components

Detailed Service Listing

The Services tab displays 11 items with detailed information in a table format:
Service columns include:
● Name: Service identifier (e.g., aodh, neutron, ceilometer, cinderv2, glance, nova, cinderv3,
gnocchi, swift)
● Service: Service type (alarming, network, metering, volumev2, image, compute, volumev3,
metric, object-store)
● Region: Deployment region (all services shown as "RegionOne")
● Endpoints: Three endpoint types for each service
○ Admin: Administrative endpoint ([Link]

497
 ○ Internal: Internal network endpoint ([Link]
○ Public: Public-facing endpoint ([Link]

Each service has unique port numbers for its endpoints. For example:

● aodh (alarming service) uses port 8042

● neutron (network service) uses port 9696
● ceilometer (metering service) uses port 8777
● cinder (volume services v2 and v3) use different endpoint structures
● glance (image service) uses port 9292
● nova (compute service) uses complex endpoint URLs
● gnocchi (metric service) uses port 8041
● swift (object-store) uses port 8080 with authentication paths

Compute Services Detail

The Compute Services tab shows three compute-related services:

● nova-conductor: Handles database access for compute nodes ([Link], zone:

internal, Status: Enabled, State: Up)
● nova-scheduler: Schedules instances to compute hosts ([Link], zone: internal,
Status: Enabled, State: Up)
● nova-compute: Manages virtual machine lifecycle ([Link], zone: nova, Status:
Enabled, State: Up)
All services show "Last Updated: 0 minutes," indicating they are actively reporting their status.

Block Storage Services

The Block Storage Services tab displays Cinder-related services with a highlighted Status and State
section:

● cinder-scheduler: Schedules volume creation ([Link], zone: nova, Status:

Enabled, State: Up)
● cinder-backup: Handles volume backups ([Link], zone: nova, Status:
Enabled, State: Up)
● cinder-volume: Manages volume operations ([Link]:lvm, zone: nova, Status:
Enabled, State: Up)
The red highlight box emphasizes the Status and State columns, which are critical for monitoring
service health.

Network Agents
The Network Agents tab shows five networking components with their status highlighted:

● DHCP agent: Provides DHCP services (neutron-dhcp-agent, Host: [Link],

Zone: internal, Status: Enabled, State: Up)
● Metering agent: Tracks network usage (neutron-metering-agent, Host:
[Link], Status: Enabled, State: Up)
● Open vSwitch agent: Manages virtual switching (neutron-openvswitch-agent, Host:
[Link], Status: Enabled, State: Up)

498
 ● L3 agent: Provides layer 3 routing (neutron-l3-agent, Host: [Link], Zone:
nova, Status: Enabled, State: Up, with "View Routers" action)
● Metadata agent: Provides instance metadata (neutron-metadata-agent, Host:
[Link], Status: Enabled, State: Up)

All agents report "Last Updated: 0 minutes" and are in an Up state, indicating healthy operation.

Hypervisor Management
The Hypervisors page (Admin > Compute > All Hypervisors) provides information about the physical
compute hosts running virtual machines. The page shows a Hypervisor Summary with visual indicators
for resource usage.

Hypervisor Resource Summary

Three pie charts display:
VCPU Usage: "Used 0 of 1" - Shows total virtual CPU capacity across all hypervisors Memory
Usage: "Used 512MB of 5.9GB" - Displays total memory across compute hosts Local Disk Usage:
"Used 0Bytes of 21GB" - Shows total local storage capacity

Hypervisor Detail Table

The page includes two views: Hypervisor and Compute Host tabs. The Hypervisor tab displays one
item:

● Hostname: "[Link]"
● Type: "QEMU" (indicating QEMU/KVM virtualization)
● VCPUs (used): "0" - No virtual CPUs currently allocated
● VCPUs (total): "1" - One physical CPU core available
● RAM (used): "512MB" - Memory in use
● RAM (total): "5.9GB" - Total physical memory
● Local Storage (used): "0Bytes" - No local storage consumed
● Local Storage (total): "21GB" - Total local disk space
● Instances: "0" - No instances currently running on this hypervisor
This information is crucial for capacity planning and understanding the physical infrastructure
supporting the cloud.

Network Management
Networks Page: The Networks page (Project > Network > Networks) allows users to view and
manage virtual networks. The interface shows a table with columns for Name, Subnets Associated,
Shared status, External status, Status, Admin State, and Availability Zones.
In the example shown, one network exists:

● Name: "external_network"
● Subnets Associated: None shown
● Shared: "No" - Not shared across projects
● External: "Yes" - Configured as an external network for public connectivity
● Status: "Active"

499
 ● Admin State: "UP"
● Availability Zones: "nova"

Action buttons include "Create Network" and "Delete Networks" for network management. A Filter
search box allows finding specific networks.

Routers Page: The Routers page (Project > Network > Routers) displays routing infrastructure. The
example shows "No items to display," indicating no routers have been created yet. Routers are essential
for connecting different networks and providing connectivity between internal networks and external
networks.
The page includes columns for:

● Name
● Status
● External Network
● Admin State
● Availability Zones
● Actions
A "Create Router" button allows administrators to create new routing instances.

Security Groups
The Security Groups page (Project > Network > Security Groups) displays firewall rule sets that
control traffic to instances. The page shows one security group:
● Name: "default"
● Security Group ID: "86a84553-2c6b-406f-b90c-f2ab861c387d"
● Description: "Default security group"
● Actions: "Manage Rules" button

Security groups function as virtual firewalls, defining ingress (incoming) and egress (outgoing) traffic
rules. Each project starts with a default security group that typically allows all outbound traffic but
restricts inbound traffic. Buttons at the top include "Create Security Group" and "Delete Security
Groups" for managing these firewall rule sets. A Filter box enables searching for specific security
groups.

Architecture
The diagram illustrates several key layers and components:
User Layer: At the top, an end user connects to the application through the internet.

Load Balancer (NEUTRON): The first component users interact with is the load balancer, which
distributes incoming traffic across multiple application servers. This is managed by Neutron,
OpenStack's networking service.

Web Tier - Auto-scaling Group: The web tier consists of multiple Nova compute instances that can
automatically scale based on demand. This tier is protected by a Web Security Group (NEUTRON),
which acts as a firewall controlling access to web servers. The diagram shows this as an "Auto-scaling

500
group" with a dashed box indicating a compute instance that can be dynamically added or removed.
These instances handle user requests and serve web pages.

Middle Load Balancer: Another load balancer sits between the web tier and application tier,
distributing requests from web servers to application servers.

Application Tier - Auto-scaling Group: Similar to the web tier, the application tier consists of Nova
compute instances in an auto-scaling group. These are protected by an App Security Group
(NEUTRON). These instances handle business logic and application processing.

Database Tier - Master/Slave Replication: The database layer uses a master-slave configuration for
high availability and failover:

● MASTER: The primary database instance handles write operations

● SLAVE: A replica database provides failover capability and read scalability
● Both databases are protected by a DB Security Group (NEUTRON)
● The diagram shows "Fail-over & replication" between master and slave
● Each database instance has attached Cinder Volumes for persistent storage (shown as boxes
beneath each database server)

Object Storage: A Swift Repo (Swift repository) is shown at the bottom, providing object storage for
database backups. Swift offers scalable, redundant storage for unstructured data.

Backup Process: An arrow labeled "DB Backup" connects the master database to the Swift storage,
illustrating the backup workflow.

Failure Recovery: The diagram includes a note: "Start new instance to replace fail-node, re-attach
Cinder volume." This illustrates OpenStack's resilience—if a database node fails, a new instance can
be launched and the persistent Cinder volume can be reattached, ensuring data is not lost.

Security Architecture
Each tier is isolated by security groups:
● WEB SECURITY GROUP (NEUTRON): Controls traffic to web servers
● APP SECURITY GROUP (NEUTRON): Controls traffic to application servers
● DB SECURITY GROUP (NEUTRON): Controls traffic to database servers
This layered security model implements defense in depth, ensuring that even if one layer is
compromised, others remain protected.

OpenStack Conceptual Architecture

Application Layer: At the top of the diagram is a box labeled "Your Applications," representing
workloads and applications that run on the OpenStack cloud infrastructure. These applications use
OpenStack services through APIs.
API Communication: A blue arrow labeled "APIs" points downward from "Your Applications" to
the OpenStack services layer, indicating that applications interact with OpenStack components through
well-defined Application Programming Interfaces. OpenStack provides RESTful APIs for each
service.

501
Core Service Components: The middle layer shows three primary service categories represented as
colored cubes:
Compute (Yellow/Green Cube): This represents Nova, the compute service responsible for:

● Provisioning and managing virtual machine instances

● Scheduling instances to physical hosts
● Managing the lifecycle of VMs (start, stop, suspend, resume)
● Providing various instance types (flavors)

Networking (Purple Cube): This represents Neutron, the networking service responsible for:

● Creating and managing virtual networks

● Providing connectivity between instances
● Managing IP address allocation
● Implementing security groups and firewall rules
● Creating routers and load balancers

Storage (Blue Cube): This represents storage services including:

● Cinder: Block storage for attaching persistent volumes to instances

● Swift: Object storage for storing large amounts of unstructured data
● Glance: Image storage for virtual machine templates

Dashboard Access: On the left side, the "OpenStack Dashboard" (represented by a computer
monitor icon) shows how administrators and users interact with OpenStack. The dashboard connects
via APIs to all three service categories. The Horizon dashboard provides a web-based interface for:
● Managing resources visually
● Monitoring usage
● Configuring services
● Creating and managing instances, networks, and storage

Shared Services Layer: Below the three core service cubes is a blue platform labeled "OpenStack
Shared Services." This layer contains supporting services used by all core services:

● Keystone: Identity and authentication

● Oslo: Common libraries and utilities
● Database services: MySQL or PostgreSQL for storing service data
● Message queue: RabbitMQ or other AMQP implementations for inter-service
communication
● Caching services: Memcached for performance optimization

Infrastructure Layer: At the bottom is a gray box labeled "Standard Hardware," indicating that
OpenStack runs on commodity hardware. This abstraction layer allows OpenStack to:
● Run on various hardware configurations
● Utilize different hypervisors (KVM, Xen, VMware, etc.)
● Support diverse networking equipment
● Work with various storage backends

502
This architecture demonstrates OpenStack's modular design, where each component can be scaled
independently and replaced with alternative implementations while maintaining API compatibility.

Web Applications Use Case

The section begins by explaining that interactive web applications are currently the most prevalent
applications in business today. Both consumers and enterprises interact with employees, customers,
and partners online using applications such as online banking, human resources systems, tax filing
platforms, and even pet adoption websites.

This lists several prominent organizations successfully using OpenStack to deliver interactive web
applications at scale:

● Workday: Enterprise cloud applications

● Betfair: Online betting and gaming
● [Link]: Genealogy and family history
● JFE Steel: Industrial manufacturing
● HMRC (Her Majesty's Revenue and Customs): UK tax authority
● LivePerson: Customer engagement platform
These diverse examples demonstrate OpenStack's versatility across industries.

Dynamic Resource Allocation: A key point emphasized is that IT resource needs for web
applications often fluctuate with end-user demand, either predictably (such as tax season for HMRC)
or unpredictably (such as viral marketing campaigns). Failure to respond to either scenario can
negatively impact customer satisfaction and sales. The ability to dynamically add and remove resources
is identified as one of the primary benefits of using an OpenStack cloud.

Reference Architecture: The document references a Web Applications reference architecture that
teaches users how to use OpenStack services to build a three-tier web application on an existing
OpenStack cloud. Users are encouraged to try the architecture themselves using Heat templates
provided in the Community Application Catalog.

Heat Template Deployment

The Heat template automates the deployment process by:

● Setting up new virtual machines for each application tier

● Creating private networks for each tier with proper isolation
● Configuring connections between tiers
● Deploying load balancers for traffic distribution
● Setting up routers for network connectivity
● Applying security groups for access control

The template deploys the popular LAMP stack (Linux, Apache, MySQL, PHP) into the tiers and uses
WordPress as an example web application to demonstrate functionality.

503
Template Variants
Two templates are provided in the deployment package:

1. Auto-scaling template: Automatically adds or removes resources based on demand

2. Manual scaling template: Requires manual intervention to scale resources

Required OpenStack Services

The target OpenStack cloud must be configured with specific services:

● Six core projects: Nova (compute), Neutron (networking), Cinder (block storage), Swift
(object storage), Glance (image), Keystone (identity)
● Heat: Required for using the deployment template and orchestration
● Ceilometer: Required specifically for auto-scaling deployment to monitor resource usage and
trigger scaling actions
● Trove: Referenced but not used in the sample configuration (provides database as a service)

This comprehensive approach allows organizations to deploy production-ready web applications

quickly while leveraging OpenStack's scalability and flexibility.

OpenStack Installation in Ubuntu

The objective is to install OpenStack on Ubuntu 18.04 using DevStack, which is a development
environment tool that simplifies the deployment process for learning and testing purposes. OpenStack
is a free and open-source Infrastructure as a Service (IaaS) cloud platform that manages cloud compute,
storage, and network resources. It provides administrators with an intuitive dashboard for provisioning
and monitoring these resources. OpenStack serves as the world's leading open-source cloud platform
and continues growing in adoption across organizations of all sizes and industries.

Advantages of OpenStack
Cost Savings: Being an open-source project, OpenStack provides significant cost savings compared
to proprietary virtualization solutions from vendors like VMware, Citrix, and Proxmox families.
Organizations avoid expensive licensing fees while maintaining full functionality.

Cloud Platform Flexibility: OpenStack functions as a fully functional cloud platform that can serve
as an extension to existing cloud infrastructure or as a reasonable alternative to hyperscalers (major
cloud providers like AWS, Azure, Google Cloud). This effectively addresses two critical concerns:
cloud cost optimization by reducing dependency on expensive cloud services, and digital sovereignty
by allowing organizations to maintain control over their data and infrastructure rather than relying
entirely on third-party providers.

DevStack: DevStack is a set of extensible scripts specifically designed to facilitate OpenStack

deployment. It automates the complex installation process, making it accessible for learning,
development, and testing purposes. DevStack is particularly useful for setting up OpenStack quickly
on a local Ubuntu instance without requiring extensive manual configuration.

504
Deployment Mode: The installation described in this guide uses single-node mode, meaning all
OpenStack services will be installed and run on a single machine. This is suitable for development,
learning, and testing but differs from production deployments which typically use multi-node
architectures for redundancy and scalability.

Installation Process
Step 1: Update and Upgrade the System
The first step involves ensuring the system has the latest package information and updates installed.
apt update -y && apt upgrade -y

apt update -y: This command refreshes the package repository index, downloading information about
the newest versions of packages and their dependencies from the configured sources. The -y flag
automatically answers "yes" to any prompts, making the process non-interactive.
&&: This operator chains commands together, executing the second command only if the first
succeeds.
apt upgrade -y: This command actually installs newer versions of the packages currently installed on
the system. Again, the -y flag ensures automatic confirmation.

Connection Method: Users should log into the Ubuntu 18.04 system using SSH (Secure Shell)
protocol, which provides encrypted remote access to the server.

Sample Output Analysis: The sample output in the PDF shows the system connecting to various
Ubuntu repository mirrors ([Link]) and downloading package
information from different repositories including:
● Main repository (bionic InRelease)
● Updates repository (bionic-updates InRelease)
● Backports repository (bionic-backports InRelease)
● Universe repository (bionic/universe)
● Security repository (bionic-security InRelease)
● Multiverse repository (bionic/multiverse)

The output displays download progress with file sizes (in kB), indicating successful connection to
package repositories.

System Reboot: After completing updates and upgrades, reboot the system using:

sudo reboot

This command restarts the system to ensure all updated packages, especially kernel updates, are
properly loaded and active.

Step 2: Create Stack User and Assign Sudo Privileges

Following best practices, DevStack should not be run as the root user but rather as a regular user with
sudo privileges. This approach provides better security and prevents accidental system-wide changes.

505
Create the Stack User:

sudo adduser -s /bin/bash -d /opt/stack -m stack

sudo: Executes the command with administrative privileges

adduser: Command to add a new user to the system
-s /bin/bash: Specifies the shell for the new user. /bin/bash is the Bourne Again Shell, the standard
Linux shell
-d /opt/stack: Sets the home directory for the user to /opt/stack instead of the default /home/stack
-m stack: Creates the home directory if it doesn't exist and names the user "stack"

Assign Sudo Privileges:

echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack

echo "stack ALL=(ALL) NOPASSWD: ALL": This creates a string that defines sudo permissions
stack: The username this rule applies to
ALL=(ALL): Allows the user to run commands as any user from any host
NOPASSWD: ALL: Permits running all commands without requiring password authentication
|: Pipe operator that sends the output of the echo command to the next command
sudo tee /etc/sudoers.d/stack: The tee command writes the input to the file /etc/sudoers.d/stack,
which is the proper location for custom sudo rules. Using tee with sudo allows writing to protected
system files.

Sample Output Analysis: The sample output shows successful execution of the commands with
confirmation that the sudo rule has been written to the sudoers file.

Step 3: Install Git and Download DevStack

After creating the stack user, the next step involves switching to this user and preparing to download
DevStack.

Switch to Stack User:

su - stack

This command switches the current session to the stack user. The - ensures a login shell is started,
loading all environment variables and settings for the stack user.

Install Git:

sudo apt install git -y

Git is a version control system necessary for cloning (downloading) the DevStack repository from the
internet. In most Ubuntu 18.04 systems, git comes pre-installed. However, if it's missing, this command
installs it. The -y flag automatically confirms the installation. The sample output demonstrates that git
is already installed (version 1:2.17.1-1ubuntu0.4) and shows that some automatically installed packages
(grub-pc-bin, libnuma1) are no longer required and can be removed using sudo apt autoremove.

506
Clone DevStack Repository:

git clone [Link]

git clone: Command to create a local copy of a remote repository

[Link] The URL of the official DevStack repository

The command downloads all DevStack scripts and files to a local directory named "devstack" in the
current working directory (/opt/stack).

Clone Output Analysis: The sample output shows:

● Cloning into 'devstack' directory
● Warning about redirection to [Link]
● Progress information: enumerating, counting, compressing, and receiving objects (43,615
objects total)
● Final message showing successful completion with delta compression
● Confirmation that a 'devstack' directory has been created

Step 4: Create DevStack Configuration File

The configuration file defines how OpenStack will be deployed, including passwords and network
settings.

Navigate to DevStack Directory:

cd devstack

This changes the current working directory to the newly cloned devstack folder.

Create Configuration File:

vim [Link]

This opens the vim text editor to create a new file called [Link]. This is the main configuration file
that DevStack reads during installation.

Configuration File Content:

[[local|localrc]]

# Password for KeyStone, Database, RabbitMQ and Service

ADMIN_PASSWORD=StrongAdminSecret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

# Host IP - get your Server/VM IP address from ip addr command

HOST_IP=[Link]

507
[[local|localrc]] marks the beginning of the local configuration section that DevStack will process.

ADMIN_PASSWORD=StrongAdminSecret: Sets the password for the admin user in OpenStack.

This is the primary password used to log into the OpenStack dashboard. Users should replace
"StrongAdminSecret" with a secure password of their choice.
DATABASE_PASSWORD=$ADMIN_PASSWORD: Sets the database password to match the
admin password. The $ADMIN_PASSWORD syntax references the previously defined variable.
RABBIT_PASSWORD=$ADMIN_PASSWORD: Sets the password for RabbitMQ, which is the
message queue service used for inter-service communication in OpenStack.
SERVICE_PASSWORD=$ADMIN_PASSWORD: Sets the password for OpenStack services to
authenticate with each other.

HOST_IP=[Link]: Specifies the IP address of the server where OpenStack is being installed. This
should be set to the actual IP address of the system, which can be obtained using the ifconfig or ip
addr command. The IP address is crucial for accessing the OpenStack dashboard from a web browser.

Notes: Two critical configuration points are highlighted:

Note 1: The ADMIN_PASSWORD is the password used to log into the OpenStack login page. The
default username for OpenStack is "admin".

Note 2: The HOST_IP represents the system's IP address, which must be obtained by running either
ifconfig or ip addrcommands on the server. This IP address is necessary for network communication
and web browser access to the dashboard.

After entering this content, save and exit the text editor (in vim, press Escape, type :wq, and press
Enter).

Step 5: Install OpenStack with DevStack

This step executes the actual installation process.

Run Installation Script:

./[Link]

./: Indicates the file is in the current directory

[Link]: The main DevStack installation script that automates the entire OpenStack deployment
process This script automatically downloads, configures, and installs all required OpenStack
components and their dependencies.

Successful Completion Indicators: The completion output shows:

This is your host IP address: [Link]

This is your host IPv6 address: ::1
Horizon is now available at [Link]
Keystone is serving at [Link]
The default users are: admin and demo
The password: StrongAdminSecret

508
Output Interpretation:

Host IP addresses: Both IPv4 ([Link]) and IPv6 (::1) addresses are displayed
Horizon URL: The web dashboard is accessible at [Link]
Keystone URL: The identity service endpoint at [Link]
Default users: Two users are created automatically:
admin: Administrative user with full privileges
demo: Demo user for testing with limited privileges
Password confirmation: Displays the password configured in [Link]

The output includes:

A warning that lib/neutron-legacy is deprecated and will be removed in future versions

Information that services are running under systemd unit files
Reference link to DevStack documentation:
[Link]
DevStack version information showing the git commit hash
OS version confirmation: Ubuntu 18.04 bionic
Timestamp showing completion time

Step 6: Accessing OpenStack on a Web Browser

After successful installation, OpenStack can be accessed through a web browser.

Access URL:

[Link]

Replace server-ip with the actual IP address displayed in the installation output. For example:
[Link]

Login Page Description: The login page displays the OpenStack logo (a red and white stylized
platform icon) with the text "openstack" beneath it. Below this is a "Log in" section with two input
fields:

User Name Field: A text input box where users enter their username (default is "admin")

Password Field: A password input box with a visibility toggle icon (eye icon) allowing users to show
or hide the password as they type

Login Credentials:
Username: admin (or demo for the demonstration user)
Password: The password configured in [Link] (StrongAdminSecret in the example)

After Login - Management Console: After clicking "Sign In" and successfully authenticating, users
access the Management Console dashboard.

509