..
      Copyright (c) 2016 IBM

      Licensed under the Apache License, Version 2.0 (the "License"); you may
      not use this file except in compliance with the License. You may obtain
      a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
      License for the specific language governing permissions and limitations
      under the License.

===================
Introducing Octavia
===================
Welcome to Octavia!

Octavia is an open source, operator-scale load balancing solution designed to
work with OpenStack.

Octavia was borne out of the Neutron LBaaS project.  Its conception influenced
the transformation of the Neutron LBaaS project, as Neutron LBaaS moved from
version 1 to version 2. Starting with the Liberty release of OpenStack, Octavia
has become the reference implementation for Neutron LBaaS version 2.

Octavia accomplishes its delivery of load balancing services by managing a
fleet of virtual machines, containers, or bare metal servers—collectively known
as *amphorae*\— which it spins up on demand. This on-demand, horizontal scaling
feature differentiates Octavia from other load balancing solutions, thereby
making Octavia truly suited "for the cloud."

Where Octavia fits into the OpenStack ecosystem
-----------------------------------------------
Load balancing is essential for enabling simple or automatic delivery scaling
and availability. In turn, application delivery scaling and availability must
be considered vital features of any cloud. Together, these facts imply that
load balancing is a vital feature of any cloud.

Therefore, we consider Octavia to be as essential as Nova, Neutron, Glance or
any other "core" project that enables the essential features of a modern
OpenStack cloud.

In accomplishing its role, Octavia makes use of other OpenStack projects:

* **Nova** - For managing amphora lifecycle and spinning up compute resources
  on demand.
* **Neutron** - For network connectivity between amphorae, tenant environments,
  and external networks.
* **Barbican** - For managing TLS certificates and credentials, when TLS
  session termination is configured on the amphorae.
* **Keystone** - For authentication against the Octavia API, and for Octavia to
  authenticate with other OpenStack projects.
* **Glance** - For storing the amphora virtual machine image.
* **Oslo** - For communication between Octavia controller components, making
  Octavia work within the standard OpenStack framework and review system, and
  project code structure.
* **Taskflow** - Is technically part of Oslo; however, Octavia makes
  extensive use of this job flow system when orchestrating back-end service
  configuration and management.

Octavia is designed to interact with the components listed previously. In each
case, we’ve taken care to define this interaction through a driver interface.
That way, external components can be swapped out with functionally-equivalent
replacements— without having to restructure major components of Octavia. For
example, if you use an SDN solution other than Neutron in your environment, it
should be possible for you to write an Octavia networking driver for your SDN
environment, which can be a drop-in replacement for the standard Neutron
networking driver in Octavia.

It is important for you to know that Octavia is not necessarily designed as a
complete replacement for the Neutron LBaaS project. That is to say, Octavia is
designed to "plug in" to Neutron LBaaS in the same way that any proprietary
vendor solution would: through a Neutron LBaaS version 2 driver interface.  You
could think of Octavia as an "open source vendor" for Neutron LBaaS, rather
than as a substitute for Neutron LBaaS. For this reason, we recommend that
tenants configure load balancing services with Octavia through the Neutron
LBaaS version 2 CLI and API.

Soon, Octavia will supplant Neutron LBaaS as the load balancing solution for
OpenStack.  At that time, third-party vendor drivers that presently "plug in"
to Neutron LBaaS will plug in to Octavia instead. For end-users, this
transition should be relatively seamless, because Octavia supports the Neutron
LBaaS v2 API and it has a similar CLI interface.


Octavia terminology
-------------------
Before you proceed further in this introduction, please note:

Experience shows that—within the subsegment of the IT industry that creates,
deploys, and uses load balancing devices or services— terminology is often used
inconsistently. To reduce confusion, the Octavia team has created a glossary of
terms as they are defined and used within the context of the Octavia project
and Neutron LBaaS version 2. This glossary is available here: :doc:`glossary`

If you are familiar with Neutron LBaaS version 1 terms and usage, it is
especially important for you to understand how the meanings of the terms “VIP,"
"load balancer," and "load balancing," have changed in Neutron LBaaS version 2.

Our use of these terms should remain consistent with the :doc:`glossary`
throughout Octavia's documentation, in discussions held by Octavia team members
on public mailing lists, in IRC channels, and at conferences. To avoid
misunderstandings, it's a good idea to familiarize yourself with these glossary
definitions.


A 10,000-foot overview of Octavia components
--------------------------------------------
.. image:: octavia-component-overview.svg
   :width: 660px
   :alt: Octavia Component Overview

Octavia version 0.9 consists of the following major components:

* **amphorae** - Amphorae are the individual virtual machines, containers, or
  bare metal servers that accomplish the delivery of load balancing services to
  tenant application environments. In Octavia version 0.8, the reference
  implementation of the amphorae image is an Ubuntu virtual machine running
  HAProxy.

* **controller** - The Controller is  the "brains" of Octavia. It consists of
  four sub-components, which are individual daemons. They can be run on
  separate back-end infrastructure if desired:

  * **API Controller** - As the name implies, this subcomponent runs Octavia's
    API. It takes API requests, performs simple sanitizing on them, and ships
    them off to the controller worker over the Oslo messaging bus.

  * **Controller Worker** - This subcomponent takes sanitized API commands from
    the API controller and performs the actions necessary to fulfill the API
    request.

  * **Health Manager** - This subcomponent monitors individual amphorae to
    ensure they are up and running, and otherwise healthy. It also handles
    failover events if amphorae fail unexpectedly.

  * **Housekeeping Manager** - This subcomponent cleans up stale (deleted)
    database records, manages the spares pool, and manages amphora certificate
    rotation.

* **network** - Octavia cannot accomplish what it does without manipulating
  the network environment. Amphorae are spun up with a network interface on the
  "load balancer network," and they may also plug directly into tenant networks
  to reach back-end pool members, depending on how any given load balancing
  service is deployed by the tenant.

For a more complete description of Octavia's components, please see the
:doc:`../design/version0.5/component-design` document within this documentation
repository.
