aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--docs/development/actors/sdnr/sdnr.rst186
-rw-r--r--docs/development/devtools/distribution-s3p.rst60
-rw-r--r--docs/development/devtools/images/distribution-performance-api-report.pngbin0 -> 76255 bytes
-rw-r--r--docs/development/devtools/images/distribution-performance-summary-report.pngbin0 -> 98261 bytes
4 files changed, 242 insertions, 4 deletions
diff --git a/docs/development/actors/sdnr/sdnr.rst b/docs/development/actors/sdnr/sdnr.rst
index 2b49d24a..13d91940 100644
--- a/docs/development/actors/sdnr/sdnr.rst
+++ b/docs/development/actors/sdnr/sdnr.rst
@@ -2,14 +2,192 @@
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-#################
+.. _sdnr-label:
+
+##########
SDNR Actor
-#################
+##########
.. contents::
:depth: 3
Overview of SDNR Actor
-#############################
+######################
+ONAP Policy Framework enables SDNR as one of the supported actors. SDNR uses two
+DMaaP topics, one to which requests are published, and another from which responses
+are received. SDNR may generate more than one response for a particular request,
+the first response simply indicating that the request was accepted, while the second
+response indicates completion of the request. For each request, a unique sub-request
+ID is generated. This is used to match the received responses with the published
+requests.
+
+When an SDNR request completes, whether successfully or unsuccessfully, the actor
+populates the *controlLoopResponse* within the *OperationOutcome*. The application
+will typically publish this to a notification topic so that downstream systems can
+take appropriate action.
+
+All SDNR operations are currently supported by a single java class,
+*SdnrOperation*, which is responsible for populating the request structure
+appropriately. This class is derived from *BidirectionalTopicOperation*.
+
+
+Request
+#######
+
+CommonHeader
+************
+
+The "CommonHeader" field in the request is built by policy.
+
+=============================== =========== ==================================================================
+ "CommonHeader" field name type Description
+=============================== =========== ==================================================================
+SubRequestID string Generated by Policy. Is a UUID and used internally by policy
+ to match the response with the request.
+RequestID string Inserted by Policy. Maps to the UUID sent by DCAE i.e. the ID
+ used throughout the closed loop lifecycle to identify a request.
+=============================== =========== ==================================================================
+
+
+Action
+******
+
+The "action" field uniquely identifies the operation to perform. Operation names are
+not validated. Instead, they are passed to SDNR, untouched.
+
+
+RPC Name
+********
+
+The "rpc-name" field is the same as the "action" field, with everything mapped to lower
+case.
+
+
+Payload
+*******
+
+The "payload" field is populated with the *payload* text that is provided within the
+ONSET event; no additional transformation is applied.
+
+
+Examples
+########
+
+Suppose the *ControlLoopOperationParams* were populated as follows:
+
+.. code-block:: bash
+
+ {
+ "actor": "SDNR",
+ "operation": "ModifyConfig",
+ "context": {
+ "event": {
+ "requestId": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "payload": "some text"
+ }
+ }
+ }
+
+An example of a request constructed by the actor using the above parameters, published
+to the SDNR request topic:
+
+.. code-block:: bash
+
+ {
+ "body": {
+ "input": {
+ "CommonHeader": {
+ "TimeStamp": "2020-05-18T14:43:58.550499700Z",
+ "APIVer": "1.0",
+ "RequestID": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "SubRequestID": "848bfd15-b189-43a1-bdea-80982b41fa24",
+ "RequestTrack": {},
+ "Flags": {}
+ },
+ "Action": "ModifyConfig",
+ "Payload": "some text"
+ }
+ },
+ "version": "1.0",
+ "rpc-name": "modifyconfig",
+ "correlation-id": "664be3d2-6c12-4f4b-a3e7-c349acced200-848bfd15-b189-43a1-bdea-80982b41fa24",
+ "type": "request"
+ }
+
+
+An example initial response received from the SDNR response topic:
+
+.. code-block:: bash
+
+ {
+ "body": {
+ "output": {
+ "CommonHeader": {
+ "TimeStamp": "2020-05-18T14:44:10.000Z",
+ "APIver": "1.0",
+ "RequestID": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "SubRequestID": "848bfd15-b189-43a1-bdea-80982b41fa24",
+ "RequestTrack": [],
+ "Flags": []
+ },
+ "Status": {
+ "Code": 100,
+ "Value": "ACCEPTED"
+ }
+ }
+ },
+ "version": "1.0",
+ "rpc-name": "modifyconfig",
+ "correlation-id": "664be3d2-6c12-4f4b-a3e7-c349acced200-848bfd15-b189-43a1-bdea-80982b41fa24",
+ "type": "response"
+ }
+
+
+An example final response received from the SDNR on the same response topic:
+
+.. code-block:: bash
+
+ {
+ "body": {
+ "output": {
+ "CommonHeader": {
+ "TimeStamp": "2020-05-18T14:44:20.000Z",
+ "APIver": "1.0",
+ "RequestID": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "SubRequestID": "848bfd15-b189-43a1-bdea-80982b41fa24",
+ "RequestTrack": [],
+ "Flags": []
+ },
+ "Status": {
+ "Code": 200,
+ "Value": "SUCCESS"
+ },
+ "Payload": "{ \"Configurations\":[ { \"Status\": { \"Code\": 200, \"Value\": \"SUCCESS\" }, \"data\":{\"FAPService\":{\"alias\":\"Chn0330\",\"X0005b9Lte\":{\"phyCellIdInUse\":6,\"pnfName\":\"ncserver23\"},\"CellConfig\":{\"LTE\":{\"RAN\":{\"Common\":{\"CellIdentity\":\"Chn0330\"}}}}}} } ] }"
+ }
+ },
+ "version": "1.0",
+ "rpc-name": "modifyconfig",
+ "correlation-id": "664be3d2-6c12-4f4b-a3e7-c349acced200-848bfd15-b189-43a1-bdea-80982b41fa24",
+ "type": "response"
+ }
+
+
+Configuration of the SDNR Actor
+###############################
+
+The following table specifies the fields that should be provided to configure the SNDR
+actor.
+
+=============================== ==================== ==================================================================
+Field name type Description
+=============================== ==================== ==================================================================
+sinkTopic string Name of the topic to which the request should be published.
+sourceTopic string Name of the topic from which the response should be read.
+ This must not be the same as the *sinkTopic*.
+timeoutSec integer (optional) Maximum time, in seconds, to wait for a response to be received
+ on the topic.
+=============================== ==================== ==================================================================
-This is a place-holder for the actor documentation.
+The individual operations are configured using these same field names. However, all
+of them are optional, as they inherit their values from the corresponding actor-level
+fields.
diff --git a/docs/development/devtools/distribution-s3p.rst b/docs/development/devtools/distribution-s3p.rst
index f448690b..093e28c0 100644
--- a/docs/development/devtools/distribution-s3p.rst
+++ b/docs/development/devtools/distribution-s3p.rst
@@ -270,3 +270,63 @@ Stability test plan was triggered for 72 hours.
.. image:: images/distribution-summary-report.png
.. image:: images/distribution-results-tree.png
+
+Performance Test of Policy Distribution
++++++++++++++++++++++++++++++++++++++++
+
+Introduction
+------------
+
+Performance test of distribution has the goal of testing the min/avg/max processing time and
+rest call throughput for all the requests when the number of requests are large enough to saturate
+the resource and find the bottleneck.
+It also tests that distribution can handle multiple policy csar's and that these are deployed within 30 seconds consistently.
+
+Setup Details
+-------------
+
+The performance test is based on the same setup as the distribution stability tests.
+
+Test Plan
+---------
+
+Performance test plan is different from the stability test plan.
+Instead of handling one policy csar at a time, multiple csar's are deployed within the watched folder at the exact same time.
+We then expect all policies from these csar's to be deployed within 30 seconds.
+Alongside these, there are multithreaded tests running towards the healtchcheck and statistics endpoints of the distribution service.
+
+Run Test
+--------
+
+Copy the performance test plans folder onto VM2.
+Edit the /tmp/ folder permissions to allow the Testplan to insert the CSAR into the /tmp/policydistribution/distributionmount/ folder.
+
+.. code-block:: bash
+
+ $ sudo chmod a+trwx /tmp
+
+From the apache jMeter folder run the test, pointing it towards the stabiltiy.jmx file inside the testplans folder
+
+.. code-block:: bash
+
+ $ ./bin/jmeter -n -t /home/rossc/testplans/performance.jmx -Jduration=259200 -l testresults.jtl
+
+Test Results
+------------
+
+**Summary**
+
+Performance test plan was triggered for 4 hours.
+
+**Test Statistics**
+
+======================= ================= ================== ==================================
+**Total # of requests** **Success %** **Error %** **Average time taken per request**
+======================= ================= ================== ==================================
+239819 100 % 0 % 100 ms
+======================= ================= ================== ==================================
+
+**JMeter Screenshot**
+
+.. image:: images/distribution-performance-summary-report.png
+.. image:: images/distribution-performance-api-report.png
diff --git a/docs/development/devtools/images/distribution-performance-api-report.png b/docs/development/devtools/images/distribution-performance-api-report.png
new file mode 100644
index 00000000..12102718
--- /dev/null
+++ b/docs/development/devtools/images/distribution-performance-api-report.png
Binary files differ
diff --git a/docs/development/devtools/images/distribution-performance-summary-report.png b/docs/development/devtools/images/distribution-performance-summary-report.png
new file mode 100644
index 00000000..3cea8e99
--- /dev/null
+++ b/docs/development/devtools/images/distribution-performance-summary-report.png
Binary files differ