.. 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.
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-#################
-Guard Actor
-#################
+###########
+GUARD Actor
+###########
.. contents::
:depth: 3
-Overview of Guard Actor
-#############################
+Overview of GUARD Actor
+#######################
-This is a place-holder for the actor documentation.
+Within ONAP Policy Framework, a GUARD is typically an implicit check performed at the
+start of each operation and is performed by making a REST call to the XACML-PDP.
+Previously, the request was built, and the REST call made, by the application. However,
+Guard checks have now been implemented using the new Actor framework.
+
+Currently, there is a single operation, *Decision*, which is implemented by the java
+class, *GuardOperation*. This class is derived from *HttpOperation*.
+
+
+Request
+#######
+
+A number of the request fields are populated from values specified in the
+actor/operation's configuration parameters (e.g., "onapName"). Additional fields
+are specified below.
+
+Request ID
+**********
+
+The "requestId" field is set to a UUID.
+
+
+Resource
+********
+
+The "resource" field is populated with a *Map* containing a single item, "guard". The
+value of the item is set to the contents of the *payload* specified within the
+*ControlLoopOperationParams*.
+
+
+Examples
+########
+
+Suppose the *ControlLoopOperationParams* were populated as follows:
+
+.. code-block:: bash
+
+ {
+ "actor": "GUARD",
+ "operation": "Decision",
+ "payload": {
+ "actor": "SO",
+ "operation": "VF Module Create",
+ "target": "OzVServer",
+ "requestId": "c7c6a4aa-bb61-4a15-b831-ba1472dd4a65",
+ "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
+ "vfCount": 2
+ }
+ }
+
+An example of a request constructed by the actor using the above parameters, sent to the
+GUARD REST server:
+
+.. code-block:: bash
+
+ {
+ "ONAPName": "Policy",
+ "ONAPComponent": "Drools PDP",
+ "ONAPInstance": "Usecases",
+ "requestId": "90ee99d2-f2d8-4d90-b162-605203c30180",
+ "action": "guard",
+ "resource": {
+ "guard": {
+ "actor": "SO",
+ "operation": "VF Module Create",
+ "target": "OzVServer",
+ "requestId": "c7c6a4aa-bb61-4a15-b831-ba1472dd4a65",
+ "clname": "ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3",
+ "vfCount": 2
+ }
+ }
+ }
+
+
+An example response received from the GUARD REST service:
+
+.. code-block:: bash
+
+ {
+ "status": "Permit",
+ "advice": {},
+ "obligations": {},
+ "policies": {}
+ }
+
+
+Configuration of the GUARD Actor
+################################
+
+The following table specifies the fields that should be provided to configure the GUARD
+actor.
+
+=============================== ===================== ==================================================================
+Field name type Description
+=============================== ===================== ==================================================================
+clientName string Name of the HTTP client to use to send the request to the
+ GUARD 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.
+onapName string ONAP Name (e.g., "Policy")
+onapComponent string ONAP Component (e.g., "Drools PDP")
+onapInstance string ONAP Instance (e.g., "Usecases")
+action string (optional) Used to populate the "action" request field.
+ Defaults to "guard".
+disabled boolean (optional) **True**, to disable guard checks, **false** otherwise.
+ Defaults to *false*.
+=============================== ===================== ==================================================================
+
+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.
are loaded first. If a later actor has the same name as one that has already been
loaded, a warning will be generated and the later actor discarded. This makes it
possible for an organization to override an actor implementation
+- An implementation for a specific Actor will typically be derived from
+ *HttpActor* or *BidirectionalTopicActor*, depending whether it is HTTP/REST-based
+ or DMaaP-topic-based. These super classes provide most of the functionality needed
+ to configure the operators, extracting operator-specific properties and adding
+ default, actor-level properties
Operator
********
and then continue; the invoker need not deal with the dependency
- Subclasses will typically derive from *HttpOperation* or *BidirectionalTopicOperation*,
though if neither of those suffice, then they can extend *OperationPartial*, or
- even just implement a raw *Operation*
-- Operation subclasses should be written in a way so-as to avoid any blocking I/O
+ even just implement a raw *Operation*. *OperationPartial* is the super class of
+ *HttpOperation* and *BidirectionalTopicOperation* and provides most of the methods
+ used by the Operation subclasses, including a number of utility methods (e.g.,
+ cancellable *allOf*)
+- Operation subclasses should be written in a way so-as to avoid any blocking I/O. If
+ this proves too difficult, then the implementation should override *doOperation()*
+ instead of *startOperationAsync()*
- Operations return a "future" when *start()* is invoked. Typically, if the "future" is
canceled, then any outstanding operation should be canceled. For instance, HTTP
connections should be closed without waiting for a response
.. 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.
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-#################
+.. _so-label:
+
+##########
SO Actor
-#################
+##########
.. contents::
:depth: 3
Overview of SO Actor
-#############################
+######################
+ONAP Policy Framework enables SO as one of the supported actors. SO uses a REST-based
+interface. However, as requests may not complete right away, a REST-based polling
+interface is used to check the status of the request. The *requestId* is extracted
+from the initial response and is appended to the *pathGet* configuration parameter to
+generate the URL used to poll for completion.
+
+Each operation supported by the actor is associated with its own java class, which is
+responsible for populating the request structure appropriately and sending the request.
+Note: the request may be issued via POST, DELETE, etc., depending on the operation.
+The operation-specific classes are all derived from the *SoOperation* class, which is,
+itself, derived from *HttpOperation*. The following operations are currently supported:
+
+- VF Module Create
+- VF Module Delete
+
+
+Request
+#######
+
+A number of nested structures are populated within the request. Several of them are
+populated with data extracted from the A&AI Custom Query response that is retrieved
+using the Target resource ID specified in the *ControlLoopOperationParams*. The
+following table lists the contents of some of the fields that appear within these
+structures.
+
++----------------------------------+---------+----------------------------------------------------------------------+
+| Field Name | Type | Description |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| top level: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *operationType* | string | Inserted by Policy. Name of the operation. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| requestDetails: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| requestParameters | | Applicable to *VF Module Create*. |
+| | | Set by Policy from the *requestParameters* specified in the |
+| | | *payload* of the *ControlLoopOperationParams*. |
+| | | The value is treated as a JSON string and decoded into an |
+| | | *SoRequestParameters* object that is placed into this field. |
++----------------------------------+---------+----------------------------------------------------------------------+
+| configurationParameters | | Applicable to *VF Module Create*. |
+| | | Set by Policy from the *configurationParameters* specified in the |
+| | | *payload* of the *ControlLoopOperationParams*. |
+| | | The value is treated as a JSON string and decoded into a |
+| | | *List* of *Maps* that is placed into this field. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| modelInfo: | | Set by Policy. Copied from the *target* specified in the |
+| | | *ControlLoopOperationParams*. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| cloudConfiguration: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *tenantId* | string | The ID of the "default" Tenant selected from the A&AI Custom Query |
+| | | response. |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *lcpCloudRegionId* | string | The ID of the "default" Cloud Region selected from the A&AI Custom |
+| | | Query response. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| relatedInstanceList[0]: | | Applicable to *VF Module Create*. |
+| | | The "default" Service Instance selected from the A&AI Custom Query |
+| | | response. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| relatedInstanceList[1]: | | Applicable to *VF Module Create*. |
+| | | The VNF selected from the A&AI Custom Query |
+| | | response. |
++----------------------------------+---------+----------------------------------------------------------------------+
+
+
+Examples
+########
+
+Suppose the *ControlLoopOperationParams* were populated as follows:
+
+.. code-block:: bash
+
+ {
+ "actor": "SO",
+ "operation": "Reroute",
+ "target": {
+ "modelInvariantId": "2246ebc9-9b9f-42d0-a5e4-0248324fb884",
+ "modelName": "VlbCdsSb00..vdns..module-3",
+ "modelVersion": "1",
+ "modelCustomizationUuid": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelVersionId": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelCustomizationId": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelUuid": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelInvariantUuid": "2246ebc9-9b9f-42d0-a5e4-0248324fb884"
+ },
+ "context": {
+ "cqdata": {
+ "tenant": {
+ "id": "41d6d38489bd40b09ea8a6b6b852dcbd"
+ },
+ "cloud-region": {
+ "id": "RegionOne"
+ },
+ "service-instance": {
+ "id": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "modelInvariantId": "6418bb39-61e1-45fc-a36b-3f211bb846c7",
+ "modelName": "vLB_CDS_SB00_02",
+ "modelVersion": "1.0",
+ "modelVersionId": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelUuid": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelInvariantUuid": "6418bb39-61e1-45fc-a36b-3f211bb846c7"
+ },
+ "generic-vnf": [
+ {
+ "vnfId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "vf-modules": [
+ {
+ "modelInvariantId": "827356a9-cb60-4976-9713-c30b4f850b41",
+ "modelName": "vLB_CDS_SB00",
+ "modelVersion": "1.0",
+ "modelCustomizationUuid": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelVersionId": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelCustomizationId": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelUuid": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelInvariantUuid": "827356a9-cb60-4976-9713-c30b4f850b41"
+ }
+ ]
+ }
+ ]
+ }
+ },
+ "payload": {
+ "requestParameters": "{\"usePreload\": false}",
+ "configurationParameters": "[{\"ip-addr\": \"$.vf-module-topology.vf-module-parameters.param[16].value\", \"oam-ip-addr\": \"$.vf-module-topology.vf-module-parameters.param[30].value\"}]"
+ }
+ }
+
+An example of a request constructed by the actor using the above parameters, sent to the
+SO REST server:
+
+.. code-block:: bash
+
+ {
+ "requestDetails": {
+ "modelInfo": {
+ "modelInvariantId": "2246ebc9-9b9f-42d0-a5e4-0248324fb884",
+ "modelType": "vfModule",
+ "modelName": "VlbCdsSb00..vdns..module-3",
+ "modelVersion": "1",
+ "modelCustomizationUuid": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelVersionId": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelCustomizationId": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelUuid": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelInvariantUuid": "2246ebc9-9b9f-42d0-a5e4-0248324fb884"
+ },
+ "cloudConfiguration": {
+ "tenantId": "41d6d38489bd40b09ea8a6b6b852dcbd",
+ "lcpCloudRegionId": "RegionOne"
+ },
+ "requestInfo": {
+ "instanceName": "vfModuleName",
+ "source": "POLICY",
+ "suppressRollback": false,
+ "requestorId": "policy"
+ },
+ "relatedInstanceList": [
+ {
+ "relatedInstance": {
+ "instanceId": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "modelInfo": {
+ "modelInvariantId": "6418bb39-61e1-45fc-a36b-3f211bb846c7",
+ "modelType": "service",
+ "modelName": "vLB_CDS_SB00_02",
+ "modelVersion": "1.0",
+ "modelVersionId": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelUuid": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelInvariantUuid": "6418bb39-61e1-45fc-a36b-3f211bb846c7"
+ }
+ }
+ },
+ {
+ "relatedInstance": {
+ "instanceId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "modelInfo": {
+ "modelInvariantId": "827356a9-cb60-4976-9713-c30b4f850b41",
+ "modelType": "vnf",
+ "modelName": "vLB_CDS_SB00",
+ "modelVersion": "1.0",
+ "modelCustomizationUuid": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelVersionId": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelCustomizationId": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelUuid": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelInvariantUuid": "827356a9-cb60-4976-9713-c30b4f850b41"
+ }
+ }
+ }
+ ],
+ "requestParameters": {
+ "usePreload": false
+ },
+ "configurationParameters": [
+ {
+ "ip-addr": "$.vf-module-topology.vf-module-parameters.param[16].value",
+ "oam-ip-addr": "$.vf-module-topology.vf-module-parameters.param[30].value"
+ }
+ ]
+ }
+ }
+
+An example response received to the initial request, from the SO REST service:
+
+.. code-block:: bash
+
+ {
+ "requestReferences": {
+ "requestId": "70f28791-c271-4cae-b090-0c2a359e26d9",
+ "instanceId": "68804843-18e0-41a3-8838-a6d90a035e1a",
+ "requestSelfLink": "http://so.onap:8080/orchestrationRequests/v7/b789e4e6-0b92-42c3-a723-1879af9c799d"
+ }
+ }
+
+An example URL used for the "get" (i.e., poll) request subsequently sent to SO:
+
+.. code-block:: bash
+
+ GET https://so.onap:6969/orchestrationRequests/v5/70f28791-c271-4cae-b090-0c2a359e26d9
+
+An example response received to the poll request, when SO has not completed the request:
+
+.. code-block:: bash
+
+ {
+ "request": {
+ "requestId": "70f28791-c271-4cae-b090-0c2a359e26d9",
+ "startTime": "Fri, 15 May 2020 12:12:50 GMT",
+ "requestScope": "vfModule",
+ "requestType": "scaleOut",
+ "requestDetails": {
+ "modelInfo": {
+ "modelInvariantId": "2246ebc9-9b9f-42d0-a5e4-0248324fb884",
+ "modelType": "vfModule",
+ "modelName": "VlbCdsSb00..vdns..module-3",
+ "modelVersion": "1",
+ "modelCustomizationUuid": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelVersionId": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelCustomizationId": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelUuid": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelInvariantUuid": "2246ebc9-9b9f-42d0-a5e4-0248324fb884"
+ },
+ "requestInfo": {
+ "source": "POLICY",
+ "instanceName": "vfModuleName",
+ "suppressRollback": false,
+ "requestorId": "policy"
+ },
+ "relatedInstanceList": [
+ {
+ "relatedInstance": {
+ "instanceId": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "modelInfo": {
+ "modelInvariantId": "6418bb39-61e1-45fc-a36b-3f211bb846c7",
+ "modelType": "service",
+ "modelName": "vLB_CDS_SB00_02",
+ "modelVersion": "1.0",
+ "modelVersionId": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelUuid": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelInvariantUuid": "6418bb39-61e1-45fc-a36b-3f211bb846c7"
+ }
+ }
+ },
+ {
+ "relatedInstance": {
+ "instanceId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "modelInfo": {
+ "modelInvariantId": "827356a9-cb60-4976-9713-c30b4f850b41",
+ "modelType": "vnf",
+ "modelName": "vLB_CDS_SB00",
+ "modelVersion": "1.0",
+ "modelCustomizationUuid": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelVersionId": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelCustomizationId": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelUuid": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelInvariantUuid": "827356a9-cb60-4976-9713-c30b4f850b41"
+ }
+ }
+ }
+ ],
+ "cloudConfiguration": {
+ "tenantId": "41d6d38489bd40b09ea8a6b6b852dcbd",
+ "tenantName": "Integration-SB-00",
+ "cloudOwner": "CloudOwner",
+ "lcpCloudRegionId": "RegionOne"
+ },
+ "requestParameters": {
+ "usePreload": false
+ },
+ "configurationParameters": [
+ {
+ "ip-addr": "$.vf-module-topology.vf-module-parameters.param[16].value",
+ "oam-ip-addr": "$.vf-module-topology.vf-module-parameters.param[30].value"
+ }
+ ]
+ },
+ "instanceReferences": {
+ "serviceInstanceId": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "vnfInstanceId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "vfModuleInstanceId": "68804843-18e0-41a3-8838-a6d90a035e1a",
+ "vfModuleInstanceName": "vfModuleName"
+ },
+ "requestStatus": {
+ "requestState": "IN_PROGRESS",
+ "statusMessage": "FLOW STATUS: Execution of ActivateVfModuleBB has completed successfully, next invoking ConfigurationScaleOutBB (Execution Path progress: BBs completed = 4; BBs remaining = 2). TASK INFORMATION: Last task executed: Call SDNC RESOURCE STATUS: The vf module was found to already exist, thus no new vf module was created in the cloud via this request",
+ "percentProgress": 68,
+ "timestamp": "Fri, 15 May 2020 12:13:41 GMT"
+ }
+ }
+ }
+
+An example response received to the poll request, when SO has completed the request:
+
+.. code-block:: bash
+
+ {
+ "request": {
+ "requestId": "70f28791-c271-4cae-b090-0c2a359e26d9",
+ "startTime": "Fri, 15 May 2020 12:12:50 GMT",
+ "finishTime": "Fri, 15 May 2020 12:14:21 GMT",
+ "requestScope": "vfModule",
+ "requestType": "scaleOut",
+ "requestDetails": {
+ "modelInfo": {
+ "modelInvariantId": "2246ebc9-9b9f-42d0-a5e4-0248324fb884",
+ "modelType": "vfModule",
+ "modelName": "VlbCdsSb00..vdns..module-3",
+ "modelVersion": "1",
+ "modelCustomizationUuid": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelVersionId": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelCustomizationId": "3a74410a-6c74-4a32-94b2-71488be6da1a",
+ "modelUuid": "1f94cedb-f656-4ddb-9f55-60ba1fc7d4b1",
+ "modelInvariantUuid": "2246ebc9-9b9f-42d0-a5e4-0248324fb884"
+ },
+ "requestInfo": {
+ "source": "POLICY",
+ "instanceName": "vfModuleName",
+ "suppressRollback": false,
+ "requestorId": "policy"
+ },
+ "relatedInstanceList": [
+ {
+ "relatedInstance": {
+ "instanceId": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "modelInfo": {
+ "modelInvariantId": "6418bb39-61e1-45fc-a36b-3f211bb846c7",
+ "modelType": "service",
+ "modelName": "vLB_CDS_SB00_02",
+ "modelVersion": "1.0",
+ "modelVersionId": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelUuid": "d01d9dec-afb6-4a53-bd9e-2eb10ca07a51",
+ "modelInvariantUuid": "6418bb39-61e1-45fc-a36b-3f211bb846c7"
+ }
+ }
+ },
+ {
+ "relatedInstance": {
+ "instanceId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "modelInfo": {
+ "modelInvariantId": "827356a9-cb60-4976-9713-c30b4f850b41",
+ "modelType": "vnf",
+ "modelName": "vLB_CDS_SB00",
+ "modelVersion": "1.0",
+ "modelCustomizationUuid": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelVersionId": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelCustomizationId": "6478f94b-0b20-4b44-afc0-94e48070586a",
+ "modelUuid": "ca3c4797-0cdd-4797-8bec-9a3ce78ac4da",
+ "modelInvariantUuid": "827356a9-cb60-4976-9713-c30b4f850b41"
+ }
+ }
+ }
+ ],
+ "cloudConfiguration": {
+ "tenantId": "41d6d38489bd40b09ea8a6b6b852dcbd",
+ "tenantName": "Integration-SB-00",
+ "cloudOwner": "CloudOwner",
+ "lcpCloudRegionId": "RegionOne"
+ },
+ "requestParameters": {
+ "usePreload": false
+ },
+ "configurationParameters": [
+ {
+ "ip-addr": "$.vf-module-topology.vf-module-parameters.param[16].value",
+ "oam-ip-addr": "$.vf-module-topology.vf-module-parameters.param[30].value"
+ }
+ ]
+ },
+ "instanceReferences": {
+ "serviceInstanceId": "c14e61b5-1ee6-4925-b4a9-b9c8dbfe3f34",
+ "vnfInstanceId": "6636c4d5-f608-4376-b6d8-7977e98cb16d",
+ "vfModuleInstanceId": "68804843-18e0-41a3-8838-a6d90a035e1a",
+ "vfModuleInstanceName": "vfModuleName"
+ },
+ "requestStatus": {
+ "requestState": "COMPLETE",
+ "statusMessage": "STATUS: ALaCarte-VfModule-scaleOut request was executed correctly. FLOW STATUS: Successfully completed all Building Blocks RESOURCE STATUS: The vf module was found to already exist, thus no new vf module was created in the cloud via this request",
+ "percentProgress": 100,
+ "timestamp": "Fri, 15 May 2020 12:14:21 GMT"
+ }
+ }
+ }
+
+
+Configuration of the SO Actor
+###############################
+
+The following table specifies the fields that should be provided to configure the SO
+actor.
+
+=============================== ==================== ==================================================================
+Field name type Description
+=============================== ==================== ==================================================================
+clientName string Name of the HTTP client to use to send the request to the
+ SO 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.
+maxGets integer (optional) Maximum number of get/poll requests to make to determine the
+ final outcome of the request. Defaults to 20.
+waitSecGet integer (optional) Time, in seconds, to wait between issuing "get" requests.
+ Defaults to 20s.
+pathGet string (optional) Path to use when polling (i.e., issuing "get" requests).
+ Note: this should include a trailing slash, but no leading
+ 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.
.. Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-#################
+.. _vfc-label:
+
+##########
VFC Actor
-#################
+##########
.. contents::
:depth: 3
Overview of VFC Actor
-#############################
+######################
+ONAP Policy Framework enables VFC as one of the supported actors.
+
+.. note::
+There has not been any support given to the Policy Framework project for the VFC Actor
+in several releases. Thus, the code and information provided is to the best of the
+knowledge of the team. If there are any questions or problems, please consult the VFC
+Project to help provide guidance.
+
+VFC uses a REST-based
+interface. However, as requests may not complete right away, a REST-based polling
+interface is used to check the status of the request. The *jobId* is extracted
+from each response and is appended to the *pathGet* configuration parameter to
+generate the URL used to poll for completion.
+
+Each operation supported by the actor is associated with its own java class, which is
+responsible for populating the request structure appropriately and sending the request.
+The operation-specific classes are all derived from the *VfcOperation* class, which is,
+itself, derived from *HttpOperation*. The following operations are currently supported:
+
+- Restart
+
+
+Request
+#######
+
+A number of nested structures are populated within the request. Several of them are
+populated from items found within the A&AI "enrichment" data provided by DCAE with
+the ONSET event. The following table lists the contents of some of the fields that
+appear within these structures.
+
++----------------------------------+---------+----------------------------------------------------------------------+
+| Field Name | Type | Description |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| top level: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *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. |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *nsInstanceId* | string | Set by Policy, using the |
+| | | "service-instance.service-instance-id" property |
+| | | found within the enrichment data. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| healVnfData: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *cause* | string | Set by Policy to the name of the operation. |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *vnfInstanceId* | string | Set by Policy, using the |
+| | | "generic-vnf.vnf-id" property |
+| | | found within the enrichment data. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| additionalParams: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *action* | | Set by Policy to the name of the operation. |
++----------------------------------+---------+----------------------------------------------------------------------+
++----------------------------------+---------+----------------------------------------------------------------------+
+| actionvminfo: | | |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *vmid* | string | Set by Policy, using the |
+| | | "vserver.vserver-id" property |
+| | | found within the enrichment data. |
++----------------------------------+---------+----------------------------------------------------------------------+
+| *vmname* | string | Set by Policy, using the |
+| | | "vserver.vserver-name" property |
+| | | found within the enrichment data. |
++----------------------------------+---------+----------------------------------------------------------------------+
+
+
+Examples
+########
+
+Suppose the *ControlLoopOperationParams* were populated as follows:
+
+.. code-block:: bash
+
+ {
+ TBD
+ }
+
+An example of a request constructed by the actor using the above parameters, sent to the
+VFC REST server:
+
+.. code-block:: bash
+
+ {
+ TBD
+ }
+
+An example response received to the initial request, from the VFC REST service:
+
+.. code-block:: bash
+
+ {
+ TBD
+ }
+
+An example URL used for the "get" (i.e., poll) request subsequently sent to VFC:
+
+.. code-block:: bash
+
+ TBD
+
+An example response received to the poll request, when VFC has not completed the request:
+
+.. code-block:: bash
+
+ {
+ TBD
+ }
+
+An example response received to the poll request, when VFC has completed the request:
+
+.. code-block:: bash
+
+ {
+ TBD
+ }
+
+
+Configuration of the VFC Actor
+###############################
+
+The following table specifies the fields that should be provided to configure the VFC
+actor.
+
+=============================== ==================== ==================================================================
+Field name type Description
+=============================== ==================== ==================================================================
+clientName string Name of the HTTP client to use to send the request to the
+ VFC REST server.
+timeoutSec integer (optional) Maximum time, in seconds, to wait for a response to be received
+ from the REST server. Defaults to 90s.
+=============================== ==================== ==================================================================
+
+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. The following additional fields are specified at
+the individual operation level.
-This is a place-holder for the actor documentation.
+=============================== ==================== ===================================================================
+Field name type Description
+=============================== ==================== ===================================================================
+path string URI appended to the URL. Note: this
+ should not include a leading or trailing slash.
+maxGets integer (optional) Maximum number of get/poll requests to make to determine the
+ final outcome of the request. Defaults to 0 (i.e., no polling).
+waitSecGet integer Time, in seconds, to wait between issuing "get" requests.
+ Defaults to 20s.
+pathGet string Path to use when polling (i.e., issuing "get" requests).
+ Note: this should include a trailing slash, but no leading
+ slash.
+=============================== ==================== ===================================================================
Introduction
------------
-The 72 hour stability test of policy API has the goal of verifying the stability of running policy design API REST service by
-ingesting a steady flow of transactions of policy design API calls in a multi-thread fashion to simulate multiple clients' behaviors.
+The 72 hour stability test of policy API has the goal of verifying the stability of running policy design API REST service by
+ingesting a steady flow of transactions of policy design API calls in a multi-thread fashion to simulate multiple clients' behaviors.
All the transaction flows are initiated from a test client server running JMeter for the duration of 72+ hours.
Setup Details
**Lab Environment**
-Intel ONAP Integration and Deployment Labs
+Intel ONAP Integration and Deployment Labs
`Physical Labs <https://wiki.onap.org/display/DW/Physical+Labs>`_,
`Wind River <https://www.windriver.com/>`_
Make the etc/hosts entries
.. code-block:: bash
-
+
$ echo $(hostname -I | cut -d\ -f1) $(hostname) | sudo tee -a /etc/hosts
-
+
Update the Ubuntu software installer
.. code-block:: bash
-
+
$ sudo apt-get update
-
+
Check and install Java
.. code-block:: bash
-
+
$ sudo apt-get install -y openjdk-8-jdk
$ java -version
-
+
Ensure that the Java version executing is OpenJDK version 8
-
+
Check and install docker
.. code-block:: bash
-
+
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
$ sudo apt-get update
$ sudo apt-cache policy docker-ce
- $ sudo apt-get install -y docker-ce
+ $ sudo apt-get install -y unzip docker-ce
$ systemctl status docker
$ docker ps
Change the permissions of the Docker socket file
.. code-block:: bash
-
+
$ sudo chmod 777 /var/run/docker.sock
+Or add the current user to the docker group
+
+.. code-block:: bash
+
+ $ sudo usermod -aG docker $USER
+
Check the status of the Docker service and ensure it is running correctly
.. code-block:: bash
-
+
$ service docker status
$ docker ps
-
+
**VM1 in lab**
**Install JMeter**
Download & install JMeter
.. code-block:: bash
-
+
$ mkdir jMeter
$ cd jMeter
- $ wget http://mirrors.whoishostingthis.com/apache//jmeter/binaries/apache-jmeter-5.1.1.zip
- $ unzip apache-jmeter-5.1.1.zip
-
+ $ wget http://mirrors.whoishostingthis.com/apache//jmeter/binaries/apache-jmeter-5.2.1.zip
+ $ unzip apache-jmeter-5.2.1.zip
+
**Install other necessary components**
Pull api code & run setup components script
.. code-block:: bash
-
+
$ cd ~
$ git clone https://git.onap.org/policy/api
$ cd api/testsuites/stability/src/main/resources/simulatorsetup
- $ ./setup_components.sh
-
+ $ . ./setup_components.sh
+
After installation, make sure the following mariadb container is up and running
.. code-block:: bash
-
+
ubuntu@test:~/api/testsuites/stability/src/main/resources/simulatorsetup$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3849ce44b86d mariadb:10.2.14 "docker-entrypoint.s…" 11 days ago Up 11 days 0.0.0.0:3306->3306/tcp mariadb
Pull api code & run setup api script
.. code-block:: bash
-
+
$ cd ~
$ git clone https://git.onap.org/policy/api
$ cd api/testsuites/stability/src/main/resources/apisetup
- $ ./setup_api.sh <host ip running api> <host ip running mariadb>
+ $ . ./setup_api.sh <host ip running api> <host ip running mariadb>
After installation, make sure the following api container is up and running
.. code-block:: bash
-
+
ubuntu@tools-2:~/api/testsuites/stability/src/main/resources/apisetup$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4f08f9972e55 nexus3.onap.org:10001/onap/policy-api:2.1.1-SNAPSHOT "bash ./policy-api.sh" 11 days ago Up 11 days 0.0.0.0:6969->6969/tcp, 0.0.0.0:9090->9090/tcp policy-api
Install visualVM
.. code-block:: bash
-
+
$ sudo apt-get install visualvm
-
+
Run few commands to configure permissions
.. code-block:: bash
-
+
$ cd /usr/lib/jvm/java-8-openjdk-amd64/bin/
$ sudo touch visualvm.policy
$ sudo chmod 777 visualvm.policy
-
+
$ vi visualvm.policy
-
+
Add the following in visualvm.policy
-
-
+
+
grant codebase "file:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar" {
permission java.security.AllPermission;
};
Run following commands to start jstatd using port 1111
.. code-block:: bash
-
+
$ cd /usr/lib/jvm/java-8-openjdk-amd64/bin/
$ ./jstatd -p 1111 -J-Djava.security.policy=visualvm.policy &
-
+
**Local Machine**
**Run & configure visualVM**
Run visualVM by typing
.. code-block:: bash
-
+
$ jvisualvm
-
+
Connect to jstatd & remote policy-api JVM
1. Right click on "Remote" in the left panel of the screen and select "Add Remote Host..."
.. image:: images/results-5.png
-Test Plan
----------
-
-The 72+ hours stability test will be running the following steps sequentially in multi-threaded loops.
-Thread number is set to 5 to simulate 5 API clients' behaviors (they can be calling the same policy CRUD API simultaneously).
-
-**Setup Thread (will be running only once)**
-
-- Get policy-api Healthcheck
-- Get API Counter Statistics
-- Get Preloaded Policy Types
-
-**API Test Flow (5 threads running the same steps in the same loop)**
-
-- Create a new TCA Policy Type with Version 1.0.0
-- Create a new TCA Policy Type with Version 2.0.0
-- Create a new TCA Policy Type with Version 3.0.0
-- Create a new TCA Policy Type with Version 4.0.0
-- Create a new TCA Policy Type with Version 5.0.0
-- Create a new TCA Policy Type with Version 6.0.0
-- Create a new TCA Policy Type with Version 7.0.0
-- Create a new TCA Policy Type with Version 8.0.0
-- Create a new TCA Policy Type with Version 9.0.0
-- Create a new TCA Policy Type with Version 10.0.0
-- Create a new TCA Policy Type with Version 11.0.0
-- A 10 sec timer
-- Get All Existing Policy Types
-- Get All Existing Versions of the New TCA Policy Type
-- Get Version 1.0.0 of the New TCA Policy Type
-- Get Version 2.0.0 of the New TCA Policy Type
-- Get Version 3.0.0 of the New TCA Policy Type
-- Get Version 4.0.0 of the New TCA Policy Type
-- Get Version 5.0.0 of the New TCA Policy Type
-- Get Version 6.0.0 of the New TCA Policy Type
-- Get Version 7.0.0 of the New TCA Policy Type
-- Get Version 8.0.0 of the New TCA Policy Type
-- Get Version 9.0.0 of the New TCA Policy Type
-- Get Version 10.0.0 of the New TCA Policy Type
-- Get Version 11.0.0 of the New TCA Policy Type
-- Get the Latest Version of the New TCA Policy Type
-- A 10 sec timer
-- Create a New TCA Policy with Version 1.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 2.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 3.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 4.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 5.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 6.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 7.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 8.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 9.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 10.0.0 over the New TCA Policy Type Version 2.0.0
-- Create a New TCA Policy with Version 11.0.0 over the New TCA Policy Type Version 2.0.0
-- A 10 sec Timer
-- Get All Existing TCA Policies
-- Get All Existing Versions of TCA Policies
-- Get Version 1.0.0 of the New TCA Policy
-- Get Version 2.0.0 of the New TCA Policy
-- Get Version 3.0.0 of the New TCA Policy
-- Get Version 4.0.0 of the New TCA Policy
-- Get Version 5.0.0 of the New TCA Policy
-- Get Version 6.0.0 of the New TCA Policy
-- Get Version 7.0.0 of the New TCA Policy
-- Get Version 8.0.0 of the New TCA Policy
-- Get Version 9.0.0 of the New TCA Policy
-- Get Version 10.0.0 of the New TCA Policy
-- Get Version 11.0.0 of the New TCA Policy
-- Get the Latest Version of the New TCA Policy
-- A 10 sec Timer
-- Create a New Guard Policy with Version 1
-- Create a New Guard Policy with Version 5
-- Create a New Guard Policy with Version 9
-- Create a New Guard Policy with Version 12
-- A 10 sec Timer
-- Get Version 1 of the New Guard Policy
-- Get Version 5 of the New Guard Policy
-- Get Version 9 of the New Guard Policy
-- Get Version 12 of the New Guard Policy
-- Get the Latest Version of the New Guard Policy
-- A 10 sec Timer
-
-**TearDown Thread (will only be running after API Test Flow is completed)**
-
-- Delete Version 2.0.0 of the New TCA Policy Type (suppose to return 409-Conflict)
-- Delete Version 3.0.0 of the New TCA Policy Type
-- Delete Version 4.0.0 of the New TCA Policy Type
-- Delete Version 5.0.0 of the New TCA Policy Type
-- Delete Version 6.0.0 of the New TCA Policy Type
-- Delete Version 7.0.0 of the New TCA Policy Type
-- Delete Version 8.0.0 of the New TCA Policy Type
-- Delete Version 9.0.0 of the New TCA Policy Type
-- Delete Version 10.0.0 of the New TCA Policy Type
-- Delete Version 11.0.0 of the New TCA Policy Type
-- Delete Version 1.0.0 of the New TCA Policy
-- Delete Version 2.0.0 of the New TCA Policy
-- Delete Version 3.0.0 of the New TCA Policy
-- Delete Version 4.0.0 of the New TCA Policy
-- Delete Version 5.0.0 of the New TCA Policy
-- Delete Version 6.0.0 of the New TCA Policy
-- Delete Version 7.0.0 of the New TCA Policy
-- Delete Version 8.0.0 of the New TCA Policy
-- Delete Version 9.0.0 of the New TCA Policy
-- Delete Version 10.0.0 of the New TCA Policy
-- Delete Version 11.0.0 of the New TCA Policy
-- Re-Delete Version 2.0.0 of the New TCA Policy Type (will return 200 now since all TCA policies created over have been deleted)
-- Delete Version 1 of the new Guard Policy
-- Delete Version 5 of the new Guard Policy
-- Delete Version 9 of the new Guard Policy
-- Delete Version 12 of the new Guard Policy
-
Run Test
--------
Connect to lab VPN
.. code-block:: bash
-
+
$ sudo openvpn --config <path to lab ovpn key file>
-
+
SSH into JMeter VM (VM1)
.. code-block:: bash
Run JMeter test in background for 72+ hours
.. code-block:: bash
-
+
$ mkdir s3p
- $ nohup ./jMeter/apache-jmeter-5.1.1/bin/jmeter.sh -n -t ~/api/testsuites/stability/src/main/resources/testplans/policy_api_stability.jmx &
+ $ nohup ./jMeter/apache-jmeter-5.2.1/bin/jmeter.sh -n -t ~/api/testsuites/stability/src/main/resources/testplans/policy_api_stability.jmx &
(Optional) Monitor JMeter test that is running in background (anytime after re-logging into JMeter VM - VM1)
$ tail -f s3p/stability.log nohup.out
+Test Plan
+---------
-Test Results
-------------
+The 72+ hours stability test will be running the following steps sequentially
+in multi-threaded loops. Thread number is set to 5 to simulate 5 API clients'
+behaviors (they can be calling the same policy CRUD API simultaneously).
+Each thread creates a different version of the policy types and policies to not
+interfere with one another while operating simultaneously. The point version
+of each entity is set to the running thread number.
+
+**Setup Thread (will be running only once)**
+
+- Get policy-api Healthcheck
+- Get API Counter Statistics
+- Get Preloaded Policy Types
+
+**API Test Flow (5 threads running the same steps in the same loop)**
+
+- Create a new Monitoring Policy Type with Version 6.0.#
+- Create a new Monitoring Policy Type with Version 7.0.#
+- Create a new Optimization Policy Type with Version 6.0.#
+- Create a new Guard Policy Type with Version 6.0.#
+- Create a new Native APEX Policy Type with Version 6.0.#
+- Create a new Native Drools Policy Type with Version 6.0.#
+- Create a new Native XACML Policy Type with Version 6.0.#
+- Get All Policy Types
+- Get All Versions of the new Monitoring Policy Type
+- Get Version 6.0.# of the new Monitoring Policy Type
+- Get Version 6.0.# of the new Optimzation Policy Type
+- Get Version 6.0.# of the new Guard Policy Type
+- Get Version 6.0.# of the new Native APEX Policy Type
+- Get Version 6.0.# of the new Native Drools Policy Type
+- Get Version 6.0.# of the new Native XACML Policy Type
+- Get the Latest Version of the New Monitoring Policy Type
+- Create Monitoring Policy Ver 6.0.# w/Monitoring Policy Type Ver 6.0.#
+- Create Monitoring Policy Ver 7.0.# w/Monitoring Policy Type Ver 7.0.#
+- Create Optimization Policy Ver 6.0.# w/Optimization Policy Type Ver 6.0.#
+- Create Guard Policy Ver 6.0.# w/Guard Policy Type Ver 6.0.#
+- Create Native APEX Policy Ver 6.0.# w/Native APEX Policy Type Ver 6.0.#
+- Create Native Drools Policy Ver 6.0.# w/Native Drools Policy Type Ver 6.0.#
+- Create Native XACML Policy Ver 6.0.# w/Native XACML Policy Type Ver 6.0.#
+- Get Version 6.0.# of the new Monitoring Policy
+- Get Version 6.0.# of the new Optimzation Policy
+- Get Version 6.0.# of the new Guard Policy
+- Get Version 6.0.# of the new Native APEX Policy
+- Get Version 6.0.# of the new Native Drools Policy
+- Get Version 6.0.# of the new Native XACML Policy
+- Get the Latest Version of the new Monitoring Policy
+- Delete Version 6.0.# of the new Monitoring Policy
+- Delete Version 7.0.# of the new Monitoring Policy
+- Delete Version 6.0.# of the new Optimzation Policy
+- Delete Version 6.0.# of the new Guard Policy
+- Delete Version 6.0.# of the new Native APEX Policy
+- Delete Version 6.0.# of the new Native Drools Policy
+- Delete Version 6.0.# of the new Native XACML Policy
+- Delete Monitoring Policy Type with Version 6.0.#
+- Delete Monitoring Policy Type with Version 7.0.#
+- Delete Optimization Policy Type with Version 6.0.#
+- Delete Guard Policy Type with Version 6.0.#
+- Delete Native APEX Policy Type with Version 6.0.#
+- Delete Native Drools Policy Type with Version 6.0.#
+- Delete Native XACML Policy Type with Version 6.0.#
+
+**TearDown Thread (will only be running after API Test Flow is completed)**
+
+- Get policy-api Healthcheck
+- Get Preloaded Policy Types
+
+
+Test Results El-Alto
+--------------------
**Summary**
.. image:: images/results-4.png
+Test Results Frankfurt
+----------------------
+
+PFPP ONAP Windriver lab
+
+**Summary**
+
+Policy API stability test plan was triggered and running for 72+ hours without
+any real errors occurring. The single failure was on teardown and was due to
+simultaneous test plans running concurrently on the lab system.
+
+Compared to El-Alto, 10x the number of API calls were made in the 72 hour run.
+However, the latency increased (most likely due to the synchronization added
+from
+`POLICY-2533 <https://jira.onap.org/browse/POLICY-2533>`_.
+This will be addressed in the next release.
+
+**Test Statistics**
+
+======================= ============= =========== =============================== =============================== ===============================
+**Total # of requests** **Success %** **Error %** **Avg. time taken per request** **Min. time taken per request** **Max. time taken per request**
+======================= ============= =========== =============================== =============================== ===============================
+ 514953 100% 0% 2510 ms 336 ms 15034 ms
+======================= ============= =========== =============================== =============================== ===============================
+
+**VisualVM Results**
+
+VisualVM results were not captured as this was run in the PFPP ONAP Windriver
+lab.
+
+**JMeter Results**
+
+.. image:: images/api-s3p-jm-1_F.png
+
Performance Test of Policy API
++++++++++++++++++++++++++++++
Introduction
------------
-Performance test of policy-api 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.
+Performance test of policy-api 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.
Setup Details
-------------
---------
Performance test plan is the same as stability test plan above.
-Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviors at the same time) whereas reducing the test time down to 1 hour.
+Only differences are, in performance test, we increase the number of threads up to 20 (simulating 20 users' behaviors at the same time) whereas reducing the test time down to 1 hour.
Run Test
--------
.. 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
Policy Drools PDP component
~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Both the Performance and the Stability tests were executed against a default ONAP installation in the PFPP tenant, from an independent VM running the jmeter tool to inject the load.
+
+General Setup
+*************
+
+The kubernetes installation allocated all policy components in the same worker node VM and some additional ones. The worker VM hosting the policy components has the
+following spec:
+
+- 16GB RAM
+- 8 VCPU
+- 160GB Ephemeral Disk
+
+The standalone VM designated to run jmeter has the same configuration and was only
+used to run this tool allocating 12G of heap memory to the jmeter tool.
+
+Other ONAP components used during the estability tests are:
+
+- Policy XACML PDP to process guard queries for each transaction.
+- DMaaP to carry PDP-D and jmeter initiated traffic to complete transactions.
+- Policy API to create (and delete at the end of the tests) policies for each
+ scenario under test.
+- Policy PAP to deploy (and undeploy at the end of the tests) policies for each scenario under test.
+
+The following components are simulated during the tests.
+
+- SO actor for the vDNS use case.
+- APPC responses for the vCPE and vFW use cases.
+- AAI to answer queries for the usecases under test.
+
+In order to restrict APPC responses to just the jmeter too driving all transactions,
+the APPC component was disabled.
+
+SO, and AAI actors were simulated internally within the PDP-D by enabling the
+feature-controlloop-utils previous to run the tests.
+
+PDP-D Setup
+***********
+
+The kubernetes charts were modified previous to the installation with
+the changes below.
+
+The oom/kubernetes/policy/charts/drools/resources/configmaps/base.conf was
+modified:
+
+.. code-block:: bash
+
+ --- a/kubernetes/policy/charts/drools/resources/configmaps/base.conf
+ +++ b/kubernetes/policy/charts/drools/resources/configmaps/base.conf
+ @@ -85,27 +85,27 @@ DMAAP_SERVERS=message-router
+
+ # AAI
+
+ -AAI_HOST=aai.{{.Release.Namespace}}
+ -AAI_PORT=8443
+ +AAI_HOST=localhost
+ +AAI_PORT=6666
+ AAI_CONTEXT_URI=
+
+ # MSO
+
+ -SO_HOST=so.{{.Release.Namespace}}
+ -SO_PORT=8080
+ -SO_CONTEXT_URI=onap/so/infra/
+ -SO_URL=https://so.{{.Release.Namespace}}:8080/onap/so/infra
+ +SO_HOST=localhost
+ +SO_PORT=6667
+ +SO_CONTEXT_URI=
+ +SO_URL=https://localhost:6667/
+
+ # VFC
+
+ -VFC_HOST=
+ -VFC_PORT=
+ +VFC_HOST=localhost
+ +VFC_PORT=6668
+ VFC_CONTEXT_URI=api/nslcm/v1/
+
+ # SDNC
+
+ -SDNC_HOST=sdnc.{{.Release.Namespace}}
+ -SDNC_PORT=8282
+ +SDNC_HOST=localhost
+ +SDNC_PORT=6670
+ SDNC_CONTEXT_URI=restconf/operations/
+
+The AAI actor had to be modified to disable https to talk to the AAI simulator.
+
+.. code-block:: bash
+
+ ~/oom/kubernetes/policy/charts/drools/resources/configmaps/AAI-http-client.properties
+
+ http.client.services=AAI
+
+ http.client.services.AAI.managed=true
+ http.client.services.AAI.https=false
+ http.client.services.AAI.host=${envd:AAI_HOST}
+ http.client.services.AAI.port=${envd:AAI_PORT}
+ http.client.services.AAI.userName=${envd:AAI_USERNAME}
+ http.client.services.AAI.password=${envd:AAI_PASSWORD}
+ http.client.services.AAI.contextUriPath=${envd:AAI_CONTEXT_URI}
+
+The SO actor had to be modified similarly.
+
+.. code-block:: bash
+
+ oom/kubernetes/policy/charts/drools/resources/configmaps/SO-http-client.properties:
+
+ http.client.services=SO
+
+ http.client.services.SO.managed=true
+ http.client.services.SO.https=false
+ http.client.services.SO.host=${envd:SO_HOST}
+ http.client.services.SO.port=${envd:SO_PORT}
+ http.client.services.SO.userName=${envd:SO_USERNAME}
+ http.client.services.SO.password=${envd:SO_PASSWORD}
+ http.client.services.SO.contextUriPath=${envd:SO_CONTEXT_URI}
+
+The feature-controlloop-utils was started by adding the following script:
+
+.. code-block:: bash
+
+ oom/kubernetes/policy/charts/drools/resources/configmaps/features.pre.sh:
+
+ #!/bin/bash
+ bash -c "features enable controlloop-utils"
+
+The PDP-D uses a small configuration:
+
+
+Stability Test of Policy PDP-D
+******************************
+
+The 72 hour stability test happened in parallel with the estability run of the API component.
+
+.. code-block:: bash
+
+ small:
+ limits:
+ cpu: 1
+ memory: 4Gi
+ requests:
+ cpu: 100m
+ memory: 1Gi
+
+Approximately 3.75G heap was allocated to the PDP-D JVM at initialization.
+
+Worker Node performance
+=======================
+
+The VM named onap-k8s-07 was monitored for the duration of the two parallel
+stability runs. The table below show the usage ranges:
+
+.. code-block:: bash
+
+ NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
+ onap-k8s-07 <=1374m <=20% <=10643Mi <=66%
+
+PDP-D performance
+=================
+
+The PDP-D was monitored during the run an stayed below the following ranges:
+
+.. code-block:: bash
+
+ NAME CPU(cores) MEMORY(bytes)
+ dev-drools-0 <=142m 684Mi
+
+Garbagge collection was monitored without detecting any major spike.
+
+The following use cases were tested:
+
+- vCPE
+- vDNS
+- vFirewall
+
+For 72 hours the following 5 scenarios were run in parallel:
+
+- vCPE success scenario
+- vCPE failure scenario (failure returned by simulated APPC recipient through DMaaP).
+- vDNS success scenario.
+- vDNS failure scenario.
+- vFirewall success scenario.
+
+Five threads, one for each scenario described above, push the traffic back to back
+with no pauses.
+
+All transactions completed successfully as expected in each scenario.
+
+The command executed was
+
+.. code-block:: bash
+
+ jmeter -n -t /home/ubuntu/jhh/s3p.jmx > /dev/null 2>&1
+
+The results were computed by taking the ellapsed time from the audit.log
+(this log reports all end to end transactions, marking the start, end, and
+ellapsed times).
+
+The count reflects the number of successful transactions as expected in the
+use case, as well as the average, standard deviation, and max/min. An histogram
+of the response times have been added as a visual indication on the most common transaction times.
+
+vCPE Success scenario
+=====================
+
+ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e:
+
+.. code-block:: bash
+
+ count 155246.000000
+ mean 269.894226
+ std 64.556282
+ min 133.000000
+ 50% 276.000000
+ max 1125.000000
+
+
+Transaction Times histogram:
+
+.. image:: images/ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e.png
+
+
+vCPE Failure scenario
+=====================
+
+ControlLoop-vCPE-Fail:
+
+.. code-block:: bash
+
+ ControlLoop-vCPE-Fail :
+ count 149621.000000
+ mean 280.483522
+ std 67.226550
+ min 134.000000
+ 50% 279.000000
+ max 5394.000000
+
+
+Transaction Times histogram:
+
+.. image:: images/ControlLoop-vCPE-Fail.png
+
+vDNS Success scenario
+=====================
+
+ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3:
+
+.. code-block:: bash
+
+ count 293000.000000
+ mean 21.961792
+ std 7.921396
+ min 15.000000
+ 50% 20.000000
+ max 672.000000
+
+Transaction Times histogram:
+
+.. image:: images/ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3.png
+
+vDNS Failure scenario
+=====================
+
+ControlLoop-vDNS-Fail:
+
+.. code-block:: bash
+
+ count 59357.000000
+ mean 3010.261267
+ std 76.599948
+ min 0.000000
+ 50% 3010.000000
+ max 3602.000000
+
+Transaction Times histogram:
+
+.. image:: images/ControlLoop-vDNS-Fail.png
+
+vFirewall Failure scenario
+==========================
+
+ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a:
+
+.. code-block:: bash
+
+ count 175401.000000
+ mean 184.581251
+ std 35.619075
+ min 136.000000
+ 50% 181.000000
+ max 3972.000000
+
+Transaction Times histogram:
+
+.. image:: images/ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a.png
+
+
+
+
Code Review / policy / parent.git / commitdiff
