aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPamela Dragosh <pdragosh@research.att.com>2018-05-16 00:34:16 +0000
committerGerrit Code Review <gerrit@onap.org>2018-05-16 00:34:16 +0000
commit52207df5d7419885c7f9c5983d54876eea19e36d (patch)
treecf451cf74b8babcbb0685b30cf37bcbb63a21140
parentd274c95ba876f5bff40118f870c1f93afada57a7 (diff)
parent7cb31ae10ead5a8e87ed90732abe43451535d49f (diff)
Merge "Documentation edits for pooling"
-rw-r--r--docs/platform/feature_pooling.rst8
-rw-r--r--docs/platform/swarch_pdp.rst4
2 files changed, 6 insertions, 6 deletions
diff --git a/docs/platform/feature_pooling.rst b/docs/platform/feature_pooling.rst
index 5ed3de18a..f7d3579dd 100644
--- a/docs/platform/feature_pooling.rst
+++ b/docs/platform/feature_pooling.rst
@@ -27,11 +27,11 @@ 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
+ - DMaaP distributes the requests randomly to the hosts
+ - The request topic should have at least as many partitions as there are hosts
* Uses a single, internal DMaaP topic for all inter-host communication
* Allocates buckets to each host
- * Requests are assigned to buckets based on their respective “request IDs”
+ - Requests are assigned to buckets based on their respective “request IDs”
* No session persistence
* No objects copied between hosts
* Requires feature(s): distributed-locking
@@ -46,7 +46,7 @@ Example Scenario
5. Publish “forward” message to internal DMaaP topic, including remote host, bucket number, DMaaP topic information, and message body
6. Remote host verifies ownership of bucket, and routes the DMaaP message to its own rule engine for processing
- The figure below shows several different hosts in a pool. Each host as a copy of the bucket assignments, which specifies which buckets are assigned to which hosts. Incoming requests are mapped to a bucket, and a bucket is mapped to a host, to which the request is routed. The host table includes an entry for each active host in the pool, to which one or more buckets are mapped.
+ The figure below shows several different hosts in a pool. Each host has a copy of the bucket assignments, which specifies which buckets are assigned to which hosts. Incoming requests are mapped to a bucket, and a bucket is mapped to a host, to which the request is routed. The host table includes an entry for each active host in the pool, to which one or more buckets are mapped.
.. image:: poolingPdps.png
diff --git a/docs/platform/swarch_pdp.rst b/docs/platform/swarch_pdp.rst
index 7783156ac..ca9dee29d 100644
--- a/docs/platform/swarch_pdp.rst
+++ b/docs/platform/swarch_pdp.rst
@@ -57,8 +57,8 @@ The current extensions supported are:
- `Feature Healthcheck <feature_healthcheck.html>`_ (enabled by default)
- `Feature Session Persistence <feature_sesspersist.html>`_ (disabled by default)
- `Feature Active/Standby Management <feature_activestdbymgmt.html>`_ (disabled by default)
-- `Feature Distributed Locking <feature_locking.html>`_ (disabled by default)
-- `Feature Pooling <feature_pooling.html>`_ (disabled by default)
+- `Feature Distributed Locking <feature_locking.html>`_ (enabled in OOM installation by default)
+- `Feature Pooling <feature_pooling.html>`_ (enabled in OOM installation by default)
.. seealso:: Click on the individual feature links for more information