openstack/octavia
Code Issues Proposed changes

Fix "P2" note references in act/act specs

Browse Source 
Currently we are getting warnings about broken references to "P2"
during docs builds.  This patch corrects those references.

Change-Id: I0d81ead1f67f7681096a4617a01ff5439801cb30
This commit is contained in:
Michael Johnson 2017-02-03 10:04:00 -08:00
parent c3345e4657
commit 196187ced0
2 changed files with 29 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
specs/version0.9/active-active-distributor.rst
View File

@ -37,7 +37,7 @@ and defines new terms to describe new components and features as necessary.
.. _P2:
**Note:** Items marked with [P2]_ refer to lower priority features to be
**Note:** Items marked with [`P2`_] refer to lower priority features to be
designed / implemented only after initial release.
@ -48,7 +48,7 @@ Proposed change
topology.
* The operator should be able to select and configure the Distributor
(e.g., through an Octavia configuration file or [P2]_ through a flavor
(e.g., through an Octavia configuration file or [`P2`_] through a flavor
framework).
* Octavia shall support a pluggable design for the Distributor, allowing
@ -58,7 +58,7 @@ Proposed change
* Octavia shall support different provisioning types for the Distributor;
including VM-based (the default, similar to current Amphorae),
[P2]_ container-based, and [P2]_ external (vendor-specific) hardware.
[`P2`_] container-based, and [`P2`_] external (vendor-specific) hardware.
* The operator shall be able to configure the distribution policies,
including affinity and availability (see below for details).
@ -163,7 +163,7 @@ Affinity of Flows to Amphorae
with similar attributes are always sent to the same Amphora; this may be
desired to achieve better performance (see discussion below).
- [P2]_ The Distributor shall support different modes of client-to-Amphora
- [`P2`_] The Distributor shall support different modes of client-to-Amphora
affinity. The operator should be able to select and configure the desired
affinity level.
@ -297,7 +297,7 @@ Forwarding with OVS and OpenFlow Rules
Amphora is ready it becomes the new *standby* (no changes to OpenFlow
rules).
- [P2]_ Handle concurrent failure of more than a single Amphora
- [`P2`_] Handle concurrent failure of more than a single Amphora
* Handling Distributor failover
@ -336,14 +336,14 @@ https://blueprints.launchpad.net/octavia/+spec/active-active-topology)
requests for the VIP address.
**Notes:**
[P2]_ It is desirable that the Distributor be considered as a router by
[`P2`_] It is desirable that the Distributor be considered as a router by
Neutron (to handle port security, network forwarding without ``arp``
spoofing, etc.). This may require changes to Neutron and may also mean
that Octavia will be a privileged user of Neutron.
Distributor needs to support IPv6 NDP
[P2_] If the Distributor is implemented as a container then hot-plugging
[`P2`_] If the Distributor is implemented as a container then hot-plugging
a port for each VIP might not be possible.
If DVR is used then routing rules must be used to forward external
@ -374,10 +374,11 @@ https://blueprints.launchpad.net/octavia/+spec/active-active-topology)
- Reference implementation shall spawn a new Distributor VM as needed. It
shall monitor its health and handle recovery using heartbeats sent to the
health monitor in a similar fashion to how this is done presently with
Amphorae. [P2]_ Spawn a new Distributor if the number VIPs exceeds a given
limit (to limit the number of Neutron ports attached to one Distributor).
[P2]_ Add configuration options and/or Operator API to allow operator to
request a dedicated Distributor for a VIP (or per tenant).
Amphorae. [`P2`_] Spawn a new Distributor if the number VIPs exceeds a
given limit (to limit the number of Neutron ports attached to one
Distributor). [`P2`_] Add configuration options and/or Operator API to
allow operator to request a dedicated Distributor for a VIP (or per
tenant).
* Define a REST API for Distributor configuration (no SSH API).
See below for details.
@ -486,7 +487,7 @@ Following API calls will be addressed.
requests to Amphorae part of this load balancer configuration. This
consists of an algorithm name and affinity type. In the initial release
of ACTIVE-ACTIVE, the only valid algorithm will be *hash*, and the
affinity type may be ``Source_IP`` or [P2]_ ``Source_IP_AND_port``.
affinity type may be ``Source_IP`` or [`P2`_] ``Source_IP_AND_port``.
2. Pre VIP unplug
@ -568,8 +569,8 @@ Further Discussion
future/alternative design and some will hopefully make their way into, yet
to be written, related blueprints (e.g., auto-scaled topology).
[P2]_ Handling changes in Cluster size (manual or auto-scaled)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[`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

28
specs/version0.9/active-active-topology.rst
View File

@ -33,7 +33,7 @@ and defines new terms to describe new components and features as necessary.
.. _P2:
**Note:** Items marked with [P2]_ refer to lower priority features to be
**Note:** Items marked with [`P2`_] refer to lower priority features to be
designed / implemented only after initial release.
@ -44,7 +44,7 @@ A tenant should be able to start a highly-available, loadbalancer for the
tenant's backend services as follows:
* The operator should be able to configure an active-active topology
through an Octavia configuration file or [P2]_ through a Neutron flavor,
through an Octavia configuration file or [`P2`_] through a Neutron flavor,
which the loadbalancer shall support. Octavia shall support active-active
topologies in addition to the topologies that it currently supports.
@ -58,7 +58,7 @@ tenant's backend services as follows:
including L7 load-balancing, SSL termination, etc.
* The active-active topology shall support various Amphora types and
implementations; including, virtual machines, [P2]_ containers, and
implementations; including, virtual machines, [`P2`_] containers, and
bare-metal servers.
* The operator should be able to configure the high-availability
@ -67,7 +67,7 @@ tenant's backend services as follows:
in the load-balancing Amphora Cluster. If the number of healthy Amphorae
drops under the desired number, Octavia shall automatically and
seamlessly create and configure a new Amphora and add it to the Amphora
Cluster. [P2]_ The operator should be further able to define that the
Cluster. [`P2`_] The operator should be further able to define that the
Amphora Cluster shall be allocated on separate physical resources.
* An Amphora Cluster will collectively act to serve as a single logical
@ -238,7 +238,7 @@ Problem 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
([`P2`_] including peer state synchronization, such as sticky-tables, if
needed) and shall reconfigure the other solution components (e.g.,
Neutron) as needed. The controller shall further manage all Amphora
life-cycle events.
@ -266,7 +266,7 @@ Amphora related changes
the same VIP). Amphorae should continue to have a management IP on the LB
Network so Octavia can configure them. Amphorae should also generally
support hot-plugging interfaces into back-end tenant networks as they do
in the current implementation. [P2]_ Finally, the Amphora configuration
in the current implementation. [`P2`_] Finally, the Amphora configuration
may need to be changed to randomize the member list, in order to prevent
synchronized decisions by all Amphorae in the Amphora Cluster.
@ -294,7 +294,7 @@ Amphora related changes
* Create a flow (or task) for the controller worker for (de-)registration
of Amphorae with Distributor. The Distributor has to be aware of the
current ``ONLINE`` Amphorae, to which it can forward traffic. [P2_] The
current ``ONLINE`` Amphorae, to which it can forward traffic. [`P2`_] The
Distributor can do very basic monitoring of the Amphorae health (primarily
to make sure network connectivity between the Distributor and Amphorae is
working). Monitoring pool member health will remain the purview of the
@ -328,7 +328,7 @@ Amphora Cluster Manager driver for the active-active topology (*new*)
* The ACM shall orchestrate creation and deletion of Amphora instances to
meet the availability requirements. Amphora failover will utilize the
existing health monitor flows, with hooks to notify the ACM when
ACTIVE-ACTIVE topology is used. [P2]_ ACM shall handle graceful amphora
ACTIVE-ACTIVE topology is used. [`P2`_] ACM shall handle graceful amphora
removal via draining (delay actual removal until existing connections are
terminated or some timeout has passed).
@ -359,7 +359,7 @@ Amphora Cluster Manager driver for the active-active topology (*new*)
properties for the specific implementation.
* Add configuration file options to support configuration of an
active-active Amphora Cluster. Add default configuration. [P2]_ Add
active-active Amphora Cluster. Add default configuration. [`P2`_] Add
Operator API.
* Add or update documentation for new components added and new or changed
@ -389,7 +389,7 @@ Network driver changes
``arp`` disabled), and registering the Amphora with the Distributor. The
tenant's front-end and back-end networks must allow attachment of
dynamically created Amphorae by involving the ACM (e.g., when the health
monitor replaces a failed Amphora). ([P2]_ extend the LBaaS API to allow
monitor replaces a failed Amphora). ([`P2`_] extend the LBaaS API to allow
specifying an address range for new Amphorae usage, e.g., a subnet pool).
@ -400,7 +400,7 @@ Amphora health-monitoring support
the ACM; namely, forward Amphora health change events to the ACM, so it
can decide when the Amphora Cluster is considered to be in healthy state.
This should be done in addition to managing the health of each Amphora.
[P2]_ Monitor the Amphorae also on their front-end network (i.e., from
[`P2`_] Monitor the Amphorae also on their front-end network (i.e., from
the Distributor).
@ -426,7 +426,7 @@ Distributor support
- Status
- [P2]_ Macro-level stats
- [`P2`_] Macro-level stats
* Spawn Distributors (if using on demand Distributor compute nodes) and/or
attach to existing ones as needed. Manage health and life-cycle of the
@ -437,7 +437,7 @@ Distributor support
* Add Distributor driver and flows to (re-)configure the Distributor on
creation/destruction of a new loadbalancer (add/remove loadbalancer VIP)
and [P2]_ configure the distribution algorithm for the loadbalancer's
and [`P2`_] configure the distribution algorithm for the loadbalancer's
Amphora Cluster.
* Add flows to Octavia to (re-)configure the Distributor on adding/removing
@ -532,7 +532,7 @@ REST API impact
* Amphora REST API -- support configuration of disabling ``arp`` on VIP.
* [P2]_ LBaaS API -- support configuration of desired availability, perhaps
* [`P2`_] LBaaS API -- support configuration of desired availability, perhaps
by selecting a flavor (e.g., gold is a minimum of 4 Amphorae, platinum is
a minimum of 10 Amphora).