docs/drools/tutorial_vFW.rst

   1
   2 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 ****************************************************
   6 Tutorial: Testing the vFW flow in a standalone PDP-D
   7 ****************************************************
   8
   9 .. contents::
  10     :depth: 3
  11
  12
  13 High Level Architecture
  14 ^^^^^^^^^^^^^^^^^^^^^^^
  15 The vFW flow begins with an onset message that is sent from DCAE notifying the PDP-D that an action needs to be taken on a VNF. Once the PDP-D has inserted the onset into drools memory, rules begin to fire to start processing the onset for the vFW policy that exists in drools memory. If the onset is not enriched with A&AI data, Policy will query A&AI for the VNF data otherwise the PDP-D will get the A&AI data needed directly from the onset. Then an A&AI named query is executed on the source VNF entity from the onset to find the target VNF entity that the PDP-D will take action on. Once the target entity is retrieved from A&AI, a Guard query is executed to determine if the action to be taken is allowed. If Guard returns a permit, the PDP-D will then send an APPC ModifyConfig recipe request to modify pg-streams as specified in the request payload. If APPC is successful then the PDP-D will send a final success notification on the POLICY-CL-MGT topic and gracefully end processing the event.
  16
  17 Initial Setup
  18 ^^^^^^^^^^^^^
  19
  20 For this tutorial, it is assumed that the set up steps from section
  21 *Using the Control Loop PDP-D docker image for standalone testing* has been followed.
  22
  23 Running the Flow
  24 ^^^^^^^^^^^^^^^^
  25
  26 **Step 1:** Deploy the vFW Operational Policy.
  27
  28    .. code-block:: bash
  29
  30        cat pdp-update-vfw.json
  31         {
  32           "policies": [
  33              {
  34              "type": "onap.policies.controlloop.Operational",
  35              "type_version": "1.0.0",
  36              "properties": {
  37              "content": "controlLoop%3A%0A++++version%3A+2.0.0%0A++++controlLoopName%3A+ControlLoop-vFirewall-135835e3-eed7-497a-83ab-8c315f37fa4a%0A++++trigger_policy%3A+unique-policy-id-1-modifyConfig%0A++++timeout%3A+1200%0A++++abatement%3A+false%0Apolicies%3A%0A++++-+id%3A+unique-policy-id-1-modifyConfig%0A++++++name%3A+modify_packet_gen_config%0A++++++description%3A%0A++++++actor%3A+APPC%0A++++++recipe%3A+ModifyConfig%0A++++++target%3A%0A++++++++++resourceID%3A+Eace933104d443b496b8.nodes.heat.vpg%0A++++++++++type%3A+VNF%0A++++++payload%3A%0A++++++++++streams%3A+%27%7B%22active-streams%22%3A5%7D%27%0A++++++retry%3A+0%0A++++++timeout%3A+300%0A++++++success%3A+final_success%0A++++++failure%3A+final_failure%0A++++++failure_timeout%3A+final_failure_timeout%0A++++++failure_retries%3A+final_failure_retries%0A++++++failure_exception%3A+final_failure_exception%0A++++++failure_guard%3A+final_failure_guard%0A"
  38              },
  39              "name": "operational.modifyconfig",
  40              "version": "1.0.0"
  41              }
  42            ],
  43            "messageName": "PDP_UPDATE",
  44            "requestId": "a7a32d3b-37b4-4fb7-9322-b90c6a6fe365",
  45            "timestampMs": 1556125347251,
  46            "name": "pdpd",
  47            "pdpGroup": "controlloop",
  48            "pdpSubgroup": "drools"
  49         }
  50
  51         http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/POLICY-PDP-PAP/events @pdp-update-vfw.json Content-Type:'text/plain'
  52
  53         telemetry
  54         > get controllers/usecases/drools/facts/usecases/controlloops
  55         > get controllers/usecases/drools/facts/usecases/controlloops/ControlLoop-vFirewall-135835e3-eed7-497a-83ab-8c315f37fa4a
  56
  57 **Step 2:** Inject a simulated *ONSET* message.
  58
  59     .. code-block:: bash
  60
  61        cat dcae.vfw.onset.json
  62         {
  63           "closedLoopControlName": "ControlLoop-vFirewall-135835e3-eed7-497a-83ab-8c315f37fa4a",
  64           "closedLoopAlarmStart": 1463679805324,
  65           "closedLoopEventClient": "microservice.stringmatcher",
  66           "closedLoopEventStatus": "ONSET",
  67           "requestID": "c7c6a4aa-bb61-4a15-b831-ba1472dd4a65",
  68           "target_type": "VNF",
  69           "target": "generic-vnf.vnf-id",
  70           "AAI": {
  71             "generic-vnf.is-closed-loop-disabled": "false",
  72             "generic-vnf.prov-status": "ACTIVE",
  73             "generic-vnf.vnf-id": "fw0002vm002fw002"
  74           },
  75           "from": "DCAE",
  76           "version": "1.0.2"
  77         }
  78
  79         # activate NOOP sources
  80
  81         http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/switches/activation
  82
  83         http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-CL/switches/activation
  84
  85         http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/events @dcae.vfw.onset.json Content-Type:'text/plain'  # send onset
  86
  87 Using the telemetry API, a simulated onset can be injected by the user.
  88 For demo purposes, this is the simulated onset that will be used:
  89
  90     .. image:: Tut_vFW_simulated_onset.JPG
  91
  92 **NOTE:** The onset that gets injected has to have a closedLoopControlName that matches
  93 the pushed policy's closedLoopControlName.
  94
  95 There should be 8 objects present. Two timers exist to put a time limit on the operation and on
  96 the overall control loop (in the case of retries or policy chaining).
  97 The event and it's associated manager and operation manager are also present in memory.
  98 A lock on the target entity is inserted to ensure no other events try to take action on
  99 the VNF that is currently processing.
 100
 101 The network log will be used to monitor the activity coming in and out of the PDP-D.
 102 This log is located at *$POLICY_HOME/logs/network.log*.
 103 This will show the notifications that the PDP-D sends out at different stages of processing.
 104 The order of successful processing begins with an ACTIVE notification to show that the onset
 105 was acknowledged and the operation is beginning transit.
 106
 107     .. image:: Tut_vFW_policy_active.JPG
 108
 109 Next a query will be sent to A&AI to get information on the VNF specified from the onset. The picture below shows the query going OUT of the PDP-D and the response coming IN.
 110
 111 **NOTE:** Policy does A&AI queries for VNF information when the onset is not enriched with A&AI data. In this example only the generic-vnf.vnf-name was provided so a query to A&AI is necessary to retrieve data that is needed in the APPC request.
 112
 113     .. image:: Tut_vFW_aai_get.JPG
 114
 115 For the vFW use case, the source entity reported in the onset message may not be the target entity that the APPC operation takes action on. To determine the true target entity, an A&AI named query is performed. The request is shown in the network log.
 116
 117     .. image:: Tut_vFW_aai_named_query_request.JPG
 118
 119 The response is also displayed in the network log.
 120
 121     .. image:: Tut_vFW_aai_named_query_response.JPG
 122
 123 Once the target entity is found, the PDP-D consults Guard to determine if this operation should be allowed, a series of operation notifications are sent for starting the Guard query, obtaining a PERMIT or DENY, and beginning the operation.
 124
 125     .. image:: Tut_vFW_policy_guard_start.JPG
 126
 127 |
 128
 129     .. image:: Tut_vFW_policy_guard_result.JPG
 130
 131 |
 132
 133     .. image:: Tut_vFW_policy_operation_start.JPG
 134
 135 **Step 3:** Inject an APPC response in the APPC-CL topic
 136
 137 A simulated APPC response will be injected to the APPC-CL topic.
 138
 139     .. code-block:: bash
 140
 141        cat appc.legacy.success.json
 142         {
 143           "CommonHeader": {
 144             "TimeStamp": 1506051879001,
 145             "APIver": "1.01",
 146             "RequestID": "c7c6a4aa-bb61-4a15-b831-ba1472dd4a65",
 147             "SubRequestID": "1",
 148             "RequestTrack": [],
 149             "Flags": []
 150           },
 151           "Status": {
 152             "Code": 400,
 153             "Value": "SUCCESS"
 154           },
 155           "Payload": {
 156             "streams": {
 157               "active-streams": 5.0
 158             },
 159             "generic-vnf.vnf-id": "7da01f3d-1e1f-374f-b049-f6385fe8d067"
 160           }
 161         }
 162
 163         http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-CL/switches/activation   # activate noop source
 164
 165        http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-CL/events @appc.legacy.success.json Content-Type:'text/plain'
 166
 167 The network log will show the PDP-D sent an operation success notification.
 168
 169     .. image:: Tut_vFW_policy_operation_success.JPG
 170
 171 Then a final success notification is sent.
 172
 173     .. image:: Tut_vFW_policy_final_success.JPG
 174
 175 After processing there should only be 2 facts left in memory.
 176
 177 End of Document