.. http://creativecommons.org/licenses/by/4.0
**********************************************************
-Control Loop Simulation and Injection of Messages Overview
+Control Loop Simulation and Injection of Messages Overview
**********************************************************
.. contents::
Telemetry
^^^^^^^^^
-The username and password for the Telemetry commands are in *${POLCIY_HOME}/config/policy-engine.properties*.
+The username and password for the Telemetry commands are in *${POLICY_HOME}/config/engine.properties*.
Injecting messages:
-------------------
.. code-block:: bash
- http --verify=no --default-scheme=https -a <userName>:<password> PUT :9696/policy/pdp/engine/topics/sources/ueb/<topic>/events @<onsetFile> Content-Type:"text/plain"
+ http --verify=no --default-scheme=https -a <userName>:<password> PUT :9696/policy/pdp/engine/topics/sources/<comm>/<topic>/events @<onsetFile> Content-Type:"text/plain"
-Alternatively, this command could be used:
+where <comm> is either "dmaap", "ueb", or "noop", depending on how the topic has been defined in the
+configuration. "dmaap" is the default deployed messaging communication infrastructure in an ONAP installation.
+The following is the equivalent "curl" version:
.. code-block:: bash
- curl --insecure --silent --user <userName>:<password> -X PUT --header "Content-Type: text/plain" --data @<onsetFile> https://localhost:9696/policy/pdp/engine/topics/sources/ueb/<topic>/events
+ curl --insecure --silent --user <userName>:<password> -X PUT --header "Content-Type: text/plain" --data @<onsetFile> https://localhost:9696/policy/pdp/engine/topics/sources/<comm>/<topic>/events
The topic being used is *unauthenticated.DCAE_CL_OUTPUT*, which is subject to change. The onset file is a file that contains the data to inject as the onset. The data contained depends on the use case. This is an example for VoLTE:
"version": "1.0.2"
}
-Getting Information
+Getting Information
-------------------
To get the name of the active controller(s), use:
Simulators
^^^^^^^^^^
-Currently, there are 4 supported simulators: A&AI, SO, vFC, and guard. When they are up, they are accessed via localhost on the following ports: A&AI – 6666, SO – 6667, vFC – 6668, and guard – 6669. They all respond with hard-coded values representing their various success messages except for with certain inputs. For the A&AI simulator, if the value being queried with a “GET” query is “getFail” the simulator returns an exception message, if the value being queried in a “GET” query is “disableClosedLoop” the simulator returns a response with the value of “is-closed-loop-disabled” set to true, and if the value being queried in a named query is “error” the response from the simulator is A&AI’s failure message. The other simulator that can return multiple response is the guard simulator, and that returns a deny response if the closed loop control name passed in is “denyGuard”
+Currently, there are 4 supported simulators: A&AI, SO, vFC, and guard. When they are up, they are accessed via localhost on the following ports: A&AI – 6666, SO – 6667, vFC – 6668, and guard – 6669. They all respond with hard-coded values representing their various success messages except for with certain inputs. For the A&AI simulator, if the value being queried with a “GET” query is “getFail” the simulator returns an exception message, if the value being queried in a “GET” query is “disableClosedLoop” the simulator returns a response with the value of “is-closed-loop-disabled” set to true, and if the value being queried in a named query is “error” the response from the simulator is A&AI’s failure message. The other simulator that can return multiple response is the guard simulator, and that returns a deny response if the closed loop control name passed in is “denyGuard”
Using the Simulators
--------------------
**Turning on the simulators**
- - First, make sure the controller is off by running the command “*policy stop*”.
- - Then turn the feature on with the command “*features enable controlloop-utils*”.
- - Finally restart the controller by running “*policy start*”.
+ - First, make sure the controller is off by running the command “*policy stop*”.
+ - Then turn the feature on with the command “*features enable controlloop-utils*”.
+ - Finally restart the controller by running “*policy start*”.
- Run “*features status*” again and the *feature controlloop-utils* will be **enabled**.
**Turning the simulators off**
- - First, make sure the controller is off by running the command “*policy stop*”.
+ - First, make sure the controller is off by running the command “*policy stop*”.
- Then turn the feature off with the command “*features disable controlloop-utils*”.
- Finally restart the controller by running “*policy start*”.
- Run “*features status*” again and the *feature controlloop-utils* will be **disabled**.
}
}]
}
-
+
.. code-block:: bash
:caption: vserver-GET-error
}
]
}
-
+
.. code-block:: bash
:caption: NamedQuery-error
End of Document
-
-.. SSNote: Wiki page ref. https://wiki.onap.org/display/DW/Control+Loop+Simulation+and+Injection+of+Messages+Overview
-
.. http://creativecommons.org/licenses/by/4.0
***********************************************************************************************
-Tutorial: Generating and Testing your own Control Loop Operational Policy in a standalone PDP-D
+Using the Control Loop PDP-D docker image for standalone testing
***********************************************************************************************
.. contents::
:depth: 3
-To generate your own control loop operational policy, use the *create-cl-amsterdam* tool. The *create-cl-amsterdam* script is located in *${POLICY_HOME}/bin (/opt/app/policy/bin)*. When the script is run, it will ask for values for a variety of fields. The fields will have pre-filled out defaults, and for the most part, the defaults are fine to leave in. The two main fields that should be changed are the Template Control Loop Name and the Control Loop Yaml.
+In this tutorial will start a Control Loop PDP-D container to use to test Operational Policies
+without companion components.
- .. image:: Tut_cl_valuesHighlight.png
+**Step 1:** Copy a template *base.conf* with configuration to instantiate the container.
-Make sure the Yaml’s controlLoopName matches the Template Control Loop Name you pass in. Finally, confirm that the parameters are correct, confirm the directory it will add the policy files in (default is /tmp) and tell the script to create the maven artifact.
+ .. code-block:: bash
- *Confirm the parameters and enter the directory to install in as shown below:*
+ mkdir config
+ cd config
+ wget https://git.onap.org/policy/docker/plain/config/drools/base.conf?h=dublin -O base.conf
- .. image:: Tut_cl_confirmAndDirectory.PNG
- *Choose whether to immediately deploy (in this case the directory is /tmp/amsterdam)*
+**Step 2:** Simplify *base.conf* for a standalone configuration (by disabling db and nexus access):
- .. image:: Tut_cl_preDeploy.PNG
+ .. code-block:: bash
-When the processing is done, you get the choice of immediately deploying the policy to the local repository, or first examining the rules in the directory it tells you. If you don’t immediately deploy, you need to use the “*mvn install*” command in the newly created directory to continue. When all that is done, go to the directory where the rule was placed (the /tmp/amsterdam directory in this case) and copy the *<name>-controller.properties* file to *${POLICY_HOME}/config*. Turn the engine off and then back on with “*policy stop*” and then “*policy start*”.
+ cd config
+ sed -i "s/^SQL_HOST=.*$/SQL_HOST=/g" base.conf
+ sed -i "s/^SNAPSHOT_REPOSITORY_ID=.*$/SNAPSHOT_REPOSITORY_ID=/g" base.conf
+ sed -i "s/^SNAPSHOT_REPOSITORY_URL=.*$/SNAPSHOT_REPOSITORY_URL=/g" base.conf
+ sed -i "s/^RELEASE_REPOSITORY_ID=.*$/RELEASE_REPOSITORY_ID=/g" base.conf
+ sed -i "s/^RELEASE_REPOSITORY_URL=.*$/RELEASE_REPOSITORY_URL=/g" base.conf
- *Location of the properties file*
+**Step 3:** Open a *bash* shell into the PDP-D Control Loop container.
- .. image:: Tut_cl_propFile.PNG
+ .. code-block:: bash
- *Moving the properties file to ${POLICY_HOME}/config*
+ docker run --rm --env-file config/base.conf -p 9696:9696 -it --name pdp nexus3.onap.org:10001/onap/policy-pdpd-cl:1.4.1 bash
- .. image:: Tut_cl_finalStep.PNG
+**Step 4:** Disable the distributed-locking feature, since this is a single CL PDP-D instance.
+
+ .. code-block:: bash
+
+ features disable distributed-locking
+
+**Step 4:** [OPTIONAL] If using simulators (see tutorials), enable the *controlloop-utils* feature.
+
+ .. code-block:: bash
+
+ features enable controlloop-utils
+
+**Step 5:** [OPTIONAL] To reduce error logs due to being unable to communicate with DMaaP, change the official configuration to use *noop* topics instead (no network IO involved).
+
+ .. code-block:: bash
+
+ cd $POLICY_HOME/config
+ sed -i "s/^dmaap/noop/g" *.properties
+
+**Step 5:** Start the CL PDP-D.
+
+ .. code-block:: bash
+
+ policy start
+
+**Step 6:** Place the CL PDP-D in *ACTIVE* mode.
+
+ .. code-block:: bash
+
+ cat pdp-state-change.json
+ {
+ "state": "ACTIVE",
+ "messageName": "PDP_STATE_CHANGE",
+ "requestId": "385146af-adeb-4157-b97d-6ae85c1ddcb3",
+ "timestampMs": 1555791893587,
+ "name": "8a9e0c256c59",
+ "pdpGroup": "controlloop",
+ "pdpSubgroup": "drools"
+ }
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/POLICY-PDP-PAP/events @pdp-state-change.json Content-Type:'text/plain'
+
+ telemetry # to verify
+ > get lifecycle/fsm/state # verify that state is ACTIVE
+
+Note that *name* in *pdp-state-change.json* can be obtained from running *hostname* in the container.
Proceed with testing your new policy as described in the specific tutorials:
End of Document
-
-
-.. SSNote: Wiki page ref. https://wiki.onap.org/display/DW/Tutorial%3A+Generating+and+Testing+your+own+Control+Loop+Operational+Policy+in+a+standalone+PDP-D
-
.. http://creativecommons.org/licenses/by/4.0
*********************************************************
-Tutorial: Testing the vCPE use case in a standalone PDP-D
+Tutorial: Testing the vCPE use case in a standalone PDP-D
*********************************************************
.. contents::
High Level Architecture
-^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^
The vCPE flow begins with an onset message that is sent from DCAE notifying the PDP-D that an action needs to be taken on a VM/VNF. Once the PDP-D has inserted the onset into drools memory, rules begin to fire to start processing the onset for the vCPE policy that exists in drools memory. If the onset is not enriched with A&AI data, Policy will query A&AI for the VM/VNF data otherwise the PDP-D will get the A&AI data needed directly from the onset. A Guard query is then executed to determine if the action to be taken is allowed. If Guard returns a permit, the PDP-D will then send an APPC Restart recipe request to restart the VM/VNF specified in the request. If APPC is successful then the PDP-D will send a operation success notification on the POLICY-CL-MGT topic. The PDP-D waits for an abatement message to come from DCAE before ending the transaction. Once the abatement is received the PDP-D sends a final success notification and gracefully ends processing the event.
Initial Setup
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^
-For this tutorial, a feature for simulating components involved in the flow outside of Policy will be turned on. Run "*features enable controlloop-utils*".
-
- .. image:: Tut_vCPE_simulators_enabled.JPG
-
-Now start the PDP-D using the command "policy start"
-
- .. image:: Tut_vCPE_policy_start.JPG
+For this tutorial, it is assumed that the set up steps from section
+*Using the Control Loop PDP-D docker image for standalone testing* has been followed.
Running the Flow
-^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^
-The telemetry API is used to see what is in memory. There should only be 1 fact, the Params object which is created at initialization time and contains the vCPE policy that was created.
+**Step 1:** Deploy the vCPE Operational Policy.
.. code-block:: bash
- curl -k --silent --user @1b3rt:31nst31n -X GET https://localhost:9696/policy/pdp/engine/controllers/amsterdam/drools/facts/amsterdam | python -m json.tool
-
-
- .. image:: Tut_vCPE_get_facts.JPG
-
-Using the telemetry API, a simulated onset can be injected by the user. For demo purposes, this is the simulated onset that will be used:
-
- .. image:: Tut_vCPE_simulated_onset.JPG
-
-**NOTE:** The onset that gets injected has to have a closedLoopControlName that matches the pushed policy's closedLoopControlName.
-
-Inject the onset using the Telemetry API.
+ cat pdp-update-vcpe.json
+ {
+ "policies": [
+ {
+ "type": "onap.policies.controlloop.Operational",
+ "type_version": "1.0.0",
+ "properties": {
+ "content": "controlLoop%3A%0A%20%20version%3A%202.0.0%0A%20%20controlLoopName%3A%20ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e%0A%20%20trigger_policy%3A%20unique-policy-id-1-restart%0A%20%20timeout%3A%203600%0A%20%20abatement%3A%20false%0A%20%0Apolicies%3A%0A%20%20-%20id%3A%20unique-policy-id-1-restart%0A%20%20%20%20name%3A%20Restart%20the%20VM%0A%20%20%20%20description%3A%0A%20%20%20%20actor%3A%20APPC%0A%20%20%20%20recipe%3A%20Restart%0A%20%20%20%20target%3A%0A%20%20%20%20%20%20type%3A%20VM%0A%20%20%20%20retry%3A%203%0A%20%20%20%20timeout%3A%201200%0A%20%20%20%20success%3A%20final_success%0A%20%20%20%20failure%3A%20final_failure%0A%20%20%20%20failure_timeout%3A%20final_failure_timeout%0A%20%20%20%20failure_retries%3A%20final_failure_retries%0A%20%20%20%20failure_exception%3A%20final_failure_exception%0A%20%20%20%20failure_guard%3A%20final_failure_guard"
+ },
+ "name": "operational.restart",
+ "version": "1.0.0"
+ }
+ ],
+ "messageName": "PDP_UPDATE",
+ "requestId": "a7a32d3b-37b4-4fb7-9322-b90c6a6fe365",
+ "timestampMs": 1556125347251,
+ "name": "8a9e0c256c59", # note this is the hostname
+ "pdpGroup": "controlloop",
+ "pdpSubgroup": "drools"
+ }
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/POLICY-PDP-PAP/events @pdp-update-vcpe.json Content-Type:'text/plain'
+
+ telemetry # verify
+ > get controllers/usecases/drools/facts/usecases/controlloops
+ > get controllers/usecases/drools/facts/usecases/controlloops/ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e
+
+**Step 2:** Inject a simulated *ONSET* message.
.. code-block:: bash
- curl -k --silent --user @1b3rt:31nst31n --header "Content-Type: text/plain" --data @dcae.vcpe.onset.json -X PUT https://localhost:9696/policy/pdp/engine/topics/sources/ueb/unauthenticated.DCAE_EVENT_OUTPUT/events | python -m json.tool
-
- .. image:: Tut_vCPE_insert_onset.JPG
+ cat dcae.vcpe.onset.json
+ {
+ "closedLoopControlName": "ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e",
+ "closedLoopAlarmStart": 1463679805324,
+ "closedLoopEventClient": "DCAE_INSTANCE_ID.dcae-tca",
+ "closedLoopEventStatus": "ONSET",
+ "requestID": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "target_type": "VNF",
+ "target": "generic-vnf.vnf-id",
+ "AAI": {
+ "vserver.is-closed-loop-disabled": "false",
+ "vserver.prov-status": "ACTIVE",
+ "generic-vnf.vnf-id": "vCPE_Infrastructure_vGMUX_demo_app"
+ },
+ "from": "DCAE",
+ "version": "1.0.2"
+ }
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/switches/activation # activate noop source
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/DCAE_TOPIC/events @dcae.vcpe.onset.json Content-Type:'text/plain' # send onset
**NOTE:** The simulated onset is enriched with A&AI data. The PDP-D will not make an A&AI query since the data needed can be extracted from the onset.
-Now check the facts in memory, there should be 7 objects present. Two timers exist to put a time limit on the operation and on the overall control loop (in the case of retries or policy chaining). The event and it's associated manager and operation manager are also present in memory. A lock on the target entity is inserted to ensure no other events try to take action on the VM/VNF that is currently processing.
+Now check the facts in memory, there should be 8 objects present. Two timers exist to put a time limit on the operation and on the overall control loop (in the case of retries or policy chaining). The event and it's associated manager and operation manager are also present in memory. A lock on the target entity is inserted to ensure no other events try to take action on the VM/VNF that is currently processing.
- .. image:: Tut_vCPE_get_facts_2.JPG
+The network log will be used to monitor the activity coming in and out of the PDP-D. This log is located at *$POLICY_LOGS/network.log*. This will show the notifications that the PDP-D sends out at different stages of processing. The order of successful processing begins with an ACTIVE notification to show that the onset was acknowledged and the operation is beginning transit.
-The network log will be used to monitor the activity coming in and out of the PDP-D. This log is located at *$POLICY_HOME/logs/network.log*. This will show the notifications that the PDP-D sends out at different stages of processing. The order of successful processing begins with an ACTIVE notification to show that the onset was acknowledged and the operation is beginning transit.
-
.. image:: Tut_vCPE_policy_active.JPG
Once the event is in the ACTIVE state, 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.
.. image:: Tut_vCPE_policy_operation.JPG
-Once the operation starts an APPC request is sent out.
-
- .. image:: Tut_vCPE_appc_request.JPG
-
-A simulated APPC response will be injected to the APPC-LCM-WRITE topic, this is the example response used:
-
- .. image:: Tut_vCPE_simulated_appc_response.JPG
-
-Inject the response using the Telemetry API.
+**Step 3:** Inject an APPC response in the APPC-LCM-WRITE topic
.. code-block:: bash
- curl -k --silent --user @1b3rt:31nst31n --header "Content-Type: text/plain" --data @appc.lcm.success.json -X PUT https://localhost:9696/policy/pdp/engine/topics/sources/ueb/APPC-LCM-WRITE/events | python -m json.tool
+ cat appc.lcm.success.json
+ {
+ "body": {
+ "output": {
+ "common-header": {
+ "timestamp": "2017-08-25T21:06:23.037Z",
+ "api-ver": "5.00",
+ "originator-id": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "request-id": "664be3d2-6c12-4f4b-a3e7-c349acced200",
+ "sub-request-id": "1",
+ "flags": {}
+ },
+ "status": {
+ "code": 400,
+ "message": "Restart Successful"
+ }
+ }
+ },
+ "version": "2.0",
+ "rpc-name": "restart",
+ "correlation-id": "664be3d2-6c12-4f4b-a3e7-c349acced200-1",
+ "type": "response"
+ }
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-LCM-WRITE/switches/activation # activate noop source
+
+ http --verify=no -a "${TELEMETRY_USER}:${TELEMETRY_PASSWORD}" PUT https://localhost:9696/policy/pdp/engine/topics/sources/noop/APPC-LCM-WRITE/events @appc.lcm.success.json Content-Type:'text/plain'
.. image:: Tut_vCPE_inject_appc_response.JPG
.. image:: Tut_vCPE_policy_operation_success.JPG
-For the vCPE use case, once an operation is successful, the PDP-D waits for DCAE to send an abatement message to end processing. The following abatement message will be used:
-
- .. image:: Tut_vCPE_simulated_abatement.JPG
-
-Inject the abatement message using the Telemetry API.
-
- .. code-block:: bash
-
- curl -k --silent --user @1b3rt:31nst31n --header "Content-Type: text/plain" --data @dcae.vcpe.abatement.json -X PUT https://localhost:9696/policy/pdp/engine/topics/sources/ueb/unauthenticated.DCAE_EVENT_OUTPUT/events | python -m json.tool
-
- .. image:: Tut_vCPE_insert_abatement.JPG
-
-Once the abatement is received, a final success notification is sent from the PDP-D.
+Once the transaction has completed, a final success notification is sent from the PDP-D.
.. image:: Tut_vCPE_policy_final_success.JPG
-After processing there should only be 1 fact left in memory.
-
- .. image:: Tut_vCPE_final_memory.JPG
-
+After processing there should only be 2 facts left in memory.
End of Document
-
-
-.. SSNote: Wiki page ref. https://wiki.onap.org/display/DW/Tutorial%3A+Testing+the+vCPE+use+case+in+a+standalone+PDP-D
-
-
Code Review / policy / parent.git / commitdiff
