diff options
Diffstat (limited to 'docs/development')
| -rw-r--r-- | docs/development/actors/sdnr/sdnr.rst | 186 | ||||
| -rw-r--r-- | docs/development/devtools/distribution-s3p.rst | 60 | ||||
| -rw-r--r-- | docs/development/devtools/images/distribution-performance-api-report.png | bin | 0 -> 76255 bytes | |||
| -rw-r--r-- | docs/development/devtools/images/distribution-performance-summary-report.png | bin | 0 -> 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 Binary files differnew file mode 100644 index 00000000..12102718 --- /dev/null +++ b/docs/development/devtools/images/distribution-performance-api-report.png diff --git a/docs/development/devtools/images/distribution-performance-summary-report.png b/docs/development/devtools/images/distribution-performance-summary-report.png Binary files differnew file mode 100644 index 00000000..3cea8e99 --- /dev/null +++ b/docs/development/devtools/images/distribution-performance-summary-report.png |
