X-Git-Url: https://gerrit.onap.org/r/gitweb?p=policy%2Fparent.git;a=blobdiff_plain;f=docs%2Fdrools%2Ffeature_pooling.rst;h=ba950a3da8e54583b274b6cad6d18f2e522ca774;hp=f7d3579ddfda3aa5c1c15c65b51837ced29f5685;hb=108dd8ff62cbdfbbe1ba3589afe43582105ea275;hpb=11de40286f2a91edc9755f6ea9e621006452527b

diff --git a/docs/drools/feature_pooling.rst b/docs/drools/feature_pooling.rst
index f7d3579d..ba950a3d 100644
--- a/docs/drools/feature_pooling.rst
+++ b/docs/drools/feature_pooling.rst
@@ -2,13 +2,12 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
+ .. _feature-pool:
+
 ****************
 Feature: Pooling
 ****************
 
-Summary
-^^^^^^^
-
 The Pooling feature provides the ability to load-balance work across a “pool” of active-active Drools-PDP hosts.   This particular implementation uses a DMaaP topic for communication between the hosts within the pool.
 
 The pool is adjusted automatically, with no manual intervention when:
@@ -16,7 +15,7 @@ The pool is adjusted automatically, with no manual intervention when:
     * a host goes offline, whether gracefully or due to a failure in the host or in the network
 
 Assumptions and Limitations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+===========================
     * Session persistence is not required
     * Data may be lost when processing is moved from one host to another
     * The entire pool may shut down if the inter-host DMaaP topic becomes inaccessible
@@ -25,7 +24,7 @@ Assumptions and Limitations
 
 
 Key Points
-^^^^^^^^^^
+==========
     * Requests are received on a common DMaaP topic
         - DMaaP distributes the requests randomly to the hosts
         - The request topic should have at least as many partitions as there are hosts
@@ -38,7 +37,8 @@ Key Points
     * Precludes feature(s): session-persistence, active-standby, state-management
 
 Example Scenario
-^^^^^^^^^^^^^^^^
+================
+
     1. Incoming DMaaP message is received on a topic — all hosts are listening, but only one random host receives the message
     2. Decode message to determine “request ID” key (message-specific operation)
     3. Hash request ID to determine the bucket number
@@ -51,7 +51,8 @@ Example Scenario
     .. image:: poolingPdps.png
 
 Bucket Reassignment
-^^^^^^^^^^^^^^^^^^^
+===================
+
     * When a host goes up or down, buckets are rebalanced
     * Attempts to maintain an even distribution
     * Leaves buckets with their current owner, where possible
@@ -62,7 +63,7 @@ Bucket Reassignment
     .. image:: poolingBuckets.png
 
 Usage
-^^^^^
+=====
 
 For pooling to be enabled, the distributed-locking feature must be also be enabled.