Merge "Dcoument new VFC Actor"
authorRam Krishna Verma <ram_krishna.verma@bell.ca>
Tue, 19 May 2020 16:23:49 +0000 (16:23 +0000)
committerGerrit Code Review <gerrit@onap.org>
Tue, 19 May 2020 16:23:49 +0000 (16:23 +0000)
docs/development/actors/aai/aai.rst
docs/development/actors/aai/classHierarchy.png [new file with mode: 0644]
docs/development/actors/aai/classHierarchy.pptx [new file with mode: 0644]
docs/development/actors/sdnr/sdnr.rst
docs/development/devtools/distribution-s3p.rst
docs/development/devtools/images/distribution-performance-api-report.png [new file with mode: 0644]
docs/development/devtools/images/distribution-performance-summary-report.png [new file with mode: 0644]

index b8e0bdc..a418f44 100644 (file)
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-#################
+.. _aai-label:
+
+##########
 A&AI Actor
-#################
+##########
 
 .. contents::
     :depth: 3
 
 Overview of A&AI Actor
-#############################
+######################
+ONAP Policy Framework enables various actors, several of which require additional
+data to be gathered from A&AI via a REST call.  Previously, the request was built,
+and the REST call made, by the application.  However, A&AI queries have now been
+implemented using the new Actor framework.
+
+Each operation supported by the actor is associated with its own java class, which is
+responsible for populating the request structure and invoking the REST service.  The
+class hierarchy is shown below.
+
+.. image:: classHierarchy.png
+
+Currently, the following operations are supported:
+
+- Tenant
+- Pnf
+- CustomQuery
+
+One thing that sets the A&AI Actor implementation apart from the other Actor
+implementations is that it is typically used to gather data for input to the
+other actors.  Consequently, when an A&AI operation completes, it places its
+response into the *properties* field of the *context*, which is passed via the
+*ControlLoopOperationParams*.  The names of the keys within the *properties*
+field are typically of the form, "AAI.<operation>.<targetEntity>", where
+"operation" is the name of the operation, and "targetEntity" is the *targetEntity*
+passed via the *ControlLoopOperationParams*.  For example, the response for
+the Tenant query for a target entity named "ozVserver" would be stored as a
+*properties* named "AAI.Tenant.ozVserver".
+
+On the other hand, as there is only one "custom query" for a given ONSET, the
+*Custom Query* operation deviates from this, in that it always stores its response
+using the key, "AAI.AaiCqResponse".
+
+
+Request
+#######
+
+Most of the the A&AI operations use "GET" requests and thus do not populate
+a request structure.  However, for those that do, the request structure is
+described in the table below.
+
+Note: the Custom Query Operation requires tenant data, thus it performs a *Tenant*
+operation before sending its request.  The tenant data is gathered for the vserver
+whose name is found in the "vserver.vserver-name" field of the enrichment data provided
+by DCAE with the ONSET event.
+
++----------------------------------+---------+----------------------------------------------------------------------+
+| Field Name                       |  Type   |                         Description                                  |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| Custom Query:                    |         |                                                                      |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *start*                          | string  |   Extracted from the *result-data[0].resource-link* field of the     |
+|                                  |         |   Tenant query response.                                             |
++----------------------------------+---------+----------------------------------------------------------------------+
+
+
+Examples
+########
+
+Suppose the *ControlLoopOperationParams* were populated as follows, with the tenant
+query having already been performed:
+
+.. code-block:: bash
+
+        {
+            "actor": "AAI",
+            "operation": "CustomQuery",
+            "context": {
+                "enrichment": {
+                    "vserver.vserver-name": "Ete_vFWCLvFWSNK_7ba1fbde_0"
+                },
+                "properties": {
+                    "AAI.Tenant.Ete_vFWCLvFWSNK_7ba1fbde_0": {
+                        "result-data": [
+                            {
+                                "resource-type": "vserver",
+                                "resource-link": "/aai/v15/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/3f2aaef74ecb4b19b35e26d0849fe9a2/vservers/vserver/6c3b3714-e36c-45af-9f16-7d3a73d99497"
+                            }
+                        ]
+                    }
+                }
+            }
+        }
+
+An example of a Custom Query request constructed by the actor using the above
+parameters, sent to the A&AI REST server:
+
+.. code-block:: bash
+
+        {
+          "start": "/aai/v15/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/3f2aaef74ecb4b19b35e26d0849fe9a2/vservers/vserver/6c3b3714-e36c-45af-9f16-7d3a73d99497",
+          "query": "query/closed-loop"
+        }
+
+
+An example response received from the A&AI REST service:
+
+.. code-block:: bash
+
+        {
+            "results": [
+                {
+                    "vserver": {
+                        "vserver-id": "f953c499-4b1e-426b-8c6d-e9e9f1fc730f",
+                        "vserver-name": "Ete_vFWCLvFWSNK_7ba1fbde_0",
+                        "vserver-name2": "Ete_vFWCLvFWSNK_7ba1fbde_0",
+                        "prov-status": "ACTIVE",
+                        "vserver-selflink": "http://10.12.25.2:8774/v2.1/41d6d38489bd40b09ea8a6b6b852dcbd/servers/f953c499-4b1e-426b-8c6d-e9e9f1fc730f",
+                        "in-maint": false,
+                        "is-closed-loop-disabled": false,
+            ...
+        }
+
+
+Configuration of the A&AI Actor
+###############################
+
+The following table specifies the fields that should be provided to configure the A&AI
+actor.
+
+=============================== ====================    ==================================================================
+Field name                         type                             Description
+=============================== ====================    ==================================================================
+clientName                        string                  Name of the HTTP client to use to send the request to the
+                                                          A&AI REST server.
+timeoutSec                        integer (optional)      Maximum time, in seconds, to wait for a response to be received
+                                                          from the REST server.  Defaults to 90s.
+path                              string                  URI appended to the URL.  This field only applies to individual
+                                                          operations; it does not apply at the actor level.  Note: the
+                                                          *path* should not include a leading or trailing slash.
+=============================== ====================    ==================================================================
 
-This is a place-holder for the actor documentation.
+The individual operations are configured using these same field names.  However, all
+of them, except the *path*, are optional, as they inherit their values from the
+corresponding actor-level fields.
diff --git a/docs/development/actors/aai/classHierarchy.png b/docs/development/actors/aai/classHierarchy.png
new file mode 100644 (file)
index 0000000..162b1da
Binary files /dev/null and b/docs/development/actors/aai/classHierarchy.png differ
diff --git a/docs/development/actors/aai/classHierarchy.pptx b/docs/development/actors/aai/classHierarchy.pptx
new file mode 100644 (file)
index 0000000..e320c49
Binary files /dev/null and b/docs/development/actors/aai/classHierarchy.pptx differ
index 2b49d24..13d9194 100644 (file)
 .. 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.
index f448690..093e28c 100644 (file)
@@ -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 (file)
index 0000000..1210271
Binary files /dev/null and b/docs/development/devtools/images/distribution-performance-api-report.png 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 (file)
index 0000000..3cea8e9
Binary files /dev/null and b/docs/development/devtools/images/distribution-performance-summary-report.png differ