openstack-attic/akanda
Code Issues Proposed changes

More verbiage tinkering.

Browse Source
This commit is contained in:
Ryan Petrello 2015-04-03 12:23:37 -04:00
parent 856a10a680
commit d8ca55b11d
5 changed files with 24 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/source/appliance.rst
View File

@ -1,12 +1,14 @@
.. _appliance:
Virtual Software Router (the Akanda Appliance)
==============================================
The Service VM (the Akanda Appliance)
=====================================
Akanda uses Linux-based software router images (stored in OpenStack Glance)
to provide layer 3 routing and advanced networking services. While it's
possible to build your own custom image, Akanda provides stable image releases
for download at `akanda.io <http://akanda.io>`_.
Akanda uses Linux-based images (stored in OpenStack Glance) to provide layer
3 routing and advanced networking services. Akanda, Inc provides stable image
releases for download at `akanda.io <http://akanda.io>`_, but it's also
possible to build your own custom Service VM image (running additional
services of your own on top of the routing and other default services provided
by Akanda).
.. _appliance_rest:

4
docs/source/architecture.rst
View File

@ -40,7 +40,7 @@ From an architectural perspective, Akanda is composed of a few subprojects:
a replacement for Neutron's various L3-L7 agents by listening for
Neutron AMQP events and coalescing them into software
router API calls (which configure and manage embedded services on the
router VM). Additionally, :py:mod:`akanda-rug` contains a health monitoring
Service VM). Additionally, :py:mod:`akanda-rug` contains a health monitoring
component which monitors health and guarantees uptime for existing
software routers.
@ -73,7 +73,7 @@ transitions, modifying its virtualized router in a variety of ways, such as:
* Booting a virtual machine for the router via the Nova API (if one doesn't
exist).
* Checking for aliveness of the router via the :ref:`REST API
<appliance_rest>` on the router VM.
<appliance_rest>` on the Service VM.
* Pushing configuration updates via the :ref:`REST API
<appliance_rest>` to configure routing
and manage services (such as ``iptables``, ``dnsmasq``, ``bird6``,

4
docs/source/operation.rst
View File

@ -62,7 +62,7 @@ a running :py:mod:`akanda.rug` via AMQP::
and places the tenant back under akanda-rug management.
$ rug-ctl ssh <router-id>
Establishes an ssh connection with a specified router VM.
Establishes an ssh connection with a specified Service VM.
$ rug-ctl workers debug
Causes the rug to print debugging diagnostics about the
@ -77,7 +77,7 @@ analyze the state machine flow of any router and step through its operation
using Python's debugger. This is particularly useful for development purposes
and understanding the nature of the :py:mod:`akanda.rug` state machine, but it's
also useful for debugging problematic routers as an operator; a common pattern
for determining why a router VM won't boot is to place the router in `debug
for determining why a Service VM won't boot is to place the router in `debug
mode`::
$ rug-ctl router debug <router-id>

18
docs/source/rug.rst
View File

@ -23,8 +23,8 @@ several event types:
* ``UPDATE`` - services on a router need to be reconfigured
* ``DELETE`` - a router was deleted
* ``POLL`` - used by the :ref:`health monitor<health>` for checking aliveness
of a router VM
* ``REBUILD`` - a router VM should be destroyed and recreated
of a Service VM
* ``REBUILD`` - a Service VM should be destroyed and recreated
As events are normalized and shuttled onto the :py:mod:`multiprocessing.Queue`,
:py:mod:`akanda.rug.scheduler` shards (by Tenant ID, by default) and
@ -57,32 +57,32 @@ State Machine Flow
The supported states in the state machine are:
:CalcAction: The entry point of the state machine. Depending on the
current status of the router VM (e.g., ``ACTIVE``, ``BUILD``, ``SHUTDOWN``)
current status of the Service VM (e.g., ``ACTIVE``, ``BUILD``, ``SHUTDOWN``)
and the current event, determine the first step in the state machine to
transition to.
:Alive: Check aliveness of the router VM by attempting to communicate with
:Alive: Check aliveness of the Service VM by attempting to communicate with
it via its REST HTTP API.
:CreateVM: Call ``nova boot`` to boot a new router VM. This will attempt
to boot a router VM up to a (configurable) number of times before
:CreateVM: Call ``nova boot`` to boot a new Service VM. This will attempt
to boot a Service VM up to a (configurable) number of times before
placing the router into ``ERROR`` state.
:CheckBoot: Check aliveness (up to a configurable number of seconds) of the
router until the VM is responsive and ready for initial configuration.
:ConfigureVM: Configure the router VM and its services. This is generally
:ConfigureVM: Configure the Service VM and its services. This is generally
the final step in the process of booting and configuring a router. This
step communicates with the Neutron API to generate a comprehensive network
configuration for the router (which is pushed to the router via its REST
API). On success, the state machine yields control back to the worker
thread and that thread handles the next event in its queue (likely for
a different router VM and its state machine).
a different Service VM and its state machine).
:ReplugVM: Attempt to hot-plug/unplug a network from the router via ``nova
interface-attach`` or ``nova-interface-detach``.
:StopVM: Terminate a running router VM. This is generally performed when
:StopVM: Terminate a running Service VM. This is generally performed when
a Neutron router is deleted or via explicit operator tools.
:ClearError: After a (configurable) number of ``nova boot`` failures, Neutron

6
docs/source/worker_diagram.dot
View File

@ -18,9 +18,9 @@ digraph sample_boot {
"Worker 1" -> "Thread N"
}
"Thread 1" -> "Router VM 1";
"Thread 1" -> "Router VM ..." [ label = "Appliance REST API" ];
"Thread 1" -> "Router VM N";
"Thread 1" -> "Service VM 1";
"Thread 1" -> "Service VM ..." [ label = "Appliance REST API" ];
"Thread 1" -> "Service VM N";
"Thread 1" -> "Nova" [ label = "Nova API" ];
"Thread 1" -> "Neutron" [ label = "Neutron API" ];