diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/development/actors/aai/aai.rst | 143 | ||||
-rw-r--r-- | docs/development/actors/aai/classHierarchy.png | bin | 0 -> 38398 bytes | |||
-rw-r--r-- | docs/development/actors/aai/classHierarchy.pptx | bin | 0 -> 36745 bytes | |||
-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 |
7 files changed, 381 insertions, 8 deletions
diff --git a/docs/development/actors/aai/aai.rst b/docs/development/actors/aai/aai.rst index b8e0bdc6..a418f440 100644 --- a/docs/development/actors/aai/aai.rst +++ b/docs/development/actors/aai/aai.rst @@ -2,14 +2,149 @@ .. 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 Binary files differnew file mode 100644 index 00000000..162b1da3 --- /dev/null +++ b/docs/development/actors/aai/classHierarchy.png diff --git a/docs/development/actors/aai/classHierarchy.pptx b/docs/development/actors/aai/classHierarchy.pptx Binary files differnew file mode 100644 index 00000000..e320c49a --- /dev/null +++ b/docs/development/actors/aai/classHierarchy.pptx 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 |