OpenStack Installation Guide
OpenStack Installation Guide
OpenStack contributors
1 Conventions                                                                                                                                                       1
  1.1 Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                 1
  1.2 Command prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                     1
2 Preface                                                                                                                                                           3
  2.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                3
  2.2 Operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                   3
4 Overview                                                                                                                                                           9
  4.1 Example architecture . . . . .      . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
       4.1.1 Controller . . . . . .       . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
       4.1.2 Compute . . . . . .          . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
       4.1.3 Block Storage . . . .        . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
       4.1.4 Object Storage . . .         . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
  4.2 Networking . . . . . . . . . .      . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   11
       4.2.1 Networking Option 1:         Provider networks .                           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
       4.2.2 Networking Option 2:         Self-service networks                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
5 Environment                                                                                                                                                       15
  5.1 Security . . . . . . . . . . . . . . . . . . . . . . . .                          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   16
  5.2 Host networking . . . . . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   17
       5.2.1  Controller node . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   19
       5.2.2  Compute node . . . . . . . . . . . . . . . .                              .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   21
       5.2.3  Block storage node (Optional) . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
       5.2.4  Verify connectivity . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
  5.3 Network Time Protocol (NTP) . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
       5.3.1  Controller node . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
       5.3.2  Other nodes . . . . . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
       5.3.3  Verify operation . . . . . . . . . . . . . . .                            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
  5.4 OpenStack packages . . . . . . . . . . . . . . . . .                              .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
       5.4.1  OpenStack packages for SUSE . . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
       5.4.2  OpenStack packages for RHEL and CentOS                                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
       5.4.3  OpenStack packages for Ubuntu . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   33
                                                                                                                                                                     i
     5.5   SQL database . . . . . . . . . . . . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   34
           5.5.1    SQL database for SUSE . . . . . . .                     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   34
           5.5.2    SQL database for RHEL and CentOS                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   35
           5.5.3    SQL database for Ubuntu . . . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   36
     5.6   Message queue . . . . . . . . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   37
           5.6.1    Message queue for SUSE . . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   38
           5.6.2    Message queue for RHEL and CentOS                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   38
           5.6.3    Message queue for Ubuntu . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   39
     5.7   Memcached . . . . . . . . . . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   40
           5.7.1    Memcached for SUSE . . . . . . . .                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   40
           5.7.2    Memcached for RHEL and CentOS .                         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   41
           5.7.3    Memcached for Ubuntu . . . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   41
     5.8   Etcd . . . . . . . . . . . . . . . . . . . . . . .               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   42
           5.8.1    Etcd for SUSE . . . . . . . . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   42
           5.8.2    Etcd for RHEL and CentOS . . . . .                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   45
           5.8.3    Etcd for Ubuntu . . . . . . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   45
7 Launch an instance                                                                                                                                                53
  7.1 Create virtual networks . . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   53
       7.1.1   Provider network . . . . . . . . . . . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   53
       7.1.2   Self-service network . . . . . . . . . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   57
  7.2 Create m1.nano flavor . . . . . . . . . . . . . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   63
  7.3 Generate a key pair . . . . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   64
  7.4 Add security group rules . . . . . . . . . . . . . . . . .                                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   65
  7.5 Launch an instance . . . . . . . . . . . . . . . . . . . .                                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   66
       7.5.1   Launch an instance on the provider network . .                                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   66
       7.5.2   Launch an instance on the self-service network                                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   71
  7.6 Block Storage . . . . . . . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   78
       7.6.1   Block Storage . . . . . . . . . . . . . . . . . .                                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   78
  7.7 Orchestration . . . . . . . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   80
  7.8 Shared File Systems . . . . . . . . . . . . . . . . . . .                                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   80
9 Appendix                                                                                                                                                          83
  9.1 Community support . . . . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   83
       9.1.1 Documentation . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   83
       9.1.2 The OpenStack wiki . .             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   84
       9.1.3 The Launchpad bugs area            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   84
       9.1.4 Documentation feedback             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   85
ii
         9.1.5   The OpenStack IRC channel . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    85
         9.1.6   OpenStack mailing lists . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    85
         9.1.7   OpenStack distribution packages       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    86
   9.2   Glossary . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    86
         9.2.1   0-9 . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    86
         9.2.2   A . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    86
         9.2.3   B . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    90
         9.2.4   C . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    92
         9.2.5   D . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    98
         9.2.6   E. . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   101
         9.2.7   F. . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   103
         9.2.8   G . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   105
         9.2.9   H . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   106
         9.2.10 I . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   107
         9.2.11 J . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   111
         9.2.12 K . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   111
         9.2.13 L . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   112
         9.2.14 M . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   113
         9.2.15 N . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   115
         9.2.16 O . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   117
         9.2.17 P . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   120
         9.2.18 Q . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   122
         9.2.19 R . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   123
         9.2.20 S . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   126
         9.2.21 T . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   131
         9.2.22 U . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   132
         9.2.23 V . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   133
         9.2.24 W . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   135
         9.2.25 X . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   135
         9.2.26 Y . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   136
         9.2.27 Z . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   136
Index 137
                                                                                                                                                            iii
iv
                                                                                           CHAPTER
ONE
CONVENTIONS
1.1 Notices
Note: A comment with additional information that explains a part of the text.
Caution: Helpful information that prevents the user from making mistakes.
Warning: Critical information about the risk of data loss or security issues.
$ command
Any user, including the root user, can run commands that are prefixed with the $ prompt.
# command
The root user must run commands that are prefixed with the # prompt. You can also prefix these com-
mands with the sudo command, if available, to run them.
                                                                                                 1
Install Guide
2               Chapter 1. Conventions
                                                                                            CHAPTER
TWO
PREFACE
2.1 Abstract
The OpenStack system consists of several key services that are separately installed. These services work
together depending on your cloud needs and include the Compute, Identity, Networking, Image, Block
Storage, Object Storage, Telemetry, Orchestration, and Database services. You can install any of these
projects separately and configure them stand-alone or as connected entities.
Explanations of configuration options and sample configuration files are included.
This guide documents the installation of OpenStack starting with the Pike release. It covers multiple
releases.
 Warning: This guide is a work-in-progress and is subject to updates frequently. Pre-release packages
 have been used for testing, and some instructions may not work with final versions. Please help us
 make this guide better by reporting any errors you encounter.
Currently, this guide describes OpenStack installation for the following Linux distributions:
openSUSE and SUSE Linux Enterprise Server
     You can install OpenStack by using packages on openSUSE Leap 42.3, openSUSE Leap 15, SUSE
     Linux Enterprise Server 12 SP4, SUSE Linux Enterprise Server 15 through the Open Build Service
     Cloud repository.
Red Hat Enterprise Linux and CentOS
     You can install OpenStack by using packages available on both Red Hat Enterprise Linux 7 and 8
     and their derivatives through the RDO repository.
      Note: OpenStack Wallaby is available for CentOS Stream 8. OpenStack Ussuri and Victoria
      are available for both CentOS 8 and RHEL 8. OpenStack Train and earlier are available on both
      CentOS 7 and RHEL 7.
Ubuntu
    You can walk through an installation by using packages available through Canonicals Ubuntu
    Cloud archive repository for Ubuntu 16.04+ (LTS).
                                                                                                        3
Install Guide
     Note: The Ubuntu Cloud Archive pockets for Pike and Queens provide OpenStack packages for
     Ubuntu 16.04 LTS; OpenStack Queens is installable direct using Ubuntu 18.04 LTS; the Ubuntu
     Cloud Archive pockets for Rocky and Stein provide OpenStack packages for Ubuntu 18.04 LTS;
     the Ubuntu Cloud Archive pocket for Victoria provides OpenStack packages for Ubuntu 20.04
     LTS.
4                                                                         Chapter 2. Preface
                                                                                            CHAPTER
THREE
The OpenStack project is an open source cloud computing platform for all types of clouds, which aims
to be simple to implement, massively scalable, and feature rich. Developers and cloud computing tech-
nologists from around the world create the OpenStack project.
OpenStack provides an Infrastructure-as-a-Service (IaaS) solution through a set of interrelated services.
Each service offers an Application Programming Interface (API) that facilitates this integration. Depend-
ing on your needs, you can install some or all services.
The OpenStack project navigator lets you browse the OpenStack services that make up the OpenStack
architecture. The services are categorized per the service type and release series.
                                                                                                       5
Install Guide
The following diagram shows the relationships among the OpenStack services:
To design, deploy, and configure OpenStack, administrators must understand the logical architecture.
As shown in Conceptual architecture, OpenStack consists of several independent parts, named the Open-
Stack services. All services authenticate through a common Identity service. Individual services interact
with each other through public APIs, except where privileged administrator commands are necessary.
Internally, OpenStack services are composed of several processes. All services have at least one API
process, which listens for API requests, preprocesses them and passes them on to other parts of the
service. With the exception of the Identity service, the actual work is done by distinct processes.
For communication between the processes of one service, an AMQP message broker is used. The ser-
vices state is stored in a database. When deploying and configuring your OpenStack cloud, you can
choose among several message broker and database solutions, such as RabbitMQ, MySQL, MariaDB,
and SQLite.
Users can access OpenStack via the web-based user interface implemented by the Horizon Dashboard,
via command-line clients and by issuing API requests through tools like browser plug-ins or curl. For
applications, several SDKs are available. Ultimately, all these access methods issue REST API calls to
the various OpenStack services.
The following diagram shows the most common, but not the only possible, architecture for an OpenStack
cloud:
FOUR
OVERVIEW
The OpenStack project is an open source cloud computing platform that supports all types of cloud
environments. The project aims for simple implementation, massive scalability, and a rich set of features.
Cloud computing experts from around the world contribute to the project.
OpenStack provides an Infrastructure-as-a-Service (IaaS) solution through a variety of complementary
services. Each service offers an Application Programming Interface (API) that facilitates this integration.
This guide covers step-by-step deployment of the major OpenStack services using a functional example
architecture suitable for new users of OpenStack with sufficient Linux experience. This guide is not
intended to be used for production system installations, but to create a minimum proof-of-concept for the
purpose of learning about OpenStack.
After becoming familiar with basic installation, configuration, operation, and troubleshooting of these
OpenStack services, you should consider the following steps toward deployment using a production ar-
chitecture:
    • Determine and implement the necessary core and optional services to meet performance and re-
      dundancy requirements.
    • Increase security using methods such as firewalls, encryption, and service policies.
    • Use a deployment tool such as Ansible, Chef, Puppet, or Salt to automate deployment and manage-
      ment of the production environment. The OpenStack project has a couple of deployment projects
      with specific guides per version: - Yoga release - Xena release - Wallaby release - Victoria release
      - Ussuri release - Train release - Stein release - Rocky release - Queens release - Pike release
The example architecture requires at least two nodes (hosts) to launch a basic virtual machine or instance.
Optional services such as Block Storage and Object Storage require additional nodes.
Important: The example architecture used in this guide is a minimum configuration, and is not intended
for production system installations. It is designed to provide a minimum proof-of-concept for the purpose
of learning about OpenStack. For information on creating architectures for specific use cases, or how to
determine which architecture is required, see the Architecture Design Guide.
                                                                                                         9
Install Guide
     • Overlay (tunnel) traffic for self-service networks traverses the management network instead of a
       dedicated network.
For more information on production architectures for Pike, see the Architecture Design Guide, OpenStack
Networking Guide for Pike, and OpenStack Administrator Guides for Pike.
For more information on production architectures for Queens, see the Architecture Design Guide, Open-
Stack Networking Guide for Queens, and OpenStack Administrator Guides for Queens.
For more information on production architectures for Rocky, see the Architecture Design Guide, Open-
Stack Networking Guide for Rocky, and OpenStack Administrator Guides for Rocky.
10                                                                            Chapter 4. Overview
                                                                                       Install Guide
4.1.1 Controller
The controller node runs the Identity service, Image service, Placement service, management portions
of Compute, management portion of Networking, various Networking agents, and the Dashboard. It also
includes supporting services such as an SQL database, message queue, and NTP.
Optionally, the controller node runs portions of the Block Storage, Object Storage, Orchestration, and
Telemetry services.
The controller node requires a minimum of two network interfaces.
4.1.2 Compute
The compute node runs the hypervisor portion of Compute that operates instances. By default, Compute
uses the KVM hypervisor. The compute node also runs a Networking service agent that connects instances
to virtual networks and provides firewalling services to instances via security groups.
You can deploy more than one compute node. Each node requires a minimum of two network interfaces.
The optional Block Storage node contains the disks that the Block Storage and Shared File System ser-
vices provision for instances.
For simplicity, service traffic between compute nodes and this node uses the management network. Pro-
duction environments should implement a separate storage network to increase performance and security.
You can deploy more than one block storage node. Each node requires a minimum of one network
interface.
The optional Object Storage node contain the disks that the Object Storage service uses for storing ac-
counts, containers, and objects.
For simplicity, service traffic between compute nodes and this node uses the management network. Pro-
duction environments should implement a separate storage network to increase performance and security.
This service requires two nodes. Each node requires a minimum of one network interface. You can
deploy more than two object storage nodes.
4.2 Networking
4.2. Networking                                                                                     11
Install Guide
The provider networks option deploys the OpenStack Networking service in the simplest way possible
with primarily layer-2 (bridging/switching) services and VLAN segmentation of networks. Essentially,
it bridges virtual networks to physical networks and relies on physical network infrastructure for layer-3
(routing) services. Additionally, a DHCP service provides IP address information to instances.
The OpenStack user requires more information about the underlying network infrastructure to create a
virtual network to exactly match the infrastructure.
 Warning: This option lacks support for self-service (private) networks, layer-3 (routing) services,
 and advanced services such as LBaaS and FWaaS. Consider the self-service networks option below
 if you desire these features.
12                                                                              Chapter 4. Overview
                                                                                         Install Guide
The self-service networks option augments the provider networks option with layer-3 (routing) services
that enable self-service networks using overlay segmentation methods such as VXLAN. Essentially, it
routes virtual networks to physical networks using NAT . Additionally, this option provides the foundation
for advanced services such as LBaaS and FWaaS.
The OpenStack user can create virtual networks without the knowledge of underlying infrastructure on
the data network. This can also include VLAN networks if the layer-2 plug-in is configured accordingly.
4.2. Networking                                                                                        13
Install Guide
14              Chapter 4. Overview
                                                                                            CHAPTER
FIVE
ENVIRONMENT
This section explains how to configure the controller node and one compute node using the example
architecture.
Although most environments include Identity, Image service, Compute, at least one networking service,
and the Dashboard, the Object Storage service can operate independently. If your use case only involves
Object Storage, you can skip to
    • Object Storage Installation Guide for Yoga
    • Object Storage Installation Guide for Stein
    • Object Storage Installation Guide for Rocky
    • Object Storage Installation Guide for Queens
    • Object Storage Installation Guide for Pike
after configuring the appropriate nodes for it.
You must use an account with administrative privileges to configure each node. Either run the commands
as the root user or configure the sudo utility.
Note: The systemctl enable call on openSUSE outputs a warning message when the service uses
SysV Init scripts instead of native systemd files. This warning can be ignored.
For best performance, we recommend that your environment meets or exceeds the hardware requirements
in Hardware requirements.
The following minimum requirements should support a proof-of-concept environment with core services
and several CirrOS instances:
    • Controller Node: 1 processor, 4 GB memory, and 5 GB storage
    • Compute Node: 1 processor, 2 GB memory, and 10 GB storage
As the number of OpenStack services and virtual machines increase, so do the hardware requirements
for the best performance. If performance degrades after enabling additional services or virtual machines,
consider adding hardware resources to your environment.
To minimize clutter and provide more resources for OpenStack, we recommend a minimal installation of
your Linux distribution. Also, you must install a 64-bit version of your distribution on each node.
A single disk partition on each node works for most basic installations. However, you should consider
Logical Volume Manager (LVM) for installations with optional services such as Block Storage.
                                                                                                      15
Install Guide
For first-time installation and testing purposes, many users select to build each host as a virtual machine
(VM). The primary benefits of VMs include the following:
     • One physical server can support multiple nodes, each with almost any number of network inter-
       faces.
     • Ability to take periodic snap shots throughout the installation process and roll back to a working
       configuration in the event of a problem.
However, VMs will reduce performance of your instances, particularly if your hypervisor and/or proces-
sor lacks support for hardware acceleration of nested VMs.
Note: If you choose to install on VMs, make sure your hypervisor provides a way to disable MAC
address filtering on the provider network interface.
For more information about system requirements, see the OpenStack Pike Administrator Guides, the
OpenStack Queens Administrator Guides, or the OpenStack Rocky Administrator Guides.
5.1 Security
OpenStack services support various security methods including password, policy, and encryption. Addi-
tionally, supporting services including the database server and message broker support password security.
To ease the installation process, this guide only covers password security where applicable. You can
create secure passwords manually, but the database connection string in services configuration file cannot
accept special characters like @. We recommend you generate them using a tool such as pwgen, or by
running the following command:
For OpenStack services, this guide uses SERVICE_PASS to reference service account passwords and
SERVICE_DBPASS to reference database passwords.
The following table provides a list of services that require passwords and their associated references in
the guide.
16                                                                          Chapter 5. Environment
                                                                                          Install Guide
                                      Table 1: Passwords
 Password name                              Description
 Database password (no variable used)       Root password for the database
 ADMIN_PASS                                 Password of user admin
 CINDER_DBPASS                              Database password for the Block Storage service
 CINDER_PASS                                Password of Block Storage service user cinder
 DASH_DBPASS                                Database password for the Dashboard
 DEMO_PASS                                  Password of user demo
 GLANCE_DBPASS                              Database password for Image service
 GLANCE_PASS                                Password of Image service user glance
 KEYSTONE_DBPASS                            Database password of Identity service
 METADATA_SECRET                            Secret for the metadata proxy
 NEUTRON_DBPASS                             Database password for the Networking service
 NEUTRON_PASS                               Password of Networking service user neutron
 NOVA_DBPASS                                Database password for Compute service
 NOVA_PASS                                  Password of Compute service user nova
 PLACEMENT_PASS                             Password of the Placement service user placement
 RABBIT_PASS                                Password of RabbitMQ user openstack
OpenStack and supporting services require administrative privileges during installation and operation.
In some cases, services perform modifications to the host that can interfere with deployment automation
tools such as Ansible, Chef, and Puppet. For example, some OpenStack services add a root wrapper
to sudo that can interfere with security policies. See the Compute service documentation for Pike, the
Compute service documentation for Queens, or the Compute service documentation for Rocky for more
information.
The Networking service assumes default values for kernel network parameters and modifies firewall
rules. To avoid most issues during your initial installation, we recommend using a stock deployment of
a supported distribution on your hosts. However, if you choose to automate deployment of your hosts,
review the configuration and policies applied to them before proceeding further.
After installing the operating system on each node for the architecture that you choose to deploy, you must
configure the network interfaces. We recommend that you disable any automated network management
tools and manually edit the appropriate configuration files for your distribution. For more information
on how to configure networking on your distribution, see the documentation.
See also:
    • Ubuntu Network Configuration
    • RHEL 7 or RHEL 8 Network Configuration
    • SLES 12 or SLES 15 or openSUSE Network Configuration
All nodes require Internet access for administrative purposes such as package installation, security up-
dates, DNS, and NTP. In most cases, nodes should obtain Internet access through the management net-
work interface. To highlight the importance of network separation, the example architectures use private
address space for the management network and assume that the physical network infrastructure provides
Internet access via NAT or other methods. The example architectures use routable IP address space
for the provider (external) network and assume that the physical network infrastructure provides direct
Internet access.
In the provider networks architecture, all instances attach directly to the provider network. In the self-
service (private) networks architecture, instances can attach to a self-service or provider network. Self-
service networks can reside entirely within OpenStack or provide some level of external network access
using NAT through the provider network.
18                                                                          Chapter 5. Environment
                                                                                         Install Guide
Note: Ubuntu has changed the network interface naming concept. Refer Changing Network Interfaces
name Ubuntu 16.04.
Unless you intend to use the exact configuration provided in this example architecture, you must modify
the networks in this procedure to match your environment. Each node must resolve the other nodes by
name in addition to IP address. For example, the controller name must resolve to 10.0.0.11, the IP
address of the management interface on the controller node.
Note: RHEL, CentOS and SUSE distributions enable a restrictive firewall by default. Ubuntu does not.
For more information about securing your environment, refer to the OpenStack Security Guide.
             DEVICE=INTERFACE_NAME
             TYPE=Ethernet
             ONBOOT="yes"
             BOOTPROTO="none"
        For SUSE:
           • Edit the /etc/sysconfig/network/ifcfg-INTERFACE_NAME file to contain the follow-
             ing:
             STARTMODE='auto'
             BOOTPROTO='static'
        # controller
        10.0.0.11            controller
        # compute1
        10.0.0.31            compute1
        # block1
        10.0.0.41            block1
        # object1
        10.0.0.51            object1
        # object2
        10.0.0.52            object2
         Warning: Some distributions add an extraneous entry in the /etc/hosts file that resolves
         the actual hostname to another loopback IP address such as 127.0.1.1. You must comment
         out or remove this entry to prevent name resolution problems. Do not remove the 127.0.0.1
         entry.
        Note: This guide includes host entries for optional services in order to reduce complexity should
        you choose to deploy them.
20                                                                         Chapter 5. Environment
                                                                                        Install Guide
Note: Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on.
  2. The provider interface uses a special configuration without an IP address assigned to it. Configure
     the second interface as the provider interface:
     Replace INTERFACE_NAME with the actual interface name. For example, eth1 or ens224.
     For Ubuntu:
        • Edit the /etc/network/interfaces file to contain the following:
          DEVICE=INTERFACE_NAME
          TYPE=Ethernet
          ONBOOT="yes"
          BOOTPROTO="none"
     For SUSE:
        • Edit the /etc/sysconfig/network/ifcfg-INTERFACE_NAME file to contain the follow-
          ing:
          STARTMODE='auto'
          BOOTPROTO='static'
        # controller
        10.0.0.11           controller
        # compute1
        10.0.0.31           compute1
        # block1
        10.0.0.41           block1
        # object1
        10.0.0.51           object1
        # object2
        10.0.0.52           object2
         Warning: Some distributions add an extraneous entry in the /etc/hosts file that resolves
         the actual hostname to another loopback IP address such as 127.0.1.1. You must comment
         out or remove this entry to prevent name resolution problems. Do not remove the 127.0.0.1
         entry.
        Note: This guide includes host entries for optional services in order to reduce complexity should
        you choose to deploy them.
If you want to deploy the Block Storage service, configure one additional storage node.
22                                                                         Chapter 5. Environment
                                                                                      Install Guide
     # controller
     10.0.0.11            controller
     # compute1
     10.0.0.31            compute1
     # block1
     10.0.0.41            block1
     # object1
     10.0.0.51            object1
     # object2
     10.0.0.52            object2
       Warning: Some distributions add an extraneous entry in the /etc/hosts file that resolves
       the actual hostname to another loopback IP address such as 127.0.1.1. You must comment
       out or remove this entry to prevent name resolution problems. Do not remove the 127.0.0.1
       entry.
     Note: This guide includes host entries for optional services in order to reduce complexity should
     you choose to deploy them.
We recommend that you verify network connectivity to the Internet and among the nodes before pro-
ceeding further.
  1. From the controller node, test access to the Internet:
     # ping -c 4 docs.openstack.org
     PING files02.openstack.org (23.253.125.17) 56(84) bytes of data.
     64 bytes from files02.openstack.org (23.253.125.17): icmp_seq=1 ttl=43␣
      ,→time=125 ms
2. From the controller node, test access to the management interface on the compute node:
# ping -c 4 compute1
# ping -c 4 openstack.org
4. From the compute node, test access to the management interface on the controller node:
# ping -c 4 controller
Note: RHEL, CentOS and SUSE distributions enable a restrictive firewall by default. During the instal-
lation process, certain steps will fail unless you alter or disable the firewall. For more information about
24                                                                           Chapter 5. Environment
                                                                                        Install Guide
To properly synchronize services among nodes, you can install Chrony, an implementation of NTP. We
recommend that you configure the controller node to reference more accurate (lower stratum) servers and
other nodes to reference the controller node.
For SUSE:
   2. Edit the chrony.conf file and add, change, or remove the following keys as necessary for your
      environment.
      For RHEL, CentOS, or SUSE, edit the /etc/chrony.conf file:
      Replace NTP_SERVER with the hostname or IP address of a suitable more accurate (lower stratum)
      NTP server. The configuration supports multiple server keys.
      Note: By default, the controller node synchronizes the time via a pool of public servers. However,
      you can optionally configure alternative servers such as those provided by your organization.
     3. To enable other nodes to connect to the chrony daemon on the controller node, add this key to the
        same chrony.conf file mentioned above:
allow 10.0.0.0/24
Other nodes reference the controller node for clock synchronization. Perform these steps on all other
nodes.
For SUSE:
     2. Configure the chrony.conf file and comment out or remove all but one server key. Change it
        to reference the controller node.
        For RHEL, CentOS, or SUSE, edit the /etc/chrony.conf file:
26                                                                          Chapter 5. Environment
                                                                                     Install Guide
We recommend that you verify NTP synchronization before proceeding further. Some nodes, particularly
those that reference the controller node, can take several minutes to synchronize.
   1. Run this command on the controller node:
# chronyc sources
      Contents in the Name/IP address column should indicate the hostname or IP address of one or
      more NTP servers. Contents in the MS column should indicate * for the server to which the NTP
      service is currently synchronized.
   2. Run the same command on all other nodes:
# chronyc sources
Contents in the Name/IP address column should indicate the hostname of the controller node.
Distributions release OpenStack packages as part of the distribution or using other methods because of
differing release schedules. Perform these procedures on all nodes.
Note: The set up of OpenStack packages described here needs to be done on all nodes: controller,
compute, and Block Storage nodes.
 Warning: Your hosts must contain the latest versions of base installation packages available for your
 distribution before proceeding further.
Note: Disable or remove any automatic update services because they can impact your OpenStack envi-
ronment.
Distributions release OpenStack packages as part of the distribution or using other methods because of
differing release schedules. Perform these procedures on all nodes.
Note: The set up of OpenStack packages described here needs to be done on all nodes: controller,
compute, and Block Storage nodes.
 Warning: Your hosts must contain the latest versions of base installation packages available for your
 distribution before proceeding further.
Note: Disable or remove any automatic update services because they can impact your OpenStack envi-
ronment.
     • Enable the Open Build Service repositories based on your openSUSE or SLES version, and on the
       version of OpenStack you want to install:
       On openSUSE for OpenStack Ussuri:
28                                                                        Chapter 5. Environment
                                                                                      Install Guide
    Note: The openSUSE distribution uses the concept of patterns to represent collections of pack-
    ages. If you selected Minimal Server Selection (Text Mode) during the initial installation, you may
    be presented with a dependency conflict when you attempt to install the OpenStack packages. To
    avoid this, remove the minimal_base-conflicts package:
# zypper rm patterns-openSUSE-minimal_base-conflicts
    Note: The packages are signed by GPG key D85F9316. You should verify the fingerprint of the
    imported GPG key before using it.
Note: If the upgrade process includes a new kernel, reboot your host to activate it.
Distributions release OpenStack packages as part of the distribution or using other methods because of
differing release schedules. Perform these procedures on all nodes.
 Warning: Starting with the Ussuri release, you will need to use either CentOS8 or RHEL 8. Previous
 OpenStack releases will need to use either CentOS7 or RHEL 7. Instructions are included for both
 distributions and versions where different.
Note: The set up of OpenStack packages described here needs to be done on all nodes: controller,
compute, and Block Storage nodes.
 Warning: Your hosts must contain the latest versions of base installation packages available for your
 distribution before proceeding further.
Note: Disable or remove any automatic update services because they can impact your OpenStack envi-
ronment.
30                                                                          Chapter 5. Environment
                                                                                       Install Guide
Prerequisites
 Warning: We recommend disabling EPEL when using RDO packages due to updates in EPEL
 breaking backwards compatibility. Or, preferably pin package versions using the yum-versionlock
 plugin.
Note: The following steps apply to RHEL only. CentOS does not require these steps.
  1. When using RHEL, it is assumed that you have registered your system using Red
     Hat Subscription Management and that you have the rhel-7-server-rpms or
     rhel-8-for-x86_64-baseos-rpms repository enabled by default depending on your ver-
     sion.
     For more information on registering a RHEL 7 system, see the Red Hat Enterprise Linux 7 System
     Administrators Guide.
  2. In addition to rhel-7-server-rpms on a RHEL 7 system, you also need to
     have the rhel-7-server-optional-rpms,          rhel-7-server-extras-rpms, and
     rhel-7-server-rh-common-rpms repositories enabled:
     For more information on registering a RHEL 8 system, see the Red Hat Enterprise Linux 8 Instal-
     lation Guide.
     In addition to rhel-8-for-x86_64-baseos-rpms on a RHEL 8 system, you also need to have the
     rhel-8-for-x86_64-appstream-rpms, rhel-8-for-x86_64-supplementary-rpms, and
     codeready-builder-for-rhel-8-x86_64-rpms repositories enabled:
   • On CentOS, the extras repository provides the RPM that enables the OpenStack repository. Cen-
     tOS includes the extras repository by default, so you can simply install the package to enable the
     OpenStack repository. For CentOS8, you will also need to enable the PowerTools repository.
     When installing the Victoria release, run:
      • On RHEL, download and install the RDO repository RPM to enable the OpenStack repository.
        On RHEL 7:
On RHEL 8:
The RDO repository RPM installs the latest available OpenStack release.
# yum upgrade
Note: If the upgrade process includes a new kernel, reboot your host to activate it.
     3. RHEL and CentOS enable SELinux by default. Install the openstack-selinux package to auto-
        matically manage security policies for OpenStack services:
32                                                                          Chapter 5. Environment
                                                                                      Install Guide
Ubuntu releases OpenStack with each Ubuntu release. Ubuntu LTS releases are provided every two years.
OpenStack packages from interim releases of Ubuntu are made available to the prior Ubuntu LTS via the
Ubuntu Cloud Archive.
Note: The archive enablement described here needs to be done on all nodes that run OpenStack services.
Archive Enablement
# add-apt-repository cloud-archive:zed
# add-apt-repository cloud-archive:yoga
# add-apt-repository cloud-archive:xena
# add-apt-repository cloud-archive:wallaby
# add-apt-repository cloud-archive:victoria
# add-apt-repository cloud-archive:ussuri
# add-apt-repository cloud-archive:train
# add-apt-repository cloud-archive:stein
# add-apt-repository cloud-archive:rocky
Note: For a full list of supported Ubuntu OpenStack releases, see Ubuntu OpenStack release cycle at
https://www.ubuntu.com/about/release-cycle.
Sample Installation
Client Installation
Most OpenStack services use an SQL database to store information. The database typically runs on the
controller node. The procedures in this guide use MariaDB or MySQL depending on the distribution.
OpenStack services also support other SQL databases including PostgreSQL.
Note: If you see Too many connections or Too many open files error log messages on Open-
Stack services, verify that maximum number of connection settings are well applied to your environment.
In MariaDB, you may also need to change open_files_limit configuration.
Most OpenStack services use an SQL database to store information. The database typically runs on the
controller node. The procedures in this guide use MariaDB or MySQL depending on the distribution.
OpenStack services also support other SQL databases including PostgreSQL.
34                                                                        Chapter 5. Environment
                                                                                    Install Guide
   2. Create and edit the /etc/my.cnf.d/openstack.cnf file and complete the following actions:
         • Create a [mysqld] section, and set the bind-address key to the management IP address
           of the controller node to enable access by other nodes via the management network. Set
           additional keys to enable useful options and the UTF-8 character set:
           [mysqld]
           bind-address = 10.0.0.11
           default-storage-engine = innodb
           innodb_file_per_table = on
           max_connections = 4096
           collation-server = utf8_general_ci
           character-set-server = utf8
Finalize installation
1. Start the database service and configure it to start when the system boots:
# mysql_secure_installation
Most OpenStack services use an SQL database to store information. The database typically runs on the
controller node. The procedures in this guide use MariaDB or MySQL depending on the distribution.
OpenStack services also support other SQL databases including PostgreSQL.
   2. Create and edit the /etc/my.cnf.d/openstack.cnf file (backup existing configuration files in
      /etc/my.cnf.d/ if needed) and complete the following actions:
         • Create a [mysqld] section, and set the bind-address key to the management IP address
           of the controller node to enable access by other nodes via the management network. Set
           additional keys to enable useful options and the UTF-8 character set:
             [mysqld]
             bind-address = 10.0.0.11
             default-storage-engine = innodb
             innodb_file_per_table = on
             max_connections = 4096
             collation-server = utf8_general_ci
             character-set-server = utf8
Finalize installation
1. Start the database service and configure it to start when the system boots:
# mysql_secure_installation
Most OpenStack services use an SQL database to store information. The database typically runs on the
controller node. The procedures in this guide use MariaDB or MySQL depending on the distribution.
OpenStack services also support other SQL databases including PostgreSQL.
Note: As of Ubuntu 16.04, MariaDB was changed to use the unix_socket Authentication Plugin. Local
authentication is now performed using the user credentials (UID), and password authentication is no
longer used by default. This means that the root user no longer uses a password for local access to the
server.
Note: As of Ubuntu 18.04, the mariadb-server package is no longer available from the default repos-
itory. To install successfully, enable the Universe repository on Ubuntu.
36                                                                           Chapter 5. Environment
                                                                                     Install Guide
           [mysqld]
           bind-address = 10.0.0.11
           default-storage-engine = innodb
           innodb_file_per_table = on
           max_connections = 4096
           collation-server = utf8_general_ci
           character-set-server = utf8
Finalize installation
# mysql_secure_installation
OpenStack uses a message queue to coordinate operations and status information among services. The
message queue service typically runs on the controller node. OpenStack supports several message queue
services including RabbitMQ, Qpid, and ZeroMQ. However, most distributions that package OpenStack
support a particular message queue service. This guide implements the RabbitMQ message queue service
because most distributions support it. If you prefer to implement a different message queue service,
consult the documentation associated with it.
The message queue runs on the controller node.
OpenStack uses a message queue to coordinate operations and status information among services. The
message queue service typically runs on the controller node. OpenStack supports several message queue
services including RabbitMQ, Qpid, and ZeroMQ. However, most distributions that package OpenStack
support a particular message queue service. This guide implements the RabbitMQ message queue service
because most distributions support it. If you prefer to implement a different message queue service,
consult the documentation associated with it.
The message queue runs on the controller node.
2. Start the message queue service and configure it to start when the system boots:
OpenStack uses a message queue to coordinate operations and status information among services. The
message queue service typically runs on the controller node. OpenStack supports several message queue
services including RabbitMQ, Qpid, and ZeroMQ. However, most distributions that package OpenStack
support a particular message queue service. This guide implements the RabbitMQ message queue service
because most distributions support it. If you prefer to implement a different message queue service,
consult the documentation associated with it.
The message queue runs on the controller node.
38                                                                          Chapter 5. Environment
                                                                                         Install Guide
2. Start the message queue service and configure it to start when the system boots:
OpenStack uses a message queue to coordinate operations and status information among services. The
message queue service typically runs on the controller node. OpenStack supports several message queue
services including RabbitMQ, Qpid, and ZeroMQ. However, most distributions that package OpenStack
support a particular message queue service. This guide implements the RabbitMQ message queue service
because most distributions support it. If you prefer to implement a different message queue service,
consult the documentation associated with it.
The message queue runs on the controller node.
5.7 Memcached
The Identity service authentication mechanism for services uses Memcached to cache tokens. The mem-
cached service typically runs on the controller node. For production deployments, we recommend en-
abling a combination of firewalling, authentication, and encryption to secure it.
The Identity service authentication mechanism for services uses Memcached to cache tokens. The mem-
cached service typically runs on the controller node. For production deployments, we recommend en-
abling a combination of firewalling, authentication, and encryption to secure it.
MEMCACHED_PARAMS="-l 10.0.0.11"
Finalize installation
• Start the Memcached service and configure it to start when the system boots:
40                                                                         Chapter 5. Environment
                                                                                    Install Guide
The Identity service authentication mechanism for services uses Memcached to cache tokens. The mem-
cached service typically runs on the controller node. For production deployments, we recommend en-
abling a combination of firewalling, authentication, and encryption to secure it.
OPTIONS="-l 127.0.0.1,::1,controller"
Finalize installation
• Start the Memcached service and configure it to start when the system boots:
The Identity service authentication mechanism for services uses Memcached to cache tokens. The mem-
cached service typically runs on the controller node. For production deployments, we recommend en-
abling a combination of firewalling, authentication, and encryption to secure it.
5.7. Memcached                                                                                   41
Install Guide
     2. Edit the /etc/memcached.conf file and configure the service to use the management IP address
        of the controller node. This is to enable access by other nodes via the management network:
-l 10.0.0.11
Finalize installation
5.8 Etcd
OpenStack services may use Etcd, a distributed reliable key-value store for distributed key locking, stor-
ing configuration, keeping track of service live-ness and other scenarios.
Right now, there is no distro package available for etcd3. This guide uses the tarball installation as a
workaround until proper distro packages are available.
The etcd service runs on the controller node.
     1. Install etcd:
            • Create etcd user:
42                                                                          Chapter 5. Environment
                                                                                   Install Guide
            #   mkdir   -p /etc/etcd
            #   chown   etcd:etcd /etc/etcd
            #   mkdir   -p /var/lib/etcd
            #   chown   etcd:etcd /var/lib/etcd
# uname -m
            # ETCD_VER=v3.2.7
            # rm -rf /tmp/etcd && mkdir -p /tmp/etcd
            # curl -L \
                   https://github.com/coreos/etcd/releases/download/${ETCD_VER}/
             ,→etcd-${ETCD_VER}-linux-amd64.tar.gz \
                   -o /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz
            # tar xzvf /tmp/etcd-${ETCD_VER}-linux-amd64.tar.gz \
                   -C /tmp/etcd --strip-components=1
            # cp /tmp/etcd/etcd /usr/bin/etcd
            # cp /tmp/etcd/etcdctl /usr/bin/etcdctl
            # ETCD_VER=v3.2.7
            # rm -rf /tmp/etcd && mkdir -p /tmp/etcd
            # curl -L \
                   https://github.com/coreos/etcd/releases/download/${ETCD_VER}/
             ,→etcd-${ETCD_VER}-linux-arm64.tar.gz \
                   -o /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz
            # tar xzvf /tmp/etcd-${ETCD_VER}-linux-arm64.tar.gz \
                   -C /tmp/etcd --strip-components=1
            # cp /tmp/etcd/etcd /usr/bin/etcd
            # cp /tmp/etcd/etcdctl /usr/bin/etcdctl
  2. Create and edit the /etc/etcd/etcd.conf.yml file and set the initial-cluster,
     initial-advertise-peer-urls, advertise-client-urls, listen-client-urls to the
     management IP address of the controller node to enable access by other nodes via the manage-
     ment network:
     name: controller
     data-dir: /var/lib/etcd
     initial-cluster-state: 'new'
     initial-cluster-token: 'etcd-cluster-01'
     initial-cluster: controller=http://10.0.0.11:2380
                                                                              (continues on next page)
5.8. Etcd                                                                                         43
Install Guide
        [Unit]
        After=network.target
        Description=etcd - highly-available key value store
        [Service]
        # Uncomment this on ARM64.
        # Environment="ETCD_UNSUPPORTED_ARCH=arm64"
        LimitNOFILE=65536
        Restart=on-failure
        Type=notify
        ExecStart=/usr/bin/etcd --config-file /etc/etcd/etcd.conf.yml
        User=etcd
        [Install]
        WantedBy=multi-user.target
# systemctl daemon-reload
Finalize installation
44                                                                 Chapter 5. Environment
                                                                                         Install Guide
OpenStack services may use Etcd, a distributed reliable key-value store for distributed key locking, stor-
ing configuration, keeping track of service live-ness and other scenarios.
The etcd service runs on the controller node.
      #[Member]
      ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
      ETCD_LISTEN_PEER_URLS="http://10.0.0.11:2380"
      ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379"
      ETCD_NAME="controller"
      #[Clustering]
      ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"
      ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"
      ETCD_INITIAL_CLUSTER="controller=http://10.0.0.11:2380"
      ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"
      ETCD_INITIAL_CLUSTER_STATE="new"
Finalize installation
OpenStack services may use Etcd, a distributed reliable key-value store for distributed key locking, stor-
ing configuration, keeping track of service live-ness and other scenarios.
The etcd service runs on the controller node.
5.8. Etcd                                                                                              45
Install Guide
        Note: As of Ubuntu 18.04, the etcd package is no longer available from the default repository.
        To install successfully, enable the Universe repository on Ubuntu.
        ETCD_NAME="controller"
        ETCD_DATA_DIR="/var/lib/etcd"
        ETCD_INITIAL_CLUSTER_STATE="new"
        ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"
        ETCD_INITIAL_CLUSTER="controller=http://10.0.0.11:2380"
        ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"
        ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"
        ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380"
        ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379"
Finalize installation
46                                                                       Chapter 5. Environment
                                                                                               CHAPTER
SIX
The installation of individual OpenStack services is covered in the Project Installation Guides that are
available at the following locations:
    • OpenStack Installation Guides for Yoga
    • OpenStack Installation Guides for Xena
    • OpenStack Installation Guides for Wallaby
    • OpenStack Installation Guides for Victoria
    • OpenStack Installation Guides for Ussuri
    • OpenStack Installation Guides for Train
    • OpenStack Installation Guides for Stein
    • OpenStack Installation Guides for Rocky
    • OpenStack Installation Guides for Queens
    • OpenStack Installation Guides for Pike
At a minimum, you need to install the following services. Install the services in the order specified below:
    • Identity service keystone installation for Yoga
    • Image service glance installation for Yoga
    • Placement service placement installation for Yoga
    • Compute service nova installation for Yoga
    • Networking service neutron installation for Yoga
We advise to also install the following components after you have installed the minimal deployment
services:
    • Dashboard horizon installation for Yoga
    • Block Storage service cinder installation for Yoga
                                                                                                         47
Install Guide
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Xena
     • Image service glance installation for Xena
     • Placement service placement installation for Xena
     • Compute service nova installation for Xena
     • Networking service neutron installation for Xena
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Xena
     • Block Storage service cinder installation for Xena
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Wallaby
     • Image service glance installation for Wallaby
     • Placement service placement installation for Wallaby
     • Compute service nova installation for Wallaby
     • Networking service neutron installation for Wallaby
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Wallaby
     • Block Storage service cinder installation for Wallaby
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Victoria
     • Image service glance installation for Victoria
     • Placement service placement installation for Victoria
     • Compute service nova installation for Victoria
     • Networking service neutron installation for Victoria
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Victoria
At a minimum, you need to install the following services. Install the services in the order specified below:
    • Identity service keystone installation for Ussuri
    • Image service glance installation for Ussuri
    • Placement service placement installation for Ussuri
    • Compute service nova installation for Ussuri
    • Networking service neutron installation for Ussuri
We advise to also install the following components after you have installed the minimal deployment
services:
    • Dashboard horizon installation for Ussuri
    • Block Storage service cinder installation for Ussuri
At a minimum, you need to install the following services. Install the services in the order specified below:
    • Identity service keystone installation for Train
    • Image service glance installation for Train
    • Placement service placement installation for Train
    • Compute service nova installation for Train
    • Networking service neutron installation for Train
We advise to also install the following components after you have installed the minimal deployment
services:
    • Dashboard horizon installation for Train
    • Block Storage service cinder installation for Train
At a minimum, you need to install the following services. Install the services in the order specified below:
    • Identity service keystone installation for Stein
    • Image service glance installation for Stein
    • Placement service placement installation for Stein
    • Compute service nova installation for Stein
    • Networking service neutron installation for Stein
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Stein
     • Block Storage service cinder installation for Stein
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Rocky
     • Image service glance installation for Rocky
     • Compute service nova installation for Rocky
     • Networking service neutron installation for Rocky
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Rocky
     • Block Storage service cinder installation for Rocky
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Queens
     • Image service glance installation for Queens
     • Compute service nova installation for Queens
     • Networking service neutron installation for Queens
We advise to also install the following components after you have installed the minimal deployment
services:
     • Dashboard horizon installation for Queens
     • Block Storage service cinder installation for Queens
At a minimum, you need to install the following services. Install the services in the order specified below:
     • Identity service keystone installation for Pike
     • Image service glance installation for Pike
     • Compute service nova installation for Pike
     • Networking service neutron installation for Pike
We advise to also install the following components after you have installed the minimal deployment
services:
   • Dashboard horizon installation for Pike
   • Block Storage service cinder installation for Pike
SEVEN
LAUNCH AN INSTANCE
This section creates the necessary virtual networks to support launching instances. Networking option 1
includes one provider (external) network with one instance that uses it. Networking option 2 includes one
provider network with one instance that uses it and one self-service (private) network with one instance
that uses it.
The instructions in this section use command-line interface (CLI) tools on the controller node. However,
you can follow the instructions on any host that the tools are installed.
For more information on the CLI tools, see the OpenStackClient documentation for Pike, the OpenStack-
Client documentation for Queens, or the OpenStackClient documentation for Rocky.
To use the dashboard, see the Dashboard User Documentation for Pike, the Dashboard User Documen-
tation for Queens, or the Dashboard User Documentation for Rocky.
Create virtual networks for the networking option that you chose when configuring Neutron. If you chose
option 1, create only the provider network. If you chose option 2, create the provider and self-service
networks.
Before launching an instance, you must create the necessary virtual network infrastructure. For net-
working option 1, an instance uses a provider (external) network that connects to the physical network
infrastructure via layer-2 (bridging/switching). This network includes a DHCP server that provides IP
addresses to instances.
The admin or other privileged user must create this network because it connects directly to the physical
network infrastructure.
Note: The following instructions and diagrams use example IP address ranges. You must adjust them
for your particular environment.
                                                                                                      53
Install Guide
1. On the controller node, source the admin credentials to gain access to admin-only CLI commands:
$ . admin-openrc
     +---------------------------+--------------------------------------+
     | Field                     | Value                                |
     +---------------------------+--------------------------------------+
     | admin_state_up            | UP                                   |
     | availability_zone_hints   |                                      |
     | availability_zones        |                                      |
     | created_at                | 2017-03-14T14:37:39Z                 |
     | description               |                                      |
     | dns_domain                | None                                 |
     | id                        | 54adb94a-4dce-437f-a33b-e7e2e7648173 |
     | ipv4_address_scope        | None                                 |
     | ipv6_address_scope        | None                                 |
     | is_default                | None                                 |
     | mtu                       | 1500                                 |
     | name                      | provider                             |
     | port_security_enabled     | True                                 |
     | project_id                | 4c7f48f1da5b494faaa66713686a7707     |
     | provider:network_type     | flat                                 |
     | provider:physical_network | provider                             |
     | provider:segmentation_id | None                                  |
     | qos_policy_id             | None                                 |
     | revision_number           | 3                                    |
     | router:external           | External                             |
     | segments                  | None                                 |
     | shared                    | True                                 |
     | status                    | ACTIVE                               |
     | subnets                   |                                      |
     | updated_at                | 2017-03-14T14:37:39Z                 |
     +---------------------------+--------------------------------------+
     The --share option allows all projects to use the virtual network.
     The --external option defines the virtual network to be external. If you wish to create an internal
     network, you can use --internal instead. Default value is internal.
     The --provider-physical-network provider and --provider-network-type flat op-
     tions connect the flat virtual network to the flat (native/untagged) physical network on the eth1
     interface on the host using information from the following files:
ml2_conf.ini:
        [ml2_type_flat]
        flat_networks = provider
linuxbridge_agent.ini:
        [linux_bridge]
        physical_interface_mappings = provider:eth1
        Replace PROVIDER_NETWORK_CIDR with the subnet on the provider physical network in CIDR
        notation.
        Replace START_IP_ADDRESS and END_IP_ADDRESS with the first and last IP address of the range
        within the subnet that you want to allocate for instances. This range must not include any existing
        active IP addresses.
        Replace DNS_RESOLVER with the IP address of a DNS resolver. In most cases, you can use one
        from the /etc/resolv.conf file on the host.
        Replace PROVIDER_NETWORK_GATEWAY with the gateway IP address on the provider network, typ-
        ically the .1 IP address.
        Example
        The provider network uses 203.0.113.0/24 with a gateway on 203.0.113.1. A DHCP server assigns
        each instance an IP address from 203.0.113.101 to 203.0.113.250. All instances use 8.8.4.4 as a
        DNS resolver.
If you chose networking option 2, you can also create a self-service (private) network that connects to the
physical network infrastructure via NAT. This network includes a DHCP server that provides IP addresses
to instances. An instance on this network can automatically access external networks such as the Internet.
However, access to an instance on this network from external networks such as the Internet requires a
floating IP address.
The demo or other unprivileged user can create this network because it provides connectivity to instances
within the demo project only.
Warning: You must create the provider network before the self-service network.
Note: The following instructions and diagrams use example IP address ranges. You must adjust them
for your particular environment.
1. On the controller node, source the demo credentials to gain access to user-only CLI commands:
$ . demo-openrc
        Non-privileged users typically cannot supply additional parameters to this command. The service
        automatically chooses parameters using information from the following files:
        ml2_conf.ini:
        [ml2]
        tenant_network_types = vxlan
        [ml2_type_vxlan]
        vni_ranges = 1:1000
        Replace DNS_RESOLVER with the IP address of a DNS resolver. In most cases, you can use one
        from the /etc/resolv.conf file on the host.
        Replace SELFSERVICE_NETWORK_GATEWAY with the gateway you want to use on the self-service
        network, typically the .1 IP address.
        Replace SELFSERVICE_NETWORK_CIDR with the subnet you want to use on the self-service net-
        work. You can use any arbitrary value, although we recommend a network from RFC 1918.
        Example
        The self-service network uses 172.16.1.0/24 with a gateway on 172.16.1.1. A DHCP server assigns
        each instance an IP address from 172.16.1.2 to 172.16.1.254. All instances use 8.8.4.4 as a DNS
        resolver.
Create a router
Self-service networks connect to provider networks using a virtual router that typically performs bidi-
rectional NAT. Each router contains an interface on at least one self-service network and a gateway on a
provider network.
The provider network must include the router:external option to enable self-service routers to use
it for connectivity to external networks such as the Internet. The admin or other privileged user must
include this option during network creation or add it later. In this case, the router:external option
was set by using the --external parameter when creating the provider network.
   1. On the controller node, source the demo credentials to gain access to user-only CLI commands:
$ . demo-openrc
Verify operation
We recommend that you verify operation and fix any issues before proceeding. The following steps use
the IP address ranges from the network and subnet creation examples.
     1. On the controller node, source the admin credentials to gain access to admin-only CLI commands:
$ . admin-openrc
2. List network namespaces. You should see one qrouter namespace and two qdhcp namespaces.
$ ip netns
        qrouter-89dd2083-a160-4d75-ab3a-14239f01ea0b
        qdhcp-7c6f9b37-76b4-463e-98d8-27e5686ed083
        qdhcp-0e62efcd-8cee-46c7-b163-d8df05c3c5ad
3. List ports on the router to determine the gateway IP address on the provider network:
      +--------------------------------------+------+-------------------+-------
       ,→------------------------------------------------------------------------
,→+--------+
      +--------------------------------------+------+-------------------+-------
       ,→------------------------------------------------------------------------
,→+--------+
       ,→   | ACTIVE |
      | d6fe98db-ae01-42b0-a860-37b1661f5950 |       | fa:16:3e:e8:c1:41 | ip_
       ,→address='203.0.113.102', subnet_id='5cc70da8-4ee7-4565-be53-b9c011fca011
       ,→'  | ACTIVE |
      +--------------------------------------+------+-------------------+-------
       ,→------------------------------------------------------------------------
,→+--------+
4. Ping this IP address from the controller node or any host on the physical provider network:
$ ping -c 4 203.0.113.102
The smallest default flavor consumes 512 MB memory per instance. For environments with compute
nodes containing less than 4 GB memory, we recommend creating the m1.nano flavor that only requires
64 MB per instance. Only use this flavor with the CirrOS image for testing purposes.
+----------------------------+---------+
| Field                      | Value   |
+----------------------------+---------+
                                                                                   (continues on next page)
Most cloud images support public key authentication rather than conventional password authentication.
Before launching an instance, you must add a public key to the Compute service.
     1. Source the demo project credentials:
$ . demo-openrc
        $ ssh-keygen -q -N ""
        $ openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey
        +-------------+-------------------------------------------------+
        | Field       | Value                                           |
        +-------------+-------------------------------------------------+
        | fingerprint | ee:3d:2e:97:d4:e2:6a:54:6d:0d:ce:43:39:2c:ba:4d |
        | name        | mykey                                           |
        | user_id     | 58126687cbcc4888bfa9ab73a2256f27                |
        +-------------+-------------------------------------------------+
Note: Alternatively, you can skip the ssh-keygen command and use an existing public key.
        +-------+-------------------------------------------------+
        | Name | Fingerprint                                      |
        +-------+-------------------------------------------------+
        | mykey | ee:3d:2e:97:d4:e2:6a:54:6d:0d:ce:43:39:2c:ba:4d |
        +-------+-------------------------------------------------+
By default, the default security group applies to all instances and includes firewall rules that deny
remote access to instances. For Linux images such as CirrOS, we recommend allowing at least ICMP
(ping) and secure shell (SSH).
    • Add rules to the default security group:
         – Permit ICMP (ping):
           +-------------------+--------------------------------------+
           | Field             | Value                                |
           +-------------------+--------------------------------------+
           | created_at        | 2017-03-30T00:46:43Z                 |
           | description       |                                      |
           | direction         | ingress                              |
           | ether_type        | IPv4                                 |
           | id                | 1946be19-54ab-4056-90fb-4ba606f19e66 |
           | name              | None                                 |
           | port_range_max    | None                                 |
           | port_range_min    | None                                 |
           | project_id        | 3f714c72aed7442681cbfa895f4a68d3     |
           | protocol          | icmp                                 |
           | remote_group_id   | None                                 |
           | remote_ip_prefix | 0.0.0.0/0                             |
           | revision_number   | 1                                    |
           | security_group_id | 89ff5c84-e3d1-46bb-b149-e621689f0696 |
           | updated_at        | 2017-03-30T00:46:43Z                 |
           +-------------------+--------------------------------------+
           +-------------------+--------------------------------------+
           | Field             | Value                                |
           +-------------------+--------------------------------------+
           | created_at        | 2017-03-30T00:43:35Z                 |
           | description       |                                      |
           | direction         | ingress                              |
           | ether_type        | IPv4                                 |
           | id                | 42bc2388-ae1a-4208-919b-10cf0f92bc1c |
           | name              | None                                 |
           | port_range_max    | 22                                   |
           | port_range_min    | 22                                   |
           | project_id        | 3f714c72aed7442681cbfa895f4a68d3     |
           | protocol          | tcp                                  |
           | remote_group_id   | None                                 |
           | remote_ip_prefix | 0.0.0.0/0                             |
                                                                                 (continues on next page)
If you chose networking option 1, you can only launch an instance on the provider network. If you chose
networking option 2, you can launch an instance on the provider network and the self-service network.
To launch an instance, you must at least specify the flavor, image name, network, security group, key,
and instance name.
     1. On the controller node, source the demo credentials to gain access to user-only CLI commands:
$ . demo-openrc
     2. A flavor specifies a virtual resource allocation profile which includes processor, memory, and stor-
        age.
        List available flavors:
        +----+---------+-----+------+-----------+-------+-----------+
        | ID | Name    | RAM | Disk | Ephemeral | VCPUs | Is Public |
        +----+---------+-----+------+-----------+-------+-----------+
        | 0 | m1.nano | 64 |      1 |         0 |     1 | True      |
        +----+---------+-----+------+-----------+-------+-----------+
        +--------------------------------------+--------+--------+
        | ID                                   | Name   | Status |
        +--------------------------------------+--------+--------+
        | 390eb5f7-8d49-41ec-95b7-68c0d5d54b34 | cirros | active |
        +--------------------------------------+--------+--------+
     +--------------------------------------+--------------+-------------------
      ,→-------------------+
     | ID                                   | Name         | Subnets          ␣
      ,→                   |
     +--------------------------------------+--------------+-------------------
      ,→-------------------+
     +--------------------------------------+--------------+-------------------
      ,→-------------------+
     This instance uses the provider provider network. However, you must reference this network
     using the ID instead of the name.
     Note: If you chose option 2, the output should also contain the selfservice self-service net-
     work.
     +--------------------------------------+---------+------------------------
      ,→+----------------------------------+
     | ID                                    | Name   | Description           ␣
      ,→| Project                          |
     +--------------------------------------+---------+------------------------
      ,→+----------------------------------+
     +--------------------------------------+---------+------------------------
      ,→+----------------------------------+
     Note: If you chose option 1 and your environment contains only one network, you can omit the
     --nic option because OpenStack automatically chooses the only network available.
     +-----------------------------+-------------------------------------------
      ,→----+
     | Field                       | Value                                    ␣
      ,→    |
     +-----------------------------+-------------------------------------------
      ,→----+
     | OS-DCF:diskConfig           | MANUAL                                   ␣
      ,→    |
     | OS-EXT-AZ:availability_zone |                                          ␣
      ,→    |
     | OS-EXT-STS:power_state      | NOSTATE                                  ␣
      ,→    |
     | OS-EXT-STS:task_state       | scheduling                               ␣
      ,→    |
     | OS-EXT-STS:vm_state         | building                                 ␣
      ,→    |
     | OS-SRV-USG:launched_at      | None                                     ␣
      ,→    |
     | OS-SRV-USG:terminated_at    | None                                     ␣
      ,→    |
     | accessIPv4                  |                                          ␣
      ,→    |
     | accessIPv6                  |                                          ␣
      ,→    |
     | addresses                   |                                          ␣
      ,→    |
     | adminPass                   | PwkfyQ42K72h                             ␣
      ,→    |
     | config_drive                |                                          ␣
      ,→    |
     | created                     | 2017-03-30T00:59:44Z                     ␣
      ,→    |
     | flavor                      | m1.nano (0)                              ␣
      ,→    |
     | hostId                      |                                          ␣
      ,→    |
     | id                          | 36f3130e-cf1b-42f8-a80b-ebd63968940e     ␣
      ,→    |
     | image                       | cirros (97e06b44-e9ed-4db4-ba67-
      ,→6e9fc5d0a203) |
     | key_name                    | mykey                                    ␣
      ,→    |
     | name                        | provider-instance                        ␣
      ,→    |
     | progress                    | 0                                        ␣
      ,→    |
                                                               (continues on next page)
     +--------------------------------------+-------------------+--------+-----
      ,→-------------------+------------+
     | ID                                     | Name            | Status |␣
      ,→Networks               | Image Name |
     +--------------------------------------+-------------------+--------+-----
      ,→-------------------+------------+
The status changes from BUILD to ACTIVE when the build process successfully completes.
  1. Obtain a Virtual Network Computing (VNC) session URL for your instance and access it from a
     web browser:
     +-------+-----------------------------------------------------------------
      ,→----------------+
     | Field | Value                                                          ␣
      ,→                |
     +-------+-----------------------------------------------------------------
      ,→----------------+
     | type | novnc                                                           ␣
      ,→                |
                                                                              (continues on next page)
        +-------+-----------------------------------------------------------------
         ,→----------------+
        Note: If your web browser runs on a host that cannot resolve the controller host name, you can
        replace controller with the IP address of the management interface on your controller node.
        The CirrOS image includes conventional user name/password authentication and provides these
        credentials at the login prompt. After logging into CirrOS, we recommend that you verify network
        connectivity using ping.
     2. Verify access to the provider physical network gateway:
$ ping -c 4 203.0.113.1
$ ping -c 4 openstack.org
   1. Verify connectivity to the instance from the controller node or any host on the provider physical
      network:
$ ping -c 4 203.0.113.103
   2. Access your instance using SSH from the controller node or any host on the provider physical
      network:
$ ssh cirros@203.0.113.103
If your instance does not launch or seem to work as you expect, see the Troubleshoot Compute docu-
mentation for Pike, the Troubleshoot Compute documentation for Queens, or the Troubleshoot Compute
documentation for Rocky for more information or use one of the many other options to seek assistance.
We want your first installation to work!
Return to Launch an instance.
To launch an instance, you must at least specify the flavor, image name, network, security group, key,
and instance name.
   1. On the controller node, source the demo credentials to gain access to user-only CLI commands:
$ . demo-openrc
   2. A flavor specifies a virtual resource allocation profile which includes processor, memory, and stor-
      age.
      List available flavors:
        +----+---------+-----+------+-----------+-------+-----------+
        | ID | Name    | RAM | Disk | Ephemeral | VCPUs | Is Public |
        +----+---------+-----+------+-----------+-------+-----------+
        | 0 | m1.nano | 64 |      1 |         0 |     1 | True      |
        +----+---------+-----+------+-----------+-------+-----------+
        +--------------------------------------+--------+--------+
        | ID                                   | Name   | Status |
        +--------------------------------------+--------+--------+
        | 390eb5f7-8d49-41ec-95b7-68c0d5d54b34 | cirros | active |
        +--------------------------------------+--------+--------+
        +--------------------------------------+-------------+--------------------
         ,→------------------+
        | ID                                   | Name        | Subnets           ␣
         ,→                  |
        +--------------------------------------+-------------+--------------------
         ,→------------------+
        +--------------------------------------+-------------+--------------------
         ,→------------------+
        This instance uses the selfservice self-service network. However, you must reference this net-
        work using the ID instead of the name.
     5. List available security groups:
        +--------------------------------------+---------+------------------------
         ,→+
        | ID                                   | Name    | Description           ␣
         ,→|
     +--------------------------------------+---------+------------------------
      ,→+
     +--------------------------------------+----------------------------------
      ,→-----+
     | Field                                | Value                           ␣
      ,→     |
     +--------------------------------------+----------------------------------
      ,→-----+
     | OS-DCF:diskConfig                    | MANUAL                          ␣
      ,→     |
     | OS-EXT-AZ:availability_zone          |                                 ␣
      ,→     |
     | OS-EXT-STS:power_state               | 0                               ␣
      ,→     |
     | OS-EXT-STS:task_state                | scheduling                      ␣
      ,→     |
     | OS-EXT-STS:vm_state                  | building                        ␣
      ,→     |
     | OS-SRV-USG:launched_at               | None                            ␣
      ,→     |
     | OS-SRV-USG:terminated_at             | None                            ␣
      ,→     |
     | accessIPv4                           |                                 ␣
      ,→     |
     | accessIPv6                           |                                 ␣
      ,→     |
     | addresses                            |                                 ␣
      ,→     |
     | adminPass                            | 7KTBYHSjEz7E                    ␣
      ,→     |
     | config_drive                         |                                 ␣
      ,→     |
     | created                              | 2016-02-26T14:52:37Z            ␣
      ,→     |
     | flavor                               | m1.nano                         ␣
                                                                          (continues on next page)
        |                                      | 5d54b34)                         ␣
         ,→     |
        | key_name                             | mykey                            ␣
         ,→     |
        | name                                 | selfservice-instance             ␣
         ,→     |
        | os-extended-volumes:volumes_attached | []                               ␣
         ,→     |
        | progress                             | 0                                ␣
         ,→     |
        | project_id                           | ed0b60bf607743088218b0a533d5943f␣
         ,→     |
        | properties                           |                                  ␣
         ,→     |
        | security_groups                      | [{u'name': u'default'}]          ␣
         ,→     |
        | status                               | BUILD                            ␣
         ,→     |
        | updated                              | 2016-02-26T14:52:38Z             ␣
         ,→     |
        | user_id                              | 58126687cbcc4888bfa9ab73a2256f27␣
         ,→     |
        +--------------------------------------+----------------------------------
         ,→-----+
        +--------------------------------------+----------------------+--------+--
         ,→----------------------+
        | ID                                   | Name                 | Status |␣
         ,→Networks               |
        +--------------------------------------+----------------------+--------+--
         ,→----------------------+
        +--------------------------------------+----------------------+--------+--
         ,→----------------------+
The status changes from BUILD to ACTIVE when the build process successfully completes.
  1. Obtain a Virtual Network Computing (VNC) session URL for your instance and access it from a
     web browser:
     +-------+-----------------------------------------------------------------
      ,→----------------+
     | Field | Value                                                           ␣
      ,→                |
     +-------+-----------------------------------------------------------------
      ,→----------------+
     | type | novnc                                                            ␣
      ,→                |
     | url    | http://controller:6080/vnc_auto.html?token=5eeccb47-525c-4918-
      ,→ac2a-3ad1e9f1f493 |
     +-------+-----------------------------------------------------------------
      ,→----------------+
     Note: If your web browser runs on a host that cannot resolve the controller host name, you can
     replace controller with the IP address of the management interface on your controller node.
     The CirrOS image includes conventional user name/password authentication and provides these
     credentials at the login prompt. After logging into CirrOS, we recommend that you verify network
     connectivity using ping.
  2. Verify access to the self-service network gateway:
$ ping -c 4 172.16.1.1
$ ping -c 4 openstack.org
        +---------------------+--------------------------------------+
        | Field               | Value                                |
        +---------------------+--------------------------------------+
        | created_at          | 2017-01-20T17:29:16Z                 |
        | description         |                                      |
        | fixed_ip_address    | None                                 |
        | floating_ip_address | 203.0.113.104                        |
        | floating_network_id | b5b6993c-ddf9-40e7-91d0-86806a42edb8 |
        | headers             |                                      |
        | id                  | 88b4d06a-d794-4406-affd-6ffa2bcf1e2a |
        | port_id             | None                                 |
        | project_id          | ed0b60bf607743088218b0a533d5943f     |
        | revision_number     | 1                                    |
        | router_id           | None                                 |
        | status              | DOWN                                 |
        | updated_at          | 2017-01-20T17:29:16Z                 |
        +---------------------+--------------------------------------+
        +--------------------------------------+----------------------+--------+--
         ,→-------------------------------------+
        | ID                                    | Name                | Status |␣
         ,→Networks                              |
        +--------------------------------------+----------------------+--------+--
         ,→-------------------------------------+
   4. Verify connectivity to the instance via floating IP address from the controller node or any host on
      the provider physical network:
$ ping -c 4 203.0.113.104
   5. Access your instance using SSH from the controller node or any host on the provider physical
      network:
$ ssh cirros@203.0.113.104
If your instance does not launch or seem to work as you expect, see the Troubleshoot Compute docu-
mentation for Pike, the Troubleshoot Compute documentation for Queens, or the Troubleshoot Compute
documentation for Rocky for more information or use one of the many other options to seek assistance.
We want your first installation to work!
Return to Launch an instance.
If your environment includes the Block Storage service, you can create a volume and attach it to an
instance.
Create a volume
1. Source the demo credentials to perform the following steps as a non-administrative project:
$ . demo-openrc
2. Create a 1 GB volume:
        +---------------------+--------------------------------------+
        | Field               | Value                                |
        +---------------------+--------------------------------------+
        | attachments         | []                                   |
        | availability_zone   | nova                                 |
        | bootable            | false                                |
        | consistencygroup_id | None                                 |
        | created_at          | 2016-03-08T14:30:48.391027           |
        | description         | None                                 |
        | encrypted           | False                                |
        | id                  | a1e8be72-a395-4a6f-8e07-856a57c39524 |
        | multiattach         | False                                |
        | name                | volume1                              |
        | properties          |                                      |
        | replication_status | disabled                              |
        | size                | 1                                    |
        | snapshot_id         | None                                 |
        | source_volid        | None                                 |
        | status              | creating                             |
        | type                | None                                 |
        | updated_at          | None                                 |
        | user_id             | 684286a9079845359882afc3aa5011fb     |
        +---------------------+--------------------------------------+
3. After a short time, the volume status should change from creating to available:
        +--------------------------------------+--------------+-----------+------
         ,→+-------------+
        +--------------------------------------+--------------+-----------+------
                                                                                     (continues on next page)
     Replace INSTANCE_NAME with the name of the instance and VOLUME_NAME with the name of the
     volume you want to attach to it.
     Example
     Attach the volume1 volume to the provider-instance instance:
2. List volumes:
     +--------------------------------------+--------------+--------+------+---
      ,→-----------------------------------------+
  3. Access your instance using SSH and use the fdisk command to verify presence of the volume as
     the /dev/vdb block storage device:
$ sudo fdisk -l
Note: You must create a file system on the device and mount it to use the volume.
For more information about how to manage volumes, see the python-openstackclient documentation for
Pike, the python-openstackclient documentation for Queens, or the python-openstackclient documenta-
tion for Rocky.
Return to Launch an instance.
7.7 Orchestration
If your environment includes the Orchestration service, you can create a stack that launches an instance.
For more information, see the Orchestration installation guide for Pike, the Orchestration installation
guide for Queens, or the Orchestration installation guide for Rocky.
If your environment includes the Shared File Systems service, you can create a share and mount it in an
instance.
For more information, see the Shared File Systems installation guide for Pike, the Shared File Systems
installation guide for Queens, or the Shared File Systems installation guide for Rocky.
EIGHT
On some deployments, such as ones where restrictive firewalls are in place, you might need to manually
configure a firewall to permit OpenStack service traffic.
To manually configure a firewall, you must permit traffic through the ports that each OpenStack service
uses. This table lists the default ports that each OpenStack service uses:
                                                                                                   81
Install Guide
To function properly, some OpenStack components depend on other, non-OpenStack services. For ex-
ample, the OpenStack dashboard uses HTTP for non-secure communication. In this case, you must
configure the firewall to allow traffic to and from HTTP.
This table lists the ports that other OpenStack components use:
On some deployments, the default port used by a service may fall within the defined local port range of
a host. To check a hosts local port range:
$ sysctl net.ipv4.ip_local_port_range
If a services default port falls within this range, run the following program to check if the port has already
been assigned to another application:
$ lsof -i :PORT
Configure the service to use a different port if the default port is already being used by another application.
NINE
APPENDIX
The following resources are available to help you run and use OpenStack. The OpenStack community
constantly improves and adds to the main features of OpenStack, but if you have any questions, do not
hesitate to ask. Use the following resources to get OpenStack support and troubleshoot your installations.
9.1.1 Documentation
                                                                                                       83
Install Guide
The OpenStack wiki contains a broad range of topics but some of the information can be difficult to find
or is a few pages deep. Fortunately, the wiki search feature enables you to search by title or content. If
you search for specific information, such as about networking or OpenStack Compute, you can find a
large amount of relevant material. More is being added all the time, so be sure to check back often. You
can find the search box in the upper-right corner of any OpenStack wiki page.
The OpenStack community values your set up and testing efforts and wants your feedback. To log a bug,
you must sign up for a Launchpad account. You can view existing bugs and report bugs in the Launchpad
Bugs area. Use the search feature to determine whether the bug has already been reported or already been
fixed. If it still seems like your bug is unreported, fill out a bug report.
Some tips:
     • Give a clear, concise summary.
     • Provide as much detail as possible in the description. Paste in your command output or stack traces,
       links to screen shots, and any other information which might be useful.
     • Be sure to include the software and package versions that you are using, especially
       if you are using a development branch, such as, "Kilo release" vs git commit
       bc79c3ecc55929bac585d04a03475b72e06a3208.
     • Any deployment-specific information is helpful, such as whether you are using Ubuntu 14.04 or
       are performing a multi-node installation.
The following Launchpad Bugs areas are available:
     • Bugs: OpenStack Block Storage (cinder)
     • Bugs: OpenStack Compute (nova)
     • Bugs: OpenStack Dashboard (horizon)
     • Bugs: OpenStack Identity (keystone)
     • Bugs: OpenStack Image service (glance)
     • Bugs: OpenStack Networking (neutron)
     • Bugs: OpenStack Object Storage (swift)
     • Bugs: Application catalog (murano)
     • Bugs: Bare metal service (ironic)
     • Bugs: Clustering service (senlin)
     • Bugs: Container Infrastructure Management service (magnum)
     • Bugs: Data processing service (sahara)
     • Bugs: Database service (trove)
     • Bugs: DNS service (designate)
     • Bugs: Key Manager Service (barbican)
     • Bugs: Monitoring (monasca)
84                                                                               Chapter 9. Appendix
                                                                                           Install Guide
To provide feedback on documentation, join our IRC channel #openstack-doc on the OFTC IRC net-
work, or report a bug in Launchpad and choose the particular project that the documentation is a part
of.
The OpenStack community lives in the #openstack IRC channel on the OFTC network. You can hang
out, ask questions, or get immediate feedback for urgent and pressing issues. To install an IRC client or
use a browser-based client, go to https://webchat.oftc.net/. You can also use Colloquy (Mac OS X), mIRC
(Windows), or XChat (Linux). When you are in the IRC channel and want to share code or command
output, the generally accepted method is to use a Paste Bin. The OpenStack project has one at Paste.
Just paste your longer amounts of text or logs in the web form and you get a URL that you can paste into
the channel. The OpenStack IRC channel is #openstack on irc.oftc.net. You can find a list of all
OpenStack IRC channels on the IRC page on the wiki.
A great way to get answers and insights is to post your question or problematic scenario to the OpenStack
mailing list. You can learn from and help others who might have similar issues. To subscribe or view
the archives, go to the general OpenStack mailing list. If you are interested in the other mailing lists for
specific projects or development, refer to Mailing Lists.
9.2 Glossary
This glossary offers a list of terms and definitions to define a vocabulary for OpenStack-related concepts.
To add to OpenStack glossary, clone the openstack/openstack-manuals repository and update the source
file doc/common/glossary.rst through the OpenStack contribution process.
9.2.1 0-9
2023.1 Antelope
      The code name for the twenty seventh release of OpenStack. This release is the first release based
      on the new release identification process which is formed after year.release count within the year
      and the name Antelope, a swift and gracious animal, also a type of steam locomotive.
6to4
       A mechanism that allows IPv6 packets to be transmitted over an IPv4 network, providing a strategy
       for migrating to IPv6.
9.2.2 A
absolute limit
     Impassable limits for guest VMs. Settings include total RAM size, maximum number of vCPUs,
     and maximum disk size.
access control list (ACL)
      A list of permissions attached to an object. An ACL specifies which users or system processes have
      access to objects. It also defines which operations can be performed on specified objects. Each
      entry in a typical ACL specifies a subject and an operation. For instance, the ACL entry (Alice,
      delete) for a file gives Alice permission to delete the file.
access key
      Alternative term for an Amazon EC2 access key. See EC2 access key.
account
     The Object Storage context of an account. Do not confuse with a user account from an authen-
     tication service, such as Active Directory, /etc/passwd, OpenLDAP, OpenStack Identity, and so
     on.
account auditor
     Checks for missing replicas and incorrect or corrupted objects in a specified Object Storage account
     by running queries against the back-end SQLite database.
86                                                                              Chapter 9. Appendix
                                                                                         Install Guide
account database
     A SQLite database that contains Object Storage accounts and related metadata and that the accounts
     server accesses.
account reaper
     An Object Storage worker that scans for and deletes account databases and that the account server
     has marked for deletion.
account server
     Lists containers in Object Storage and stores container information in the account database.
account service
     An Object Storage component that provides account services such as list, create, modify, and audit.
     Do not confuse with OpenStack Identity service, OpenLDAP, or similar user-account services.
accounting
     The Compute service provides accounting information through the event notification and system
     usage data facilities.
Active Directory
      Authentication and identity service by Microsoft, based on LDAP. Supported in OpenStack.
active/active configuration
      In a high-availability setup with an active/active configuration, several systems share the load to-
      gether and if one fails, the load is distributed to the remaining systems.
active/passive configuration
      In a high-availability setup with an active/passive configuration, systems are set up to bring addi-
      tional resources online to replace those that have failed.
address pool
     A group of fixed and/or floating IP addresses that are assigned to a project and can be used by or
     assigned to the VM instances in a project.
Address Resolution Protocol (ARP)
     The protocol by which layer-3 IP addresses are resolved into layer-2 link local addresses.
admin API
     A subset of API calls that are accessible to authorized administrators and are generally not acces-
     sible to end users or the public Internet. They can exist as a separate service (keystone) or can be
     a subset of another API (nova).
admin server
     In the context of the Identity service, the worker process that provides access to the admin API.
administrator
     The person responsible for installing, configuring, and managing an OpenStack cloud.
Advanced Message Queuing Protocol (AMQP)
    The open standard messaging protocol used by OpenStack components for intra-service commu-
    nications, provided by RabbitMQ, Qpid, or ZeroMQ.
Advanced RISC Machine (ARM)
    Lower power consumption CPU often found in mobile and embedded devices. Supported by Open-
    Stack.
alert
        The Compute service can send alerts through its notification system, which includes a facility to
        create custom notification drivers. Alerts can be sent to and displayed on the dashboard.
9.2. Glossary                                                                                          87
Install Guide
allocate
      The process of taking a floating IP address from the address pool so it can be associated with a
      fixed IP on a guest VM instance.
Amazon Kernel Image (AKI)
    Both a VM container format and disk format. Supported by Image service.
Amazon Machine Image (AMI)
    Both a VM container format and disk format. Supported by Image service.
Amazon Ramdisk Image (ARI)
    Both a VM container format and disk format. Supported by Image service.
Anvil
        A project that ports the shell script-based project named DevStack to Python.
aodh
        Part of the OpenStack Telemetry service; provides alarming functionality.
Apache
     The Apache Software Foundation supports the Apache community of open-source software
     projects. These projects provide software products for the public good.
Apache License 2.0
     All OpenStack core projects are provided under the terms of the Apache License 2.0 license.
Apache Web Server
     The most common web server software currently used on the Internet.
API endpoint
     The daemon, worker, or service that a client communicates with to access an API. API endpoints
     can provide any number of services, such as authentication, sales data, performance meters, Com-
     pute VM commands, census data, and so on.
API extension
     Custom modules that extend some OpenStack core APIs.
API extension plug-in
     Alternative term for a Networking plug-in or Networking API extension.
API key
     Alternative term for an API token.
API server
     Any node running a daemon or worker that provides an API endpoint.
API token
     Passed to API requests and used by OpenStack to verify that the client is authorized to run the
     requested operation.
API version
     In OpenStack, the API version for a project is part of the URL. For example, example.com/nova/
     v1/foobar.
applet
      A Java program that can be embedded into a web page.
Application Catalog service (murano)
     The project that provides an application catalog service so that users can compose and deploy com-
     posite environments on an application abstraction level while managing the application lifecycle.
88                                                                             Chapter 9. Appendix
                                                                                          Install Guide
9.2. Glossary                                                                                           89
Install Guide
authorization
     The act of verifying that a user, process, or client is authorized to perform an action.
authorization node
     An Object Storage node that provides authorization services.
AuthZ
     The Identity component that provides high-level authorization services.
Auto ACK
     Configuration setting within RabbitMQ that enables or disables message acknowledgment. En-
     abled by default.
auto declare
      A Compute RabbitMQ setting that determines whether a message exchange is automatically cre-
      ated when the program starts.
availability zone
      An Amazon EC2 concept of an isolated area that is used for fault tolerance. Do not confuse with
      an OpenStack Compute zone or cell.
AWS CloudFormation template
    AWS CloudFormation allows Amazon Web Services (AWS) users to create and manage a collec-
    tion of related resources. The Orchestration service supports a CloudFormation-compatible format
    (CFN).
9.2.3 B
back end
     Interactions and processes that are obfuscated from the user, such as Compute volume mount, data
     transmission to an iSCSI target by a daemon, or Object Storage object integrity checks.
back-end catalog
     The storage method used by the Identity service catalog service to store and retrieve information
     about API endpoints that are available to the client. Examples include an SQL database, LDAP
     database, or KVS back end.
back-end store
     The persistent data store used to save and retrieve information for a service, such as lists of Object
     Storage objects, current state of guest VMs, lists of user names, and so on. Also, the method
     that the Image service uses to get and store VM images. Options include Object Storage, locally
     mounted file system, RADOS block devices, VMware datastore, and HTTP.
Backup, Restore, and Disaster Recovery service (freezer)
     The project that provides integrated tooling for backing up, restoring, and recovering file systems,
     instances, or database backups.
bandwidth
    The amount of available data used by communication resources, such as the Internet. Represents
    the amount of data that is used to download things or the amount of data available to download.
barbican
     Code name of the Key Manager service.
bare
       An Image service container format that indicates that no container exists for the VM image.
90                                                                              Chapter 9. Appendix
                                                                                            Install Guide
9.2. Glossary                                                                                             91
Install Guide
9.2.4 C
cache pruner
      A program that keeps the Image service VM image cache at or below its configured maximum
      size.
Cactus
     An OpenStack grouped release of projects that came out in the spring of 2011. It included Compute
     (nova), Object Storage (swift), and the Image service (glance). Cactus is a city in Texas, US and
     is the code name for the third release of OpenStack. When OpenStack releases went from three to
     six months long, the code name of the release changed to match a geography nearest the previous
     summit.
CALL
    One of the RPC primitives used by the OpenStack message queue software. Sends a message and
    waits for a response.
capability
     Defines resources for a cell, including CPU, storage, and networking. Can apply to the specific
     services within a cell or a whole cell.
capacity cache
     A Compute back-end database table that contains the current workload, amount of free RAM, and
     number of VMs running on each host. Used to determine on which host a VM starts.
capacity updater
     A notification driver that monitors VM instances and updates the capacity cache as needed.
92                                                                                 Chapter 9. Appendix
                                                                                              Install Guide
CAST
    One of the RPC primitives used by the OpenStack message queue software. Sends a message and
    does not wait for a response.
catalog
      A list of API endpoints that are available to a user after authentication with the Identity service.
catalog service
      An Identity service that lists API endpoints that are available to a user after authentication with the
      Identity service.
ceilometer
      Part of the OpenStack Telemetry service; gathers and stores metrics from other OpenStack services.
cell
       Provides logical partitioning of Compute resources in a child and parent relationship. Requests are
       passed from parent cells to child cells if the parent cannot provide the requested resource.
cell forwarding
       A Compute option that enables parent cells to pass resource requests to child cells if the parent
       cannot provide the requested resource.
cell manager
      The Compute component that contains a list of the current capabilities of each host within the cell
      and routes requests as appropriate.
CentOS
     A Linux distribution that is compatible with OpenStack.
Ceph
       Massively scalable distributed storage system that consists of an object store, block store, and
       POSIX-compatible distributed file system. Compatible with OpenStack.
CephFS
    The POSIX-compliant file system provided by Ceph.
certificate authority (CA)
       In cryptography, an entity that issues digital certificates. The digital certificate certifies the owner-
       ship of a public key by the named subject of the certificate. This enables others (relying parties) to
       rely upon signatures or assertions made by the private key that corresponds to the certified public
       key. In this model of trust relationships, a CA is a trusted third party for both the subject (owner) of
       the certificate and the party relying upon the certificate. CAs are characteristic of many public key
       infrastructure (PKI) schemes. In OpenStack, a simple certificate authority is provided by Compute
       for cloudpipe VPNs and VM image decryption.
Challenge-Handshake Authentication Protocol (CHAP)
     An iSCSI authentication method supported by Compute.
chance scheduler
     A scheduling method used by Compute that randomly chooses an available host from the pool.
changes since
     A Compute API parameter that allows downloading changes to the requested item since your last
     request, instead of downloading a new, fresh set of data and comparing it against the old data.
Chef
       An operating system configuration management tool supporting OpenStack deployments.
9.2. Glossary                                                                                               93
Install Guide
child cell
      If a requested resource such as CPU time, disk storage, or memory is not available in the parent
      cell, the request is forwarded to its associated child cells. If the child cell can fulfill the request, it
      does. Otherwise, it attempts to pass the request to any of its children.
cinder
      Codename for Block Storage service.
CirrOS
     A minimal Linux distribution designed for use as a test image on clouds such as OpenStack.
Cisco neutron plug-in
      A Networking plug-in for Cisco devices and technologies, including UCS and Nexus.
cloud architect
      A person who plans, designs, and oversees the creation of clouds.
Cloud Auditing Data Federation (CADF)
     Cloud Auditing Data Federation (CADF) is a specification for audit event data. CADF is supported
     by OpenStack Identity.
cloud computing
      A model that enables access to a shared pool of configurable computing resources, such as net-
      works, servers, storage, applications, and services, that can be rapidly provisioned and released
      with minimal management effort or service provider interaction.
cloud computing infrastructure
      The hardware and software components such as servers, storage, and network and virtualization
      software that are needed to support the computing requirements of a cloud computing model.
cloud computing platform software
      The delivery of different services through the Internet. These resources include tools and appli-
      cations like data storage, servers, databases, networking, and software. As long as an electronic
      device has access to the web, it has access to the data and the software programs to run it.
cloud computing service architecture
      Cloud service architecture defines the overall cloud computing services and solutions that are im-
      plemented in and across the boundaries of an enterprise business network. Considers the core
      business requirements and matches them with a possible cloud solution.
cloud controller
      Collection of Compute components that represent the global state of the cloud; talks to services,
      such as Identity authentication, Object Storage, and node/storage workers through a queue.
cloud controller node
      A node that runs network, volume, API, scheduler, and image services. Each service may be broken
      out into separate nodes for scalability or availability.
Cloud Data Management Interface (CDMI)
     SINA standard that defines a RESTful API for managing objects in the cloud, currently unsup-
     ported in OpenStack.
Cloud Infrastructure Management Interface (CIMI)
     An in-progress specification for cloud management. Currently unsupported in OpenStack.
cloud technology
      Clouds are tools of virtual sources orchestrated by management and automation softwares. This
      includes, raw processing power, memory, network, storage of cloud based applications.
94                                                                                   Chapter 9. Appendix
                                                                                         Install Guide
cloud-init
     A package commonly installed in VM images that performs initialization of an instance after boot
     using information that it retrieves from the metadata service, such as the SSH public key and user
     data.
cloudadmin
     One of the default roles in the Compute RBAC system. Grants complete system access.
Cloudbase-Init
     A Windows project providing guest initialization features, similar to cloud-init.
cloudpipe
     A compute service that creates VPNs on a per-project basis.
cloudpipe image
     A pre-made VM image that serves as a cloudpipe server. Essentially, OpenVPN running on Linux.
Clustering service (senlin)
      The project that implements clustering services and libraries for the management of groups of
      homogeneous objects exposed by other OpenStack services.
command filter
    Lists allowed commands within the Compute rootwrap facility.
Command-Line Interface (CLI)
    A text-based client that helps you create scripts to interact with OpenStack clouds.
Common Internet File System (CIFS)
    A file sharing protocol. It is a public or open variation of the original Server Message Block (SMB)
    protocol developed and used by Microsoft. Like the SMB protocol, CIFS runs at a higher level
    and uses the TCP/IP protocol.
Common Libraries (oslo)
    The project that produces a set of python libraries containing code shared by OpenStack projects.
    The APIs provided by these libraries should be high quality, stable, consistent, documented and
    generally applicable.
community project
    A project that is not officially endorsed by the OpenStack Technical Commitee. If the project is
    successful enough, it might be elevated to an incubated project and then to a core project, or it
    might be merged with the main code trunk.
compression
    Reducing the size of files by special encoding, the file can be decompressed again to its original
    content. OpenStack supports compression at the Linux file system level but does not support
    compression for things such as Object Storage objects or Image service VM images.
Compute API (nova API)
    The nova-api daemon provides access to nova services. Can communicate with other APIs, such
    as the Amazon EC2 API.
compute controller
    The Compute component that chooses suitable hosts on which to start VM instances.
compute host
    Physical host dedicated to running compute nodes.
compute node
    A node that runs the nova-compute daemon that manages VM instances that provide a wide range
9.2. Glossary                                                                                        95
Install Guide
96                                                                             Chapter 9. Appendix
                                                                                          Install Guide
continuous delivery
      A software engineering approach in which teams produce software in short cycles, ensuring that the
      software can be reliably released at any time and, when releasing the software, doing so manually.
continuous deployment
      A software release process that uses automated testing to validate if changes to a codebase are
      correct and stable for immediate autonomous deployment to a production environment.
continuous integration
      The practice of merging all developers working copies to a shared mainline several times a day.
controller node
     Alternative term for a cloud controller node.
core API
      Depending on context, the core API is either the OpenStack API or the main API of a specific core
      project, such as Compute, Networking, Image service, and so on.
core service
      An official OpenStack service defined as core by Interop Working Group. Currently, consists of
      Block Storage service (cinder), Compute service (nova), Identity service (keystone), Image service
      (glance), Networking service (neutron), and Object Storage service (swift).
cost
       Under the Compute distributed scheduler, this is calculated by looking at the capabilities of each
       host relative to the flavor of the VM instance being requested.
credentials
     Data that is only known to or accessible by a user and used to verify that the user is who he says
     he is. Credentials are presented to the server during authentication. Examples include a password,
     secret key, digital certificate, and fingerprint.
CRL
       A Certificate Revocation List (CRL) in a PKI model is a list of certificates that have been revoked.
       End entities presenting these certificates should not be trusted.
Cross-Origin Resource Sharing (CORS)
     A mechanism that allows many resources (for example, fonts, JavaScript) on a web page to be re-
     quested from another domain outside the domain from which the resource originated. In particular,
     JavaScripts AJAX calls can use the XMLHttpRequest mechanism.
Crowbar
    An open source community project by SUSE that aims to provide all necessary services to quickly
    deploy and manage clouds.
current workload
     An element of the Compute capacity cache that is calculated based on the number of build, snap-
     shot, migrate, and resize operations currently in progress on a given host.
customer
     Alternative term for project.
customization module
     A user-created Python module that is loaded by horizon to change the look and feel of the dash-
     board.
9.2. Glossary                                                                                           97
Install Guide
9.2.5 D
daemon
    A process that runs in the background and waits for requests. May or may not listen on a TCP or
    UDP port. Do not confuse with a worker.
Dashboard (horizon)
     OpenStack project which provides an extensible, unified, web-based user interface for all Open-
     Stack services.
data encryption
      Both Image service and Compute support encrypted virtual machine (VM) images (but not in-
      stances). In-transit data encryption is supported in OpenStack using technologies such as HTTPS,
      SSL, TLS, and SSH. Object Storage does not support object encryption at the application level but
      may support storage that uses disk encryption.
Data loss prevention (DLP) software
      Software programs used to protect sensitive information and prevent it from leaking outside a
      network boundary through the detection and denying of the data transportation.
Data Processing service (sahara)
     OpenStack project that provides a scalable data-processing stack and associated management in-
     terfaces.
data store
      A database engine supported by the Database service.
database ID
     A unique ID given to each replica of an Object Storage database.
database replicator
     An Object Storage component that copies changes in the account, container, and object databases
     to other nodes.
Database service (trove)
     An integrated project that provides scalable and reliable Cloud Database-as-a-Service functionality
     for both relational and non-relational database engines.
deallocate
      The process of removing the association between a floating IP address and a fixed IP address. Once
      this association is removed, the floating IP returns to the address pool.
Debian
     A Linux distribution that is compatible with OpenStack.
deduplication
     The process of finding duplicate data at the disk block, file, and/or object level to minimize storage
     usecurrently unsupported within OpenStack.
default panel
     The default panel that is displayed when a user accesses the dashboard.
default project
     New users are assigned to this project if no project is specified when a user is created.
default token
     An Identity service token that is not associated with a specific project and is exchanged for a scoped
     token.
98                                                                              Chapter 9. Appendix
                                                                                         Install Guide
delayed delete
      An option within Image service so that an image is deleted after a predefined number of seconds
      instead of immediately.
delivery mode
      Setting for the Compute RabbitMQ message delivery mode; can be set to either transient or per-
      sistent.
denial of service (DoS)
      Denial of service (DoS) is a short form for denial-of-service attack. This is a malicious attempt to
      prevent legitimate users from using a service.
deprecated auth
     An option within Compute that enables administrators to create and manage users through the
     nova-manage command as opposed to using the Identity service.
designate
      Code name for the DNS service.
Desktop-as-a-Service
     A platform that provides a suite of desktop environments that users access to receive a desktop
     experience from any location. This may provide general use, development, or even homogeneous
     testing environments.
developer
      One of the default roles in the Compute RBAC system and the default role assigned to a new user.
device ID
      Maps Object Storage partitions to physical storage devices.
device weight
      Distributes partitions proportionately across Object Storage devices based on the storage capacity
      of each device.
DevStack
     Community project that uses shell scripts to quickly build complete OpenStack development en-
     vironments.
DHCP agent
   OpenStack Networking agent that provides DHCP services for virtual networks.
Diablo
     A grouped release of projects related to OpenStack that came out in the fall of 2011, the fourth
     release of OpenStack. It included Compute (nova 2011.3), Object Storage (swift 1.4.3), and the
     Image service (glance). Diablo is the code name for the fourth release of OpenStack. The design
     summit took place in the Bay Area near Santa Clara, California, US and Diablo is a nearby city.
direct consumer
      An element of the Compute RabbitMQ that comes to life when a RPC call is executed. It connects
      to a direct exchange through a unique exclusive queue, sends the message, and terminates.
direct exchange
      A routing table that is created within the Compute RabbitMQ during RPC calls; one is created for
      each RPC call that is invoked.
direct publisher
      Element of RabbitMQ that provides a response to an incoming MQ message.
9.2. Glossary                                                                                          99
Install Guide
disassociate
      The process of removing the association between a floating IP address and fixed IP and thus re-
      turning the floating IP address to the address pool.
Discretionary Access Control (DAC)
      Governs the ability of subjects to access objects, while enabling users to make policy decisions and
      assign security attributes. The traditional UNIX system of users, groups, and read-write-execute
      permissions is an example of DAC.
disk encryption
      The ability to encrypt data at the file system, disk partition, or whole-disk level. Supported within
      Compute VMs.
disk format
      The underlying format that a disk image for a VM is stored as within the Image service back-end
      store. For example, AMI, ISO, QCOW2, VMDK, and so on.
dispersion
      In Object Storage, tools to test and ensure dispersion of objects and containers to ensure fault
      tolerance.
distributed virtual router (DVR)
      Mechanism for highly available multi-host routing when using OpenStack Networking (neutron).
Django
     A web framework used extensively in horizon.
DNS record
     A record that specifies information about a particular domain and belongs to the domain.
DNS service (designate)
     OpenStack project that provides scalable, on demand, self service access to authoritative DNS
     services, in a technology-agnostic manner.
dnsmasq
    Daemon that provides DNS, DHCP, BOOTP, and TFTP services for virtual networks.
domain
    An Identity API v3 entity. Represents a collection of projects, groups and users that defines ad-
    ministrative boundaries for managing OpenStack Identity entities. On the Internet, separates a
    website from other sites. Often, the domain name has two or more parts that are separated by dots.
    For example, yahoo.com, usa.gov, harvard.edu, or mail.yahoo.com. Also, a domain is an entity or
    container of all DNS-related information containing one or more records.
Domain Name System (DNS)
    A system by which Internet domain name-to-address and address-to-name resolutions are deter-
    mined. DNS helps navigate the Internet by translating the IP address into an address that is easier
    to remember. For example, translating 111.111.111.1 into www.yahoo.com. All domains and their
    components, such as mail servers, utilize DNS to resolve to the appropriate locations. DNS servers
    are usually set up in a master-slave relationship such that failure of the master invokes the slave.
    DNS servers might also be clustered or replicated such that changes made to one DNS server are
    automatically propagated to other active servers. In Compute, the support that enables associating
    DNS entries with floating IP addresses, nodes, or cells so that hostnames are consistent across
    reboots.
download
     The transfer of data, usually in the form of files, from one computer to another.
durable exchange
     The Compute RabbitMQ message exchange that remains active when the server restarts.
durable queue
     A Compute RabbitMQ message queue that remains active when the server restarts.
Dynamic Host Configuration Protocol (DHCP)
    A network protocol that configures devices that are connected to a network so that they can com-
    municate on that network by using the Internet Protocol (IP). The protocol is implemented in a
    client-server model where DHCP clients request configuration data, such as an IP address, a de-
    fault route, and one or more DNS server addresses from a DHCP server. A method to automatically
    configure networking for a host at boot time. Provided by both Networking and Compute.
Dynamic HyperText Markup Language (DHTML)
    Pages that use HTML, JavaScript, and Cascading Style Sheets to enable users to interact with a
    web page or show simple animation.
9.2.6 E
east-west traffic
      Network traffic between servers in the same cloud or data center. See also north-south traffic.
EBS boot volume
     An Amazon EBS storage volume that contains a bootable VM image, currently unsupported in
     OpenStack.
ebtables
     Filtering tool for a Linux bridging firewall, enabling filtering of network traffic passing through a
     Linux bridge. Used in Compute along with arptables, iptables, and ip6tables to ensure isolation of
     network communications.
EC2
      The Amazon commercial compute product, similar to Compute.
EC2 access key
     Used along with an EC2 secret key to access the Compute EC2 API.
EC2 API
     OpenStack supports accessing the Amazon EC2 API through Compute.
EC2 Compatibility API
     A Compute component that enables OpenStack to communicate with Amazon EC2.
EC2 secret key
     Used along with an EC2 access key when communicating with the Compute EC2 API; used to
     digitally sign each request.
edge computing
      Running fewer processes in the cloud and moving those processes to local places.
Elastic Block Storage (EBS)
      The Amazon commercial block storage product.
encapsulation
     The practice of placing one packet type within another for the purposes of abstracting or securing
     data. Examples include GRE, MPLS, or IPsec.
encryption
     OpenStack supports encryption technologies such as HTTPS, SSH, SSL, TLS, digital certificates,
     and data encryption.
endpoint
     See API endpoint.
endpoint registry
     Alternative term for an Identity service catalog.
endpoint template
     A list of URL and port number endpoints that indicate where a service, such as Object Storage,
     Compute, Identity, and so on, can be accessed.
enterprise cloud computing
      A computing environment residing behind a firewall that delivers software, infrastructure and plat-
      form services to an enterprise.
entity
         Any piece of hardware or software that wants to connect to the network services provided by Net-
         working, the network connectivity service. An entity can make use of Networking by implementing
         a VIF.
ephemeral image
     A VM image that does not save changes made to its volumes and reverts them to their original state
     after the instance is terminated.
ephemeral volume
     Volume that does not save the changes made to it and reverts to its original state when the current
     user relinquishes control.
Essex
         A grouped release of projects related to OpenStack that came out in April 2012, the fifth release
         of OpenStack. It included Compute (nova 2012.1), Object Storage (swift 1.4.8), Image (glance),
         Identity (keystone), and Dashboard (horizon). Essex is the code name for the fifth release of Open-
         Stack. The design summit took place in Boston, Massachusetts, US and Essex is a nearby city.
ESXi
         An OpenStack-supported hypervisor.
ETag
         MD5 hash of an object within Object Storage, used to ensure data integrity.
euca2ools
     A collection of command-line tools for administering VMs; most are compatible with OpenStack.
Eucalyptus Kernel Image (EKI)
     Used along with an ERI to create an EMI.
Eucalyptus Machine Image (EMI)
     VM image container format supported by Image service.
Eucalyptus Ramdisk Image (ERI)
     Used along with an EKI to create an EMI.
evacuate
     The process of migrating one or all virtual machine (VM) instances from one host to another,
     compatible with both shared storage live migration and block migration.
exchange
     Alternative term for a RabbitMQ message exchange.
exchange type
     A routing algorithm in the Compute RabbitMQ.
exclusive queue
      Connected to by a direct consumer in RabbitMQCompute, the message can be consumed only by
      the current connection.
extended attributes (xattr)
     File system option that enables storage of additional information beyond owner, group, permis-
     sions, modification time, and so on. The underlying Object Storage file system must support ex-
     tended attributes.
extension
      Alternative term for an API extension or plug-in. In the context of Identity service, this is a call
      that is specific to the implementation, such as adding support for OpenID.
external network
      A network segment typically used for instance Internet access.
extra specs
      Specifies additional requirements when Compute determines where to start a new instance. Ex-
      amples include a minimum amount of network bandwidth or a GPU.
9.2.7 F
FakeLDAP
     An easy method to create a local LDAP directory for testing Identity and Compute. Requires Redis.
fan-out exchange
      Within RabbitMQ and Compute, it is the messaging interface that is used by the scheduler service
      to receive capability messages from the compute, volume, and network nodes.
federated identity
      A method to establish trusts between identity providers and the OpenStack cloud.
Fedora
     A Linux distribution compatible with OpenStack.
Fibre Channel
      Storage protocol similar in concept to TCP/IP; encapsulates SCSI commands and data.
Fibre Channel over Ethernet (FCoE)
      The fibre channel protocol tunneled within Ethernet.
fill-first scheduler
        The Compute scheduling method that attempts to fill a host with VMs rather than starting new
        VMs on a variety of hosts.
filter
         The step in the Compute scheduling process when hosts that cannot run VMs are eliminated and
         not chosen.
firewall
      Used to restrict communications between hosts and/or nodes, implemented in Compute using ipt-
      ables, arptables, ip6tables, and ebtables.
FireWall-as-a-Service (FWaaS)
     A Networking extension that provides perimeter firewall functionality.
fixed IP address
       An IP address that is associated with the same instance each time that instance boots, is generally
       not accessible to end users or the public Internet, and is used for management of the instance.
Flat Manager
      The Compute component that gives IP addresses to authorized nodes and assumes DHCP, DNS,
      and routing configuration and services are provided by something else.
flat mode injection
      A Compute networking method where the OS network configuration information is injected into
      the VM image before the instance starts.
flat network
       Virtual network type that uses neither VLANs nor tunnels to segregate project traffic. Each flat
       network typically requires a separate underlying physical interface defined by bridge mappings.
       However, a flat network can contain multiple subnets.
FlatDHCP Manager
     The Compute component that provides dnsmasq (DHCP, DNS, BOOTP, TFTP) and radvd (routing)
     services.
flavor
         Alternative term for a VM instance type.
flavor ID
      UUID for each Compute or Image service VM flavor or instance type.
floating IP address
       An IP address that a project can associate with a VM so that the instance has the same public
       IP address each time that it boots. You create a pool of floating IP addresses and assign them to
       instances as they are launched to maintain a consistent IP address for maintaining DNS assignment.
Folsom
     A grouped release of projects related to OpenStack that came out in the fall of 2012, the sixth
     release of OpenStack. It includes Compute (nova), Object Storage (swift), Identity (keystone),
     Networking (neutron), Image service (glance), and Volumes or Block Storage (cinder). Folsom is
     the code name for the sixth release of OpenStack. The design summit took place in San Francisco,
     California, US and Folsom is a nearby city.
FormPost
    Object Storage middleware that uploads (posts) an image through a form on a web page.
freezer
      Code name for the Backup, Restore, and Disaster Recovery service.
front end
      The point where a user interacts with a service; can be an API endpoint, the dashboard, or a
      command-line tool.
9.2.8 G
gateway
     An IP address, typically assigned to a router, that passes network traffic between different networks.
generic receive offload (GRO)
     Feature of certain network interface drivers that combines many smaller received packets into a
     large packet before delivery to the kernel IP stack.
generic routing encapsulation (GRE)
     Protocol that encapsulates a wide variety of network layer protocols inside virtual point-to-point
     links.
glance
      Codename for the Image service.
glance API server
      Alternative name for the Image API.
glance registry
      Alternative term for the Image service image registry.
global endpoint template
      The Identity service endpoint template that contains services available to all projects.
GlusterFS
     A file system designed to aggregate NAS hosts, compatible with OpenStack.
gnocchi
     Part of the OpenStack Telemetry service; provides an indexer and time-series database.
golden image
     A method of operating system installation where a finalized disk image is created and then used
     by all nodes without modification.
Governance service (congress)
     The project that provides Governance-as-a-Service across any collection of cloud services in order
     to monitor, enforce, and audit policy over dynamic infrastructure.
Graphic Interchange Format (GIF)
    A type of image file that is commonly used for animated images on web pages.
Graphics Processing Unit (GPU)
    Choosing a host based on the existence of a GPU is currently unsupported in OpenStack.
Green Threads
     The cooperative threading model used by Python; reduces race conditions and only context
     switches when specific library calls are made. Each OpenStack service is its own thread.
Grizzly
     The code name for the seventh release of OpenStack. The design summit took place in San Diego,
     California, US and Grizzly is an element of the state flag of California.
Group
    An Identity v3 API entity. Represents a collection of users that is owned by a specific domain.
guest OS
      An operating system instance running under the control of a hypervisor.
9.2.9 H
Hadoop
    Apache Hadoop is an open source software framework that supports data-intensive distributed
    applications.
Hadoop Distributed File System (HDFS)
    A distributed, highly fault-tolerant file system designed to run on low-cost commodity hardware.
handover
     An object state in Object Storage where a new replica of the object is automatically created due to
     a drive failure.
HAProxy
    Provides a load balancer for TCP and HTTP-based applications that spreads requests across mul-
    tiple servers.
hard reboot
     A type of reboot where a physical or virtual power button is pressed as opposed to a graceful,
     proper shutdown of the operating system.
Havana
     The code name for the eighth release of OpenStack. The design summit took place in Portland,
     Oregon, US and Havana is an unincorporated community in Oregon.
health monitor
      Determines whether back-end members of a VIP pool can process a request. A pool can have
      several health monitors associated with it. When a pool has several monitors associated with it, all
      monitors check each member of the pool. All monitors must declare a member to be healthy for it
      to stay active.
heat
       Codename for the Orchestration service.
Heat Orchestration Template (HOT)
     Heat input in the format native to OpenStack.
high availability (HA)
      A high availability system design approach and associated service implementation ensures that a
      prearranged level of operational performance will be met during a contractual measurement period.
      High availability systems seek to minimize system downtime and data loss.
horizon
      Codename for the Dashboard.
horizon plug-in
      A plug-in for the OpenStack Dashboard (horizon).
host
       A physical computer, not a VM instance (node).
host aggregate
      A method to further subdivide availability zones into hypervisor pools, a collection of common
      hosts.
Host Bus Adapter (HBA)
     Device plugged into a PCI slot, such as a fibre channel or network card.
hybrid cloud
     A hybrid cloud is a composition of two or more clouds (private, community or public) that re-
     main distinct entities but are bound together, offering the benefits of multiple deployment models.
     Hybrid cloud can also mean the ability to connect colocation, managed and/or dedicated services
     with cloud resources.
hybrid cloud computing
     A mix of on-premises, private cloud and third-party, public cloud services with orchestration be-
     tween the two platforms.
Hyper-V
     One of the hypervisors supported by OpenStack.
hyperlink
     Any kind of text that contains a link to some other site, commonly found in documents where
     clicking on a word or words opens up a different website.
Hypertext Transfer Protocol (HTTP)
     An application protocol for distributed, collaborative, hypermedia information systems. It is the
     foundation of data communication for the World Wide Web. Hypertext is structured text that uses
     logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or
     transfer hypertext.
Hypertext Transfer Protocol Secure (HTTPS)
     An encrypted communications protocol for secure communication over a computer network, with
     especially wide deployment on the Internet. Technically, it is not a protocol in and of itself; rather,
     it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the TLS or SSL
     protocol, thus adding the security capabilities of TLS or SSL to standard HTTP communications.
     Most OpenStack API endpoints and many inter-component communications support HTTPS com-
     munication.
hypervisor
     Software that arbitrates and controls VM access to the actual underlying hardware.
hypervisor pool
     A collection of hypervisors grouped together through host aggregates.
9.2.10 I
Icehouse
     The code name for the ninth release of OpenStack. The design summit took place in Hong Kong
     and Ice House is a street in that city.
ID number
     Unique numeric ID associated with each user in Identity, conceptually similar to a Linux or LDAP
     UID.
Identity API
      Alternative term for the Identity service API.
Identity back end
      The source used by Identity service to retrieve user information; an OpenLDAP server, for example.
identity provider
      A directory service, which allows users to login with a user name and password. It is a typical
      source of authentication tokens.
9.2.11 J
Java
       A programming language that is used to create systems that involve more than one computer by
       way of a network.
JavaScript
     A scripting language that is used to build web pages.
JavaScript Object Notation (JSON)
     One of the supported response formats in OpenStack.
jumbo frame
    Feature in modern Ethernet networks that supports frames up to approximately 9000 bytes.
Juno
       The code name for the tenth release of OpenStack. The design summit took place in Atlanta,
       Georgia, US and Juno is an unincorporated community in Georgia.
9.2.12 K
Kerberos
     A network authentication protocol which works on the basis of tickets. Kerberos allows nodes
     communication over a non-secure network, and allows nodes to prove their identity to one another
     in a secure manner.
kernel-based VM (KVM)
     An OpenStack-supported hypervisor. KVM is a full virtualization solution for Linux on x86 hard-
     ware containing virtualization extensions (Intel VT or AMD-V), ARM, IBM Power, and IBM
     zSeries. It consists of a loadable kernel module, that provides the core virtualization infrastructure
     and a processor specific module.
Key Manager service (barbican)
     The project that produces a secret storage and generation system capable of providing key man-
     agement for services wishing to enable encryption features.
keystone
      Codename of the Identity service.
Kickstart
     A tool to automate system configuration and installation on Red Hat, Fedora, and CentOS-based
     Linux distributions.
Kilo
       The code name for the eleventh release of OpenStack. The design summit took place in Paris,
       France. Due to delays in the name selection, the release was known only as K. Because k is the
       unit symbol for kilo and the kilogram reference artifact is stored near Paris in the Pavillon de
       Breteuil in Sèvres, the community chose Kilo as the release name.
9.2.13 L
large object
      An object within Object Storage that is larger than 5ăGB.
Launchpad
     The collaboration site for OpenStack.
Layer-2 (L2) agent
     OpenStack Networking agent that provides layer-2 connectivity for virtual networks.
Layer-2 network
     Term used in the OSI network architecture for the data link layer. The data link layer is responsible
     for media access control, flow control and detecting and possibly correcting errors that may occur
     in the physical layer.
Layer-3 (L3) agent
     OpenStack Networking agent that provides layer-3 (routing) services for virtual networks.
Layer-3 network
     Term used in the OSI network architecture for the network layer. The network layer is responsible
     for packet forwarding including routing from one node to another.
Liberty
     The code name for the twelfth release of OpenStack. The design summit took place in Vancouver,
     Canada and Liberty is the name of a village in the Canadian province of Saskatchewan.
libvirt
       Virtualization API library used by OpenStack to interact with many of its supported hypervisors.
Lightweight Directory Access Protocol (LDAP)
     An application protocol for accessing and maintaining distributed directory information services
     over an IP network.
Linux
     Unix-like computer operating system assembled under the model of free and open-source software
     development and distribution.
Linux bridge
     Software that enables multiple VMs to share a single physical NIC within Compute.
Linux Bridge neutron plug-in
     Enables a Linux bridge to understand a Networking port, interface attachment, and other abstrac-
     tions.
Linux containers (LXC)
     An OpenStack-supported hypervisor.
live migration
      The ability within Compute to move running virtual machine instances from one host to another
      with only a small service interruption during switchover.
load balancer
      A load balancer is a logical device that belongs to a cloud account. It is used to distribute work-
      loads between multiple back-end systems or services, based on the criteria defined as part of its
      configuration.
load balancing
      The process of spreading client requests between two or more nodes to improve performance and
      availability.
Load-Balancer-as-a-Service (LBaaS)
     Enables Networking to distribute incoming requests evenly between designated instances.
Load-balancing service (octavia)
     The project that aims to provide scalable, on demand, self service access to load-balancer services,
     in technology-agnostic manner.
Logical Volume Manager (LVM)
     Provides a method of allocating space on mass-storage devices that is more flexible than conven-
     tional partitioning schemes.
9.2.14 M
magnum
    Code name for the Containers Infrastructure Management service.
management API
    Alternative term for an admin API.
management network
    A network segment used for administration, not accessible to the public Internet.
manager
    Logical groupings of related code, such as the Block Storage volume manager or network manager.
manifest
     Used to track segments of a large object within Object Storage.
manifest object
     A special Object Storage object that contains the manifest for a large object.
manila
     Codename for OpenStack Shared File Systems service.
manila-share
     Responsible for managing Shared File System Service devices, specifically the back-end devices.
maximum transmission unit (MTU)
    Maximum frame or packet size for a particular network medium. Typically 1500 bytes for Ethernet
    networks.
mechanism driver
    A driver for the Modular Layer 2 (ML2) neutron plug-in that provides layer-2 connectivity for
    virtual instances. A single OpenStack installation can use multiple mechanism drivers.
melange
     Project name for OpenStack Network Information Service. To be merged with Networking.
membership
    The association between an Image service VM image and a project. Enables images to be shared
    with specified projects.
membership list
    A list of projects that can access a given VM image within Image service.
memcached
    A distributed memory object caching system that is used by Object Storage for caching.
memory overcommit
    The ability to start new VM instances based on the actual memory usage of a host, as opposed
    to basing the decision on the amount of RAM each running instance thinks it has available. Also
    known as RAM overcommit.
message broker
     The software package used to provide AMQP messaging capabilities within Compute. Default
     package is RabbitMQ.
message bus
     The main virtual communication line used by all AMQP messages for inter-cloud communications
     within Compute.
message queue
     Passes requests from clients to the appropriate workers and returns the output to the client after the
     job completes.
Message service (zaqar)
     The project that provides a messaging service that affords a variety of distributed application pat-
     terns in an efficient, scalable, and highly available manner, and to create and maintain associated
     Python libraries and documentation.
Meta-Data Server (MDS)
     Stores CephFS metadata.
Metadata agent
     OpenStack Networking agent that provides metadata services for instances.
migration
     The process of moving a VM instance from one host to another.
mistral
     Code name for Workflow service.
Mitaka
     The code name for the thirteenth release of OpenStack. The design summit took place in Tokyo,
     Japan. Mitaka is a city in Tokyo.
Modular Layer 2 (ML2) neutron plug-in
    Can concurrently use multiple layer-2 networking technologies, such as 802.1Q and VXLAN, in
    Networking.
monasca
    Codename for OpenStack Monitoring.
Monitor (LBaaS)
     LBaaS feature that provides availability monitoring using the ping command, TCP, and
     HTTP/HTTPS GET.
Monitor (Mon)
     A Ceph component that communicates with external clients, checks data state and consistency, and
     performs quorum functions.
Monitoring (monasca)
     The OpenStack service that provides a multi-project, highly scalable, performant, fault-tolerant
     monitoring-as-a-service solution for metrics, complex event processing and logging. To build
      an extensible platform for advanced monitoring services that can be used by both operators and
      projects to gain operational insight and visibility, ensuring availability and stability.
multi-cloud computing
      The use of multiple cloud computing and storage services in a single network architecture.
multi-cloud SDKs
      SDKs that provide a multi-cloud abstraction layer and include support for OpenStack. These SDKs
      are excellent for writing applications that need to consume more than one type of cloud provider,
      but may expose a more limited set of features.
multi-factor authentication
      Authentication method that uses two or more credentials, such as a password and a private key.
      Currently not supported in Identity.
multi-host
      High-availability mode for legacy (nova) networking. Each compute node handles NAT and DHCP
      and acts as a gateway for all of the VMs on it. A networking failure on one compute node doesnt
      affect VMs on other compute nodes.
multinic
     Facility in Compute that allows each virtual machine instance to have more than one VIF connected
     to it.
murano
    Codename for the Application Catalog service.
9.2.15 N
Nebula
     Released as open source by NASA in 2010 and is the basis for Compute.
netadmin
     One of the default roles in the Compute RBAC system. Enables the user to allocate publicly ac-
     cessible IP addresses to instances and change firewall rules.
NetApp volume driver
     Enables Compute to communicate with NetApp storage devices through the NetApp OnCommand
     Provisioning Manager.
network
     A virtual network that provides connectivity between entities. For example, a collection of virtual
     ports that share network connectivity. In Networking terminology, a network is always a layer-2
     network.
Network Address Translation (NAT)
     Process of modifying IP address information while in transit. Supported by Compute and Net-
     working.
network controller
     A Compute daemon that orchestrates the network configuration of nodes, including IP addresses,
     VLANs, and bridging. Also manages routing for both public and private networks.
Network File System (NFS)
     A method for making file systems available over the network. Supported by OpenStack.
network ID
     Unique ID assigned to each network segment within Networking. Same as network UUID.
network manager
     The Compute component that manages various network components, such as firewall rules, IP
     address allocation, and so on.
network namespace
     Linux kernel feature that provides independent virtual networking instances on a single host with
     separate routing tables and interfaces. Similar to virtual routing and forwarding (VRF) services
     on physical network equipment.
network node
     Any compute node that runs the network worker daemon.
network segment
     Represents a virtual, isolated OSI layer-2 subnet in Networking.
Network Service Header (NSH)
     Provides a mechanism for metadata exchange along the instantiated service path.
Network Time Protocol (NTP)
     Method of keeping a clock for a host or node correct via communication with a trusted, accurate
     time source.
network UUID
     Unique ID for a Networking network segment.
network worker
     The nova-network worker daemon; provides services such as giving an IP address to a booting
     nova instance.
Networking API (Neutron API)
     API used to access OpenStack Networking. Provides an extensible architecture to enable custom
     plug-in creation.
Networking service (neutron)
     The OpenStack project which implements services and associated libraries to provide on-demand,
     scalable, and technology-agnostic network abstraction.
neutron
     Codename for OpenStack Networking service.
neutron API
     An alternative name for Networking API.
neutron manager
     Enables Compute and Networking integration, which enables Networking to perform network
     management for guest VMs.
neutron plug-in
     Interface within Networking that enables organizations to create custom plug-ins for advanced
     features, such as QoS, ACLs, or IDS.
Newton
     The code name for the fourteenth release of OpenStack. The design summit took place in Austin,
     Texas, US. The release is named after Newton House which is located at 1013 E. Ninth St., Austin,
     TX. which is listed on the National Register of Historic Places.
9.2.16 O
object
      A BLOB of data held by Object Storage; can be in any format.
object auditor
      Opens all objects for an object server and verifies the MD5 hash, size, and metadata for each object.
object expiration
      A configurable option within Object Storage to automatically delete objects after a specified
      amount of time has passed or a certain date is reached.
object hash
      Unique ID for an Object Storage object.
       This means that OpenDev itself is run like an open source project, you can join us and help run the
       system. Additionally, all of the services run are Open Source software themselves.
       The OpenStack project is the largest project using OpenDev.
OpenLDAP
    An open source LDAP server. Supported by both Compute and Identity.
OpenStack
    OpenStack is a cloud operating system that controls large pools of compute, storage, and network-
    ing resources throughout a data center, all managed through a dashboard that gives administrators
    control while empowering their users to provision resources through a web interface. OpenStack
    is an open source project licensed under the Apache License 2.0.
OpenStack code name
    Each OpenStack release has a code name. Code names ascend in alphabetical order: Austin, Bexar,
    Cactus, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton,
    Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed.
       At the same time as OpenStack releases run out of alphabet the Technical Committee changed the
       naming process to have release number and a release name as an identification code. The release
       number will be the primary identifier: year.release count within the year and the name will be
       used mostly for marketing purposes. The first such release will be: 2023.1 Antelope.
       Wallaby was the first code name choosen by a new policy: Code names are choosen by the com-
       munity following the alphabet, for details see release name criteria.
       The Victoria name was the last name where code names are cities or counties near where the
       corresponding OpenStack design summit took place. An exception, called the Waldon exception,
       was granted to elements of the state flag that sound especially cool. Code names are chosen by
       popular vote.
openSUSE
     A Linux distribution that is compatible with OpenStack.
operator
     The person responsible for planning and maintaining an OpenStack installation.
optional service
      An official OpenStack service defined as optional by Interop Working Group. Currently, consists
      of Dashboard (horizon), Telemetry service (Telemetry), Orchestration service (heat), Database
      service (trove), Bare Metal service (ironic), and so on.
Orchestration service (heat)
     The OpenStack service which orchestrates composite cloud applications using a declarative tem-
     plate format through an OpenStack-native REST API.
orphan
     In the context of Object Storage, this is a process that is not terminated after an upgrade, restart,
     or reload of the service.
Oslo
       Codename for the Common Libraries project.
9.2.17 P
panko
     Part of the OpenStack Telemetry service; provides event storage.
parent cell
     If a requested resource, such as CPU time, disk storage, or memory, is not available in the parent
     cell, the request is forwarded to associated child cells.
partition
      A unit of storage within Object Storage used to store objects. It exists on top of devices and is
      replicated for fault tolerance.
partition index
      Contains the locations of all Object Storage partitions within the ring.
partition shift value
      Used by Object Storage to determine which partition data should reside on.
path MTU discovery (PMTUD)
     Mechanism in IP networks to detect end-to-end MTU and adjust packet size accordingly.
pause
        A VM state where no changes occur (no changes in memory, network communications stop, etc);
        the VM is frozen but not shut down.
PCI passthrough
     Gives guest VMs exclusive access to a PCI device. Currently supported in OpenStack Havana and
     later releases.
persistent message
      A message that is stored both in memory and on disk. The message is not lost after a failure or
      restart.
persistent volume
      Changes to these types of disk volumes are saved.
personality file
     A file used to customize a Compute instance. It can be used to inject SSH keys or a specific network
     configuration.
Pike
        The code name for the sixteenth release of OpenStack. The OpenStack summit took place in
        Boston, Massachusetts, US. The release is named after the Massachusetts Turnpike, abbreviated
        commonly as the Mass Pike, which is the easternmost stretch of Interstate 90.
Platform-as-a-Service (PaaS)
      Provides to the consumer an operating system and, often, a language runtime and libraries (collec-
      tively, the platform) upon which they can run their own application code, without providing any
      control over the underlying infrastructure. Examples of Platform-as-a-Service providers include
      Cloud Foundry and OpenShift.
plug-in
      Software component providing the actual implementation for Networking APIs, or for Compute
      APIs, depending on the context.
policy service
      Component of Identity that provides a rule-management interface and a rule-based authorization
       engine.
policy-based routing (PBR)
      Provides a mechanism to implement packet forwarding and routing according to the policies de-
      fined by the network administrator.
pool
       A logical set of devices, such as web servers, that you group together to receive and process traf-
       fic. The load balancing function chooses which member of the pool handles the new requests or
       connections received on the VIP address. Each VIP has one pool.
pool member
      An application that runs on the back-end server in a load-balancing system.
port
       A virtual network port within Networking; VIFs / vNICs are connected to a port.
port UUID
      Unique ID for a Networking port.
preseed
      A tool to automate system configuration and installation on Debian-based Linux distributions.
private cloud
      Computing resources used exclusively by one business or organization.
private image
      An Image service VM image that is only available to specified projects.
private IP address
      An IP address used for management and administration, not available to the public Internet.
private network
      The Network Controller provides virtual networks to enable compute servers to interact with each
      other and with the public network. All machines must have a public and private network interface.
      A private network interface can be a flat or VLAN network interface. A flat network interface is
      controlled by the flat_interface with flat managers. A VLAN network interface is controlled by the
      vlan_interface option with VLAN managers.
project
      Projects represent the base unit of ownership in OpenStack, in that all resources in OpenStack
      should be owned by a specific project. In OpenStack Identity, a project must be owned by a specific
      domain.
project ID
      Unique ID assigned to each project by the Identity service.
project VPN
      Alternative term for a cloudpipe.
promiscuous mode
     Causes the network interface to pass all traffic it receives to the host rather than passing only the
     frames addressed to it.
protected property
      Generally, extra properties on an Image service image to which only cloud administrators have
      access. Limits which user roles can perform CRUD operations on that property. The cloud admin-
      istrator can configure any image property as protected.
provider
     An administrator who has access to all hosts and instances.
proxy node
     A node that provides the Object Storage proxy service.
proxy server
     Users of Object Storage interact with the service through the proxy server, which in turn looks up
     the location of the requested data within the ring and returns the results to the user.
public API
      An API endpoint used for both service-to-service communication and end-user interactions.
public cloud
      Data centers available to many users over the Internet.
public image
      An Image service VM image that is available to all projects.
public IP address
      An IP address that is accessible to end-users.
public key authentication
      Authentication method that uses keys rather than passwords.
public network
      The Network Controller provides virtual networks to enable compute servers to interact with each
      other and with the public network. All machines must have a public and private network interface.
      The public network interface is controlled by the public_interface option.
Puppet
     An operating system configuration-management tool supported by OpenStack.
Python
     Programming language used extensively in OpenStack.
9.2.18 Q
        Sydney, Australia. The release is named after the Queens Pound river in the South Coast region of
        New South Wales.
Quick EMUlator (QEMU)
     QEMU is a generic and open source machine emulator and virtualizer. One of the hypervisors
     supported by OpenStack, generally used for development purposes.
quota
        In Compute and Block Storage, the ability to set resource limits on a per-project basis.
9.2.19 R
RabbitMQ
     The default message queue software used by OpenStack.
Rackspace Cloud Files
     Released as open source by Rackspace in 2010; the basis for Object Storage.
RADOS Block Device (RBD)
   Ceph component that enables a Linux block device to be striped over multiple distributed data
   stores.
radvd
     The router advertisement daemon, used by the Compute VLAN manager and FlatDHCP manager
     to provide routing services for VM instances.
rally
        Codename for the Benchmark service.
RAM filter
   The Compute setting that enables or disables RAM overcommitment.
RAM overcommit
   The ability to start new VM instances based on the actual memory usage of a host, as opposed
   to basing the decision on the amount of RAM each running instance thinks it has available. Also
   known as memory overcommit.
rate limit
       Configurable option within Object Storage to limit database writes on a per-account and/or per-
       container basis.
raw
        One of the VM image disk formats supported by Image service; an unstructured disk image.
rebalance
      The process of distributing Object Storage partitions across all drives in the ring; used during initial
      ring creation and after ring reconfiguration.
reboot
     Either a soft or hard reboot of a server. With a soft reboot, the operating system is signaled to
     restart, which enables a graceful shutdown of all processes. A hard reboot is the equivalent of power
     cycling the server. The virtualization platform should ensure that the reboot action has completed
     successfully, even in cases in which the underlying domain/VM is paused or halted/stopped.
rebuild
      Removes all data on the server and replaces it with the specified image. Server ID and IP addresses
      remain the same.
Recon
     An Object Storage component that collects meters.
record
     Belongs to a particular domain and is used to specify information about the domain. There are
     several types of DNS records. Each record type contains particular information used to describe
     the purpose of that record. Examples include mail exchange (MX) records, which specify the mail
     server for a particular domain; and name server (NS) records, which specify the authoritative name
     servers for a domain.
record ID
     A number within a database that is incremented each time a change is made. Used by Object
     Storage when replicating.
Red Hat Enterprise Linux (RHEL)
     A Linux distribution that is compatible with OpenStack.
reference architecture
      A recommended architecture for an OpenStack cloud.
region
      A discrete OpenStack environment with dedicated API endpoints that typically shares only the
      Identity (keystone) with other regions.
registry
      Alternative term for the Image service registry.
registry server
      An Image service that provides VM image metadata information to clients.
Reliable, Autonomic Distributed Object Store
      (RADOS)
      A collection of components that provides object storage within Ceph. Similar to OpenStack Object
      Storage.
Remote Procedure Call (RPC)
    The method used by the Compute RabbitMQ for intra-service communications.
replica
      Provides data redundancy and fault tolerance by creating copies of Object Storage objects, ac-
      counts, and containers so that they are not lost when the underlying storage fails.
replica count
      The number of replicas of the data in an Object Storage ring.
replication
      The process of copying data to a separate physical device for fault tolerance and performance.
replicator
      The Object Storage back-end process that creates and manages object replicas.
request ID
     Unique ID assigned to each request sent to Compute.
rescue image
      A special type of VM image that is booted when an instance is placed into rescue mode. Allows
      an administrator to mount the file systems for an instance to correct the problem.
resize
         Converts an existing server to a different flavor, which scales the server up or down. The original
         server is saved to enable rollback if a problem occurs. All resizes must be tested and explicitly
         confirmed, at which time the original server is removed.
RESTful
    A kind of web service API that uses REST, or Representational State Transfer. REST is the style
    of architecture for hypermedia systems that is used for the World Wide Web.
ring
         An entity that maps Object Storage data to partitions. A separate ring exists for each service, such
         as account, object, and container.
ring builder
      Builds and manages rings within Object Storage, assigns partitions to devices, and pushes the
      configuration to other storage nodes.
Rocky
     The code name for the eightteenth release of OpenStack. The OpenStack summit took place in
     Vancouver, Canada. The release is named after the Rocky Mountains.
role
         A personality that a user assumes to perform a specific set of operations. A role includes a set of
         rights and privileges. A user assuming that role inherits those rights and privileges.
Role Based Access Control (RBAC)
     Provides a predefined list of actions that the user can perform, such as start or stop VMs, reset
     passwords, and so on. Supported in both Identity and Compute and can be configured using the
     dashboard.
role ID
      Alphanumeric ID assigned to each Identity service role.
Root Cause Analysis (RCA) service (Vitrage)
     OpenStack project that aims to organize, analyze and visualize OpenStack alarms and events, yield
     insights regarding the root cause of problems and deduce their existence before they are directly
     detected.
rootwrap
     A feature of Compute that allows the unprivileged nova user to run a specified list of commands
     as the Linux root user.
round-robin scheduler
     Type of Compute scheduler that evenly distributes instances among available hosts.
router
      A physical or virtual network device that passes network traffic between different networks.
routing key
      The Compute direct exchanges, fanout exchanges, and topic exchanges use this key to determine
      how to process a message; processing varies depending on exchange type.
RPC driver
    Modular system that allows the underlying message queue software of Compute to be changed.
    For example, from RabbitMQ to ZeroMQ or Qpid.
rsync
         Used by Object Storage to push object replicas.
RXTX cap
    Absolute limit on the amount of network traffic a Compute VM instance can send and receive.
RXTX quota
    Soft limit on the amount of network traffic a Compute VM instance can send and receive.
9.2.20 S
sahara
     Codename for the Data Processing service.
SAML assertion
   Contains information about a user as provided by the identity provider. It is an indication that a
   user has been authenticated.
Sandbox
     A virtual space in which new or untested software can be run securely.
scheduler manager
     A Compute component that determines where VM instances should start. Uses modular design to
     support a variety of scheduler types.
scoped token
     An Identity service API access token that is associated with a specific project.
scrubber
     Checks for and deletes unused VMs; the component of Image service that implements delayed
     delete.
secret key
      String of text known only by the user; used along with an access key to make requests to the
      Compute API.
secure boot
      Process whereby the system firmware validates the authenticity of the code involved in the boot
      process.
secure shell (SSH)
      Open source tool used to access remote hosts through an encrypted communications channel, SSH
      key injection is supported by Compute.
security group
      A set of network traffic filtering rules that are applied to a Compute instance.
segmented object
     An Object Storage large object that has been broken up into pieces. The re-assembled object is
     called a concatenated object.
self-service
       For IaaS, ability for a regular (non-privileged) account to manage a virtual infrastructure compo-
       nent such as networks without involving an administrator.
SELinux
     Linux kernel security module that provides the mechanism for supporting access control policies.
senlin
      Code name for the Clustering service.
server
      Computer that provides explicit services to the client software running on that system, often man-
      aging a variety of computer operations. A server is a VM instance in the Compute system. Flavor
      and image are requisite elements when creating a server.
server image
      Alternative term for a VM image.
server UUID
      Unique ID assigned to each guest VM instance.
service
      An OpenStack service, such as Compute, Object Storage, or Image service. Provides one or more
      endpoints through which users can access resources and perform operations.
service catalog
      Alternative term for the Identity service catalog.
Service Function Chain (SFC)
      For a given service, SFC is the abstracted view of the required service functions and the order in
      which they are to be applied.
service ID
      Unique ID assigned to each service that is available in the Identity service catalog.
Service Level Agreement (SLA)
      Contractual obligations that ensure the availability of a service.
service project
      Special project that contains all services that are listed in the catalog.
service provider
      A system that provides services to other system entities. In case of federated identity, OpenStack
      Identity is the service provider.
service registration
      An Identity service feature that enables services, such as Compute, to automatically register with
      the catalog.
service token
      An administrator-defined token used by Compute to communicate securely with the Identity ser-
      vice.
session back end
      The method of storage used by horizon to track client sessions, such as local memory, cookies, a
      database, or memcached.
session persistence
      A feature of the load-balancing service. It attempts to force subsequent connections to a service to
      be redirected to the same node as long as it is online.
session storage
      A horizon component that stores and tracks client session information. Implemented through the
      Django sessions framework.
share
        A remote, mountable file system in the context of the Shared File Systems service. You can mount
        a share to, and access a share from, several hosts by several users at a time.
share network
      An entity in the context of the Shared File Systems service that encapsulates interaction with the
      Networking service. If the driver you selected runs in the mode requiring such kind of interaction,
      you need to specify the share network to create a share.
Shared File Systems API
     A Shared File Systems service that provides a stable RESTful API. The service authenticates and
     routes requests throughout the Shared File Systems service. There is python-manilaclient to inter-
     act with the API.
Shared File Systems service (manila)
     The service that provides a set of services for management of shared file systems in a multi-project
     cloud environment, similar to how OpenStack provides block-based storage management through
     the OpenStack Block Storage service project. With the Shared File Systems service, you can create
     a remote file system and mount the file system on your instances. You can also read and write data
     from your instances to and from your file system.
shared IP address
     An IP address that can be assigned to a VM instance within the shared IP group. Public IP addresses
     can be shared across multiple servers for use in various high-availability scenarios. When an IP
     address is shared to another server, the cloud network restrictions are modified to enable each
     server to listen to and respond on that IP address. You can optionally specify that the target server
     network configuration be modified. Shared IP addresses can be used with many standard heartbeat
     facilities, such as keepalive, that monitor for failure and manage IP failover.
shared IP group
     A collection of servers that can share IPs with other members of the group. Any server in a group
     can share one or more public IPs with any other server in the group. With the exception of the first
     server in a shared IP group, servers must be launched into shared IP groups. A server may be a
     member of only one shared IP group.
shared storage
     Block storage that is simultaneously accessible by multiple clients, for example, NFS.
Sheepdog
     Distributed block storage system for QEMU, supported by OpenStack.
Simple Cloud Identity Management (SCIM)
     Specification for managing identity in the cloud, currently unsupported by OpenStack.
Simple Protocol for Independent Computing Environments (SPICE)
     SPICE provides remote desktop access to guest virtual machines. It is an alternative to VNC.
     SPICE is supported by OpenStack.
Single-root I/O Virtualization (SR-IOV)
      A specification that, when implemented by a physical PCIe device, enables it to appear as multiple
      separate PCIe devices. This enables multiple virtualized guests to share direct access to the physi-
      cal device, offering improved performance over an equivalent virtual device. Currently supported
      in OpenStack Havana and later releases.
SmokeStack
    Runs automated tests against the core OpenStack API; written in Rails.
snapshot
     A point-in-time copy of an OpenStack storage volume or image. Use storage volume snapshots to
     back up volumes. Use image snapshots to back up data, or as gold images for additional servers.
soft reboot
       A controlled reboot where a VM instance is properly restarted through operating system com-
       mands.
Software Development Kit (SDK)
     Contains code, examples, and documentation that you use to create applications in the language of
     your choice.
Software Development Lifecycle Automation service (solum)
     OpenStack project that aims to make cloud services easier to consume and integrate with applica-
     tion development process by automating the source-to-image process, and simplifying app-centric
     deployment.
Software-defined networking (SDN)
     Provides an approach for network administrators to manage computer network services through
     abstraction of lower-level functionality.
SolidFire Volume Driver
      The Block Storage driver for the SolidFire iSCSI storage appliance.
solum
     Code name for the Software Development Lifecycle Automation service.
spread-first scheduler
     The Compute VM scheduling algorithm that attempts to start a new VM on the host with the least
     amount of load.
SQLAlchemy
    An open source SQL toolkit for Python, used in OpenStack.
SQLite
     A lightweight SQL database, used as the default persistent storage method in many OpenStack
     services.
stack
        A set of OpenStack resources created and managed by the Orchestration service according to
        a given template (either an AWS CloudFormation template or a Heat Orchestration Template
        (HOT)).
StackTach
     Community project that captures Compute AMQP communications; useful for debugging.
static IP address
       Alternative term for a fixed IP address.
StaticWeb
      WSGI middleware component of Object Storage that serves container data as a static web page.
Stein
        The code name for the nineteenth release of OpenStack. The OpenStack Summit took place in
        Berlin, Germany. The release is named after the street SteinstraSSe in Berlin.
storage back end
      The method that a service uses for persistent storage, such as iSCSI, NFS, or local disk.
storage manager
      A XenAPI component that provides a pluggable interface to support a wide variety of persistent
      storage back ends.
9.2.21 T
tacker
      Code name for the NFV Orchestration service
Telemetry service (telemetry)
     The OpenStack project which collects measurements of the utilization of the physical and virtual
     resources comprising deployed clouds, persists this data for subsequent retrieval and analysis, and
     triggers actions when defined criteria are met.
TempAuth
    An authentication facility within Object Storage that enables Object Storage itself to perform au-
    thentication and authorization. Frequently used in testing and development.
Tempest
    Automated software test suite designed to run against the trunk of the OpenStack core project.
TempURL
    An Object Storage middleware component that enables creation of URLs for temporary object
    access.
tenant
     A group of users; used to isolate access to Compute resources. An alternative term for a project.
Tenant API
     An API that is accessible to projects.
tenant endpoint
     An Identity service API endpoint that is associated with one or more projects.
tenant ID
     An alternative term for project ID.
token
        An alpha-numeric string of text used to access OpenStack APIs and resources.
token services
      An Identity service component that manages and validates tokens after a user or project has been
      authenticated.
tombstone
     Used to mark Object Storage objects that have been deleted; ensures that the object is not updated
     on another node after it has been deleted.
topic publisher
      A process that is created when a RPC call is executed; used to push the message to the topic
      exchange.
Torpedo
     Community project used to run automated tests against the OpenStack API.
Train
        The code name for the twentieth release of OpenStack. The OpenStack Infrastructure Summit took
        place in Denver, Colorado, US.
        Two Project Team Gathering meetings in Denver were held at a hotel next to the train line from
        downtown to the airport. The crossing signals there had some sort of malfunction in the past
        causing them to not stop the cars when a train was coming properly. As a result the trains were
        required to blow their horns when passing through that area. Obviously staying in a hotel, by
        trains that are blowing their horns 24/7 was less than ideal. As a result, many jokes popped up
        about Denver and trains - and thus the release is called train.
transaction ID
      Unique ID assigned to each Object Storage request; used for debugging and tracing.
transient
      Alternative term for non-durable.
transient exchange
      Alternative term for a non-durable exchange.
transient message
      A message that is stored in memory and is lost after the server is restarted.
transient queue
      Alternative term for a non-durable queue.
TripleO
      OpenStack-on-OpenStack program. The code name for the OpenStack Deployment program.
trove
        Codename for OpenStack Database service.
trusted platform module (TPM)
      Specialized microprocessor for incorporating cryptographic keys into devices for authenticating
      and securing a hardware platform.
9.2.22 U
Ubuntu
    A Debian-based Linux distribution.
unscoped token
     Alternative term for an Identity service default token.
updater
     Collective term for a group of Object Storage components that processes queued and failed updates
     for containers and objects.
user
        In OpenStack Identity, entities represent individual API consumers and are owned by a specific
        domain. In OpenStack Compute, a user can be associated with roles, projects, or both.
user data
      A blob of data that the user can specify when they launch an instance. The instance can access this
      data through the metadata service or config drive. Commonly used to pass a shell script that the
      instance runs on boot.
User Mode Linux (UML)
     An OpenStack-supported hypervisor.
Ussuri
     The code name for the twenty first release of OpenStack. The OpenStack Infrastructure Summit
     took place in Shanghai, Peoples Republic of China. The release is named after the Ussuri river.
9.2.23 V
Victoria
      The code name for the twenty second release of OpenStack. The OpenDev + PTG was planned
      to take place in Vancouver, British Columbia, Canada. The release is named after Victoria, the
      capital city of British Columbia.
      The in-person event was cancelled due to COVID-19. The event is being virtualized instead.
VIF UUID
     Unique ID assigned to each Networking VIF.
Virtual Central Processing Unit (vCPU)
     Subdivides physical CPUs. Instances can then use those divisions.
Virtual Disk Image (VDI)
     One of the VM image disk formats supported by Image service.
Virtual Extensible LAN (VXLAN)
     A network virtualization technology that attempts to reduce the scalability problems associated
     with large cloud computing deployments. It uses a VLAN-like encapsulation technique to encap-
     sulate Ethernet frames within UDP packets.
Virtual Hard Disk (VHD)
     One of the VM image disk formats supported by Image service.
virtual IP address (VIP)
      An Internet Protocol (IP) address configured on the load balancer for use by clients connecting to
      a service that is load balanced. Incoming connections are distributed to back-end nodes based on
      the configuration of the load balancer.
virtual machine (VM)
      An operating system instance that runs on top of a hypervisor. Multiple VMs can run at the same
      time on the same physical host.
virtual network
      An L2 network segment within Networking.
Virtual Network Computing (VNC)
     Open source GUI and CLI tools used for remote console access to VMs. Supported by Compute.
Virtual Network InterFace (VIF)
     An interface that is plugged into a port in a Networking network. Typically a virtual network
     interface belonging to a VM.
virtual networking
      A generic term for virtualization of network functions such as switching, routing, load balancing,
      and security using a combination of VMs and overlays on physical network infrastructure.
virtual port
      Attachment point where a virtual interface connects to a virtual network.
virtual private network (VPN)
      Provided by Compute in the form of cloudpipes, specialized instances that are used to create VPNs
      on a per-project basis.
virtual server
      Alternative term for a VM or guest.
volume node
     A Block Storage node that runs the cinder-volume daemon.
volume plug-in
     Provides support for new and specialized types of back-end storage for the Block Storage volume
     manager.
volume worker
     A cinder component that interacts with back-end storage to manage the creation and deletion of
     volumes and the creation of compute volumes, provided by the cinder-volume daemon.
vSphere
     An OpenStack-supported hypervisor.
9.2.24 W
Wallaby
     The code name for the twenty third release of OpenStack. Wallabies are native to Australia, which
     at the start of this naming period was experiencing unprecedented wild fires.
Watcher
     Code name for the Infrastructure Optimization service.
weight
     Used by Object Storage devices to determine which storage devices are suitable for the job. Devices
     are weighted by size.
weighted cost
     The sum of each cost used when deciding where to start a new VM instance in Compute.
weighting
     A Compute process that determines the suitability of the VM instances for a job for a particular
     host. For example, not enough RAM on the host, too many CPUs on the host, and so on.
worker
     A daemon that listens to a queue and carries out tasks in response to messages. For example, the
     cinder-volume worker manages volume creation and deletion on storage arrays.
Workflow service (mistral)
    The OpenStack service that provides a simple YAML-based language to write workflows (tasks
    and transition rules) and a service that allows to upload them, modify, run them at scale and in
    a highly available manner, manage and monitor workflow execution state and state of individual
    tasks.
9.2.25 X
X.509
        X.509 is the most widely used standard for defining digital certificates. It is a data structure that
        contains the subject (entity) identifiable information such as its name along with its public key.
        The certificate can contain a few other attributes as well depending upon the version. The most
        recent and standard version of X.509 is v3.
Xen
        Xen is a hypervisor using a microkernel design, providing services that allow multiple computer
        operating systems to execute on the same computer hardware concurrently.
Xen API
     The Xen administrative API, which is supported by Compute.
Xen Cloud Platform (XCP)
     An OpenStack-supported hypervisor.
Xen Storage Manager Volume Driver
     A Block Storage volume plug-in that enables communication with the Xen Storage Manager API.
Xena
        The code name for the twenty fourth release of OpenStack. The release is named after a fictional
        warrior princess.
XenServer
     An OpenStack-supported hypervisor.
XFS
        High-performance 64-bit file system created by Silicon Graphics. Excels in parallel I/O operations
        and data consistency.
9.2.26 Y
Yoga
        The code name for the twenty fifth release of OpenStack. The release is named after a philosophical
        school with mental and physical practices from India.
9.2.27 Z
zaqar
        Codename for the Message service.
Zed
        The code name for the twenty sixth release of OpenStack. The release is named after the pronun-
        ciation of the letter Z.
ZeroMQ
    Message queue software supported by OpenStack. An alternative to RabbitMQ. Also spelled 0MQ.
Zuul
        Zuul is an open source CI/CD platform specializing in gating changes across multiple systems and
        applications before landing a single patch.
        Zuul is used for OpenStack development to ensure that only tested code gets merged.
137