diff options
| -rw-r--r-- | docs/docs_vfw.rst | 28 |
1 files changed, 24 insertions, 4 deletions
diff --git a/docs/docs_vfw.rst b/docs/docs_vfw.rst index fd5fdecee..95b56f347 100644 --- a/docs/docs_vfw.rst +++ b/docs/docs_vfw.rst @@ -63,21 +63,41 @@ The command above enables 5 streams. Running the Use Case ~~~~~~~~~~~~~~~~~~~~ -Users can run the use case using the automated Robot Framework or manually. For using the Robot Framework in an ONAP instance installed with OOM, users have to connect to the Rancher VM and run the following operations: +Running the Use Case +~~~~~~~~~~~~~~~~~~~~ +Users can run the use case using the automated Robot Framework or manually. For using the Robot Framework in an ONAP instance installed with OOM, users should connect to the Rancher VM and run the following operations. First, users should instantiate the vFW using the templates in the heat/vFWCL directory in the demo repository: :: bash oom/kubernetes/robot/ete-k8s.sh <namespace> instantiateVFWCL +The second step is to update the vFW operational policy in the Policy Engine. At startup, the Policy Engine has no policies in its internal repository. Before running use cases, users should push policies by using the push-policies.sh script in the Policy Administration Point (PAP) container. For the vFW use case, users also have to modify the model invariant ID of the vPacketGenerator VNF. The ID in push-policies.sh is a placeholder; the real model invariant ID is generated at service creation time. To update push-policies.sh, users should access the PAP container and copy that script to a non-read-only directory. The current directory, i.e. /tmp/policy-install/config, is used to mount configuration with Helm ConfigMap at container instantiation time and is read-only. + +:: + + PAP_POD=$(kubectl get pods -n onap | grep pap | awk '{ print $1 }') + + kubectl exec -it -n onap $PAP_POD bash + + cp /tmp/policy-install/config/push-policies.sh /tmp/policy-install + + sed -i "s/Eace933104d443b496b8.nodes.heat.vpg/02c953b7-e626-4e16-9874-6191572949a0/g" push-policies.sh + +In the example above, Eace933104d443b496b8.nodes.heat.vpg is a placeholder and it's replaced with 02c953b7-e626-4e16-9874-6191572949a0, which in this example is the actual model invariant ID of the packet generator. + +The next operation is to push policies running the push-policies.sh script from the Rancher VM: + :: - kubectl exec -it $PAP_POD -n onap -c pap -- bash -c 'export PRELOAD_POLICIES=true; /tmp/policy-install/config/push-policies.sh' + kubectl exec -it $PAP_POD -n onap -c pap -- bash -c 'export PRELOAD_POLICIES=true; /tmp/policy-install/push-policies.sh' + +The last instruction to run closed loop generates different traffic pattern from Robot. The following command sets the packet generator to high and low rates, checking whether the policy kicks in to modulate the rates back to medium. :: - bash oom/kubernetes/robot/demo-k8s.sh <namespace> vfwclosedloop <pgn-ip-address> + bash oom/kubernetes/robot/demo-k8s.sh <namespace> vfwclosedloop <pktgen-ip-address> -The first instruction instantiate the vFW using the templates in the heat/vFWCL directory in the demo repository. The second instruction pushes policies to the Policy Engine, while the third instruction sets the packet generator to high and low rates, checking whether the policy kicks in to modulate the rates back to medium. +This last command is not strictly required; the vPacketGenerator internally already has a script that changes the amount of traffic being generated by the VNF. It is still useful to execute the instruction above in case one wants Robot to check whether traffic patterns are applied consistently and closed loop executes correctly, without using the vSink GUI (http://<vSink_ip_address>:667). For documentation about running the use case manually for previous releases, please look at the videos and the material available at this `wiki page`__. |