Fix active-active specs tox test

The recently-merged active-active specifications did not pass the
specs tox test. This commit makes minor adjustments to the formatting
and sectioning of these documents so that they now pass the tox test.

Change-Id: Ic8319c6940cb7ffcb185e7c35c4ec536ad19107f
Closes-Bug: #1620914
This commit is contained in:
Stephen Balukoff 2016-09-08 13:15:08 -07:00
parent 60339db638
commit dad4504f9c
2 changed files with 65 additions and 59 deletions

View File

@ -4,17 +4,19 @@
http://creativecommons.org/licenses/by/3.0/legalcode
.. attention::
Please review the active-active topology blueprint first ("Active-Active,
N+1 Amphorae Setup",
https://review.openstack.org/#/c/234639/7/specs/version1/active-active-topology.rst).
=================================================
Distributor for Active-Active, N+1 Amphorae Setup
=================================================
.. attention::
Please review the active-active topology blueprint first (
:doc:`active-active-topology` )
https://blueprints.launchpad.net/octavia/+spec/active-active-topology
Problem description
===================
This blueprint describes how Octavia implements a *Distributor* to support the
*active-active* loadbalancer (LB) solution, as described in the blueprint
linked above. It presents the high-level Distributor design and suggests
@ -38,8 +40,9 @@ and defines new terms to describe new components and features as necessary.
**Note:** Items marked with [P2]_ refer to lower priority features to be
designed / implemented only after initial release.
Problem description
===================
Proposed change
===============
* Octavia shall implement a Distributor to support the active-active
topology.
@ -60,11 +63,12 @@ Problem description
* The operator shall be able to configure the distribution policies,
including affinity and availability (see below for details).
Architecture
============
------------
High-level Topology Description
-------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* The following diagram illustrates the Distributor's role in an active-active
topology:
@ -150,7 +154,7 @@ High-level Topology Description
to the GW router (that is, it does not pass through the Distributor).
Affinity of Flows to Amphorae
-----------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Affinity is required to make sure related packets are forwarded to the
same Amphora. At minimum, since TCP connections are terminated at the
@ -225,7 +229,7 @@ Affinity of Flows to Amphorae
abstraction will be used to allow other implementations at a later time.
Forwarding with OVS and OpenFlow Rules
--------------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* The reference implementation of the Distributor shall use OVS for
forwarding and configure the Distributor through OpenFlow rules.
@ -308,8 +312,8 @@ Forwarding with OVS and OpenFlow Rules
return the complete list of Amphorae MAC addresses with positional
information each time an Amphora is registered or unregistered.
Proposed change
===============
Specific proposed changes
-------------------------
**Note:** These are changes on top of the changes described in the
"Active-Active, N+1 Amphorae Setup" blueprint, (see
@ -436,7 +440,7 @@ which Amphorae are registered with which Distributors and in which order:
* position ``(sa.Integer, nullable=True)``
Order in which Amphorae are registered with the Distributor.
REST API Impact
REST API impact
---------------
Distributor will be running its own rest API server. This API will be secured
using two-way SSL authentication, and use certificate rotation in the same
@ -555,31 +559,8 @@ Other deployer impact
Developer impact
----------------
Implementation
==============
Assignee(s)
-----------
Work Items
----------
Dependencies
============
Testing
=======
* Unit tests with tox.
* Function tests with tox.
Documentation Impact
====================
Further Discussion
==================
------------------
.. Note::
This section captures some background, ideas, concerns, and remarks that
@ -588,7 +569,7 @@ Further Discussion
to be written, related blueprints (e.g., auto-scaled topology).
[P2]_ Handling changes in Cluster size (manual or auto-scaled)
----------------------------------------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- The Distributor shall support different mechanism for preserving affinity
of flows to Amphorae following a *change in the size* of the Amphorae
@ -722,7 +703,7 @@ Further Discussion
sense for Octavia as well.
Forwarding Data-path Implementation Alternatives
------------------------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The current design uses L2 forwarding based only on L3 parameters and uses
Direct Return routing (one-legged). The rational behind this approach is
@ -732,7 +713,7 @@ serve all traffic even for very large workloads. Other approaches are
possible.
2-legged Router
^^^^^^^^^^^^^^^
_______________
- Distributor acts as router, being in-path on both directions.
@ -742,12 +723,12 @@ possible.
- No need to use MAC forwarding -- use routing rules
LVS
^^^
___
Use LVS for Distributor.
DNS
^^^
___
Use DNS for the Distributor.
@ -760,7 +741,7 @@ Use DNS for the Distributor.
- Need a different public IP for each Amphora (no VIP)
Pure SDN
^^^^^^^^
________
- Implement the OpenFlow rules directly in the network, without a
Distributor instance.
@ -771,7 +752,7 @@ Pure SDN
network and SDN controller are shared resources)
Distributor Sharing
-------------------
^^^^^^^^^^^^^^^^^^^
- The initial implementation of the Distributor will not be shared between
tenants until tests can be written to verify the security of this solution.
@ -787,7 +768,7 @@ Distributor Sharing
bottleneck.
Distributor High-Availability
-----------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- The Distributor should be highly-available (as this is one of the
motivations for the active-active topology). Once the initial active-active
@ -818,6 +799,31 @@ Distributor High-Availability
will be explored and decided when an HA Distributor specification is
written and approved.
Implementation
==============
Assignee(s)
-----------
Work Items
----------
Dependencies
============
Testing
=======
* Unit tests with tox.
* Function tests with tox.
Documentation Impact
====================
References
==========
@ -826,5 +832,5 @@ References
.. [3] https://blueprints.launchpad.net/octavia/+spec/amphora-driver-interface
.. [4] https://blueprints.launchpad.net/octavia/+spec/controller
.. [5] https://blueprints.launchpad.net/octavia/+spec/operator-api
.. [6] doc/main/api/haproxy-amphora-api.rst
.. [6] :doc:`../../api/haproxy-amphora-api`
.. [7] https://blueprints.launchpad.net/octavia/+spec/active-active-topology

View File

@ -11,6 +11,9 @@ Active-Active, N+1 Amphorae Setup
https://blueprints.launchpad.net/octavia/+spec/active-active-topology
Problem description
===================
This blueprint describes how Octavia implements an *active-active*
loadbalancer (LB) solution that is highly-available through redundant
Amphorae. It presents the high-level service topology and suggests
@ -34,8 +37,8 @@ and defines new terms to describe new components and features as necessary.
designed / implemented only after initial release.
Problem description
===================
Proposed change
===============
A tenant should be able to start a highly-available, loadbalancer for the
tenant's backend services as follows:
@ -232,7 +235,7 @@ Problem Details
to its support for different Amphora types. The operator should be able
to configure different types of algorithms for the Distributor. All
algorithms should provide flow-affinity to allow TLS termination at the
amphora. See Distributor spec. for details.
amphora. See :doc:`active-active-distributor` for details.
* Octavia controller shall seamlessly configure any newly created Amphora
([P2]_ including peer state synchronization, such as sticky-tables, if
@ -247,10 +250,6 @@ Problem Details
synchronize state information.
Proposed change
===============
Required changes
----------------
@ -491,7 +490,7 @@ Data model impact
- new value: ``IN_CLUSTER``
* Distributor table (*new*): Distributor information, similar to Amphora.
See Distributor spec.
See :doc:`active-active-distributor`
* Cluster table (*new*): an extension to loadbalancer (i.e., one-to-one
mapping to load-balancer)
@ -524,11 +523,12 @@ Data model impact
- `cluster_type`: type of Amphora Cluster implementation
REST API Impact
REST API impact
---------------
* Distributor REST API -- This is a new internal API that will be secured
via two-way SSL certificate authentication. See Distributor spec.
via two-way SSL certificate authentication. See
:doc:`active-active-distributor`
* Amphora REST API -- support configuration of disabling ``arp`` on VIP.
@ -548,7 +548,7 @@ REST API Impact
Security impact
---------------
* See the Distributor spec. for Distributor related security impact.
* See :doc:`active-active-distributor` for Distributor related security impact.
Notifications impact
@ -631,5 +631,5 @@ References
.. [3] https://blueprints.launchpad.net/octavia/+spec/amphora-driver-interface
.. [4] https://blueprints.launchpad.net/octavia/+spec/controller
.. [5] https://blueprints.launchpad.net/octavia/+spec/operator-api
.. [6] doc/main/api/haproxy-amphora-api.rst
.. [6] :doc:`../../api/haproxy-amphora-api`
.. [7] https://blueprints.launchpad.net/octavia/+spec/active-active-topology