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
parent
60339db638
commit
dad4504f9c
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue