diff --git a/specs/version0.9/active-active-distributor.rst b/specs/version0.9/active-active-distributor.rst index c1016b8fa3..ff4739f598 100644 --- a/specs/version0.9/active-active-distributor.rst +++ b/specs/version0.9/active-active-distributor.rst @@ -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 diff --git a/specs/version0.9/active-active-topology.rst b/specs/version0.9/active-active-topology.rst index d8f0f752e5..fd318ef5e6 100644 --- a/specs/version0.9/active-active-topology.rst +++ b/specs/version0.9/active-active-topology.rst @@ -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).