1 .. This work is licensed under a Creative Commons Attribution 4.0
2 International License. http://creativecommons.org/licenses/by/4.0
10 vFW Traffic Distribution Use Case
11 ---------------------------------
15 The purpose of this work is to show Traffic Distribiution functionality implemented in Casablanca and Dublin releases for vFW Use Case.
16 The orchstration workflow triggers a change to traffic distribution (redistribution) done by a traffic balancing/distribution entity (aka anchor point).
17 The DistributeTraffic action targets the traffic balancing/distribution entity, in some cases DNS, other cases a load balancer external to the VNF instance, as examples.
18 Traffic distribution (weight) changes intended to take a VNF instance out of service are completed only when all in-flight traffic/transactions have been completed.
19 DistributeTrafficCheck command may be used to verify initial conditions of redistribution or can be used to verify the state of VNFs and redistribution itself.
20 To complete the traffic redistribution process, gracefully taking a VNF instance out-of-service/into-service, without dropping in-flight calls or sessions,
21 QuiesceTraffic/ResumeTraffic command may need to follow traffic distribution changes. The VNF application remains in an active state.
24 Traffic Distribution functionality is an outcome of Change Management project. Further details can be found on following pages
26 https://wiki.onap.org/display/DW/Change+Management+Extensions (DistributeTraffic LCM and Use Case)
28 https://wiki.onap.org/display/DW/Change+Management+Dublin+Extensions (Distribute Traffic Workflow with Optimization Framework)
33 .. figure:: files/dt-use-case.png
37 Figure 1 The idea of Traffic Distribution Use Case
39 The idea of the simplified scenario presented in the Casablanca release is shown on Figure 1. In a result of the DistributeTraffic LCM action traffic flow originated from vPKG to vFW 1 and vSINK 1 is redirected to vFW 2 and vSINK 2 (as it is seen on Figure 2).
40 Result of the change can be observed also on the vSINKs' dashboards which show a current incoming traffic. Observation of the dashboard from vSINK 1 and vSINK 2 proves workflow works properly.
42 .. figure:: files/dt-result.png
46 Figure 2 The result of traffic distribution
48 The purpose of the work in the Dublin release was to built a Traffic Distribution Workflow that takes as an input configuration parameters delivered by Optimization Framework and on their basis several traffic distribution LCM actions are executed by APPC in the specific workflow.
50 .. figure:: files/dt-workflow.png
54 Figure 3 The Traffic Distribution Workflow
56 The prepared Traffic Distribution Workflow has following steps:
58 - Workflow sends placement request to Optimization Framework (**1**) specific information about the vPKG and vFW-SINK models and VNF-ID of vFW that we want to migrate traffic out from.
59 Optimization Framework role is to find the vFW-SINK VNF/VF-module instance where traffic should be migrated to and vPKG which will be associated with this vFW.
60 Although in our case the calculation is very simple, the mechanism is ready to work for instances of services with VNF having houndreds of VF-modules spread accross different cloud regions.
62 - Optimization Framework takes from the Policy Framework policies (**2-3**) for VNFs and for relations between each other (in our case there is checked ACTIVE status of vFW-SINK and vPKG VF-modules and the Region to which they belong)
64 - Optimization Framework, base on the information from the polcies and service topology information taken from A&AI (**4-11**), offers traffic distribution anchor and destination canidates' pairs (**12-13**) (pairs of VF-modules data with information about their V-Servers and their network interfaces). This information is returned to the workflow script (**14**).
66 - Information from Optimization Framework can be used to construct APPC LCM requests for DistributeTrafficCheck and DistributeTraffic commands (**15, 24, 33, 42**). This information is used to fill CDT templates with proper data for further Ansible playbooks execution (**17, 26, 35, 44**)
68 - In the first DistributeTrafficCheck LCM request on vPGN VNF/VF-Module APPC, over Ansible, checks if already configured destinatrion of vPKG packages is different than already configured. If not workflow is stopped (**23**).
70 - Next, APPC performs the DistributeTraffic action like it is shown on Figure 1 and Figure 2 (**25-31**). If operation is completed properly traffic should be redirected to vFW 2 and vSINK 2 instance. If not, workflow is stopped (**32**).
72 - Finally, APPC executes the DistributeTrafficCheck action on vFW 1 in order to verify that it does not receives any traffic anymore (**34-40**) and on vFW 2 in order to verify that it receives traffic forwarded from vFW 2 (**43-49**)
77 In order to setup the scenario and to test the DistributeTraffic LCM API in action you need to perform the following steps:
79 1. Create an instance of vFWDT (vPKG , 2 x vFW, 2 x vSINK) – dedicated for the DistributeTraffic LCM API tests
81 #. Gather A&AI facts for Traffic Distribution use case configuration
83 #. Install Traffic Distribution workflow packages
85 #. Configure Optimization Framework for Traffic Distribution workflow
87 #. Configure vPKG and vFW VNFs in APPC CDT tool
89 #. Configure Ansible Server to work with vPKG and vFW VMs
91 #. Execute Traffic Distribution Workflow
93 You will use the following ONAP K8s VMs or containers:
95 - ONAP Rancher Server – workflow setup and its execution
97 - APPC MariaDB container – setup Ansible adapter for vFWDT VNFs
99 - APPC Ansible Server container – setup of Ansible Server, configuration of playbook and input parameters for LCM actions
101 .. note:: In all occurences <K8S-NODE-IP> constant is the IP address of any K8s Node of ONAP OOM installation which hosts ONAP pods i.e. k8s-node-1 and <K8S-RANCHER-IP> constant is the IP address of K8S Rancher Server
103 vFWDT Service Instantiation
104 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
106 In order to test a DistributeTraffic LCM API functionality a dedicated vFW instance must be prepared. It differs from a standard vFW instance by having an additional VF-module with a second instance of vFW and a second instance of vSINK. Thanks to that when a service instance is deployed there are already available two instances of vFW and vSINK that can be used for verification of DistributeTraffic LCM API – there is no need to use the ScaleOut function to test DistributeTraffic functionality what simplifies preparations for tests.
108 In order to instantiate vFWDT service please follow the procedure for standard vFW with following changes. You can create such service manually or you can use robot framework. For manual instantiation:
110 1. Please use the following HEAT templates:
112 https://github.com/onap/demo/tree/master/heat/vFWDT
114 2. Create Virtual Service in SDC with composition like it is shown on Figure 3
116 .. figure:: files/vfwdt-service.png
120 Figure 3 Composition of vFWDT Service
122 3. Use the following payload files in the SDNC-Preload phase during the VF-Module instantiation
124 - :download:`vPKG preload example <files/vpkg-preload.json>`
126 - :download:`vFW/SNK 1 preload example <files/vfw-1-preload.json>`
128 - :download:`vFW/SNK 2 preload example <files/vfw-2-preload.json>`
130 .. note:: Use publikc-key that is a pair for private key files used to log into ONAP OOM Rancher server. It will simplify further configuration
132 .. note:: vFWDT has a specific configuration of the networks – different than the one in original vFW use case (see Figure 4). Two networks must be created before the heat stack creation: *onap-private* network (10.0.0.0/16 typically) and *onap-external-private* (e.g. "10.100.0.0/16"). The latter one should be connected over a router to the external network that gives an access to VMs. Thanks to that VMs can have a floating IP from the external network assigned automatically in a time of stacks' creation. Moreover, the vPKG heat stack must be created before the vFW/vSINK stacks (it means that the VF-module for vPKG must be created as a first one). The vPKG stack creates two networks for the vFWDT use case: *protected* and *unprotected*; so these networks must be present before the stacks for vFW/vSINK are created.
134 .. figure:: files/vfwdt-networks.png
138 Figure 4 Configuration of networks for vFWDT service
140 4. Go to *robot* folder in Rancher server (being *root* user)
142 Go to the Rancher node and locate *demo-k8s.sh* script in *oom/kubernetes/robot* directory. This script will be used to run heatbridge procedure which will update A&AI information taken from OpenStack
144 5. Run robot *heatbridge* in order to upload service topology information into A&AI
148 ./demo-k8s.sh onap heatbridge <stack_name> <service_instance_id> <service> <oam-ip-address>
152 - <stack_name> - HEAT stack name from: OpenStack -> Orchestration -> Stacks
153 - <service_instance_id> - is service_instance_id which you can get from VID or AAI REST API
154 - <service> - in our case it should be vFWDT but may different (vFW, vFWCL) if you have assigned different service type in SDC
155 - <oam-ip-address> - it is the name of HEAT input which stores ONAP management network name
157 Much easier way to create vFWDT service instance is to trigger it from the robot framework. Robot automates creation of service instance and it runs also heatbridge. To create vFWDT this way:
159 1. Go to *robot* folder in Rancher server (being *root* user)
161 Go to the Rancher node and locate *demo-k8s.sh* script in *oom/kubernetes/robot* directory. This script will be used to run instantiate vFWDT service
163 2. Run robot scripts for vFWDT instantiation
167 ./demo-k8s.sh onap init
168 ./ete-k8s.sh onap instantiateVFWDT
171 .. note:: You can verify the status of robot's service instantiation process by going to http://<K8S-NODE-IP>:30209/logs/ (login/password: test/test)
173 After successful instantiation of vFWDT service go to the OpenStack dashboard and project which is configured for VNFs deployment and locate vFWDT VMs. Choose one and try to ssh into one them to proove that further ansible configuration action will be possible
177 ssh -i <rancher_private_key> ubuntu@<VM-IP>
180 .. note:: The same private key file is used to ssh into Rancher server and VMs created by ONAP
182 Preparation of Workflow Script Environment
183 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
185 1. Enter over ssh Rancher server using root user
189 ssh -i <rancher_private_key> root@<K8S-RANCHER-IP>
191 2. Clone onap/demo repository
195 git clone --single-branch --branch dublin "https://gerrit.onap.org/r/demo"
197 3. Enter vFWDT tutorial directory
201 cd demo/tutorials/vFWDT
204 what should show following folders
208 root@sb01-rancher:~/demo/tutorials/vFWDT# ls
209 playbooks preloads workflow
212 .. note:: Remember vFWDT tutorial directory `~/demo/tutorials/vFWDT` for the further use
214 4. Install python dependencies
218 sudo apt-get install python3-pip
219 pip3 install -r workflow/requirements.txt --user
221 Gathering Scenario Facts
222 ------------------------
223 In order to configure CDT tool for execution of Ansible playbooks and for execution of Traffic distribution workflow we need following A&AI facts for vFWDT service
225 - **vnf-id** of generic-vnf vFW instance that we want to migrate traffic out from
226 - **vnf-type** of vPKG VNF - required to configure CDT for Distribute Traffic LCMs
227 - **vnf-type** of vFW-SINK VNFs - required to configure CDT for Distribute Traffic LCMs
229 Gathering facts from VID Portal
230 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
232 1. Enter the VID portal
236 https://<K8S-NODE-IP>:30200/vid/welcome.htm
238 2. In the left hand menu enter **Search for Existing Service Instances**
240 3. Select proper subscriber from the list and press **Submit** button. When service instance of vFWDT Service Type appears Click on **View/Edit** link
242 .. note:: The name of the subscriber you can read from the robot logs if your have created vFWDT instance with robot. Otherwise this should be *Demonstration* subscriber
244 4. For each VNF in vFWDT service instance note its *vnf-id* and *vnf-type*
246 .. figure:: files/vfwdt-vid-vpkg.png
250 Figure 5 vnf-type and vnf-id for vPKG VNF
252 .. figure:: files/vfwdt-vid-vnf-1.png
256 Figure 6 vnf-type and vnf-id for vFW-SINK 1 VNF
258 .. figure:: files/vfwdt-vid-vnf-2.png
262 Figure 7 vnf-type and vnf-id for vFW-SINK 2 VNF
264 Gathering facts directly from A&AI
265 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
267 1. Enter OpenStack dashboard on whicvh vFWDT instance was created and got to **Project->Compute->Instances** and read VM names of vPKG VM and 2 vFW VMs created in vFWDT service instance
269 2. Open Postman or any other REST client
271 3. In Postman in General Settings disable *SSL Certificate verification*
273 4. You can use also following Postman Collection for AAI :download:`AAI Postman Collection <files/vfwdt-aai-postman.json>`
275 5. Alternatively create Collection and set its *Authorization* to *Basic Auth* type with login/password: AAI/AAI
277 6. Create new GET query for *tenants* type with following link and read *tenant-id* value
281 https://<K8S-NODE-IP>:30233/aai/v14/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/
283 .. note:: *CloudOwner* and *Region* names are fixed for default setup of ONAP
285 7. Create new GET query for *vserver* type with following link replacing <tenant-id> with value read before and <vm-name> with vPKG VM name read from OpenStack dashboard
289 https://<K8S-NODE-IP>:30233/aai/v14/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/<tenant-id>/vservers/?vserver-name=<vm-name>
291 Read from the response (realtionship with *generic-vnf* type) vnf-id of vPKG VNF
293 .. note:: If you do not receive any vserver candidate it means that heatbridge procedure was not performed or was not completed successfuly. It is mandatory to continue this tutorial
295 8. Create new GET query for *generic-vnf* type with following link replacing <vnf-id> with value read from previous GET response
299 https://<K8S-NODE-IP>:30233/aai/v14/network/generic-vnfs/generic-vnf/<vnf-id>
301 9. Repeat this procedure also for 2 vFW VMs and note their *vnf-type* and *vnf-id*
303 Configuration of ONAP Environment
304 ---------------------------------
305 This sections show the steps necessary to configure Policies, CDT and Ansible server what is required for execution of APPC LCM actions in the workflow script
307 Configuration of Policies for Optimization Framework
308 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
309 We need to enter the Policy editor in order to upload policy types and then the policy rules for the demo. The polcies are required for the Optimization Framework and they guide OOF how to determine
310 vFW and vPGN instances used in the Traffic Distribution workflow.
312 1. Enter the Policy portal
314 Specify *demo*:*demo* as a login and password
318 https://<K8S-NODE-IP>:30219/onap/login.htm
320 From the left side menu enter *Dictionary* section and from the combo boxes select *MicroService Policy* and *MicroService Models* respectively. Below you can see the result.
322 .. figure:: files/vfwdt-policy-type-list.png
326 Figure 8 List of MicroService policy types in the Policy portal
328 2. Upload the policy types
330 Before policy rules for Traffic Distribution can be uploaded we need to create policy types to store these rules. For that we need to create following three types:
332 - VNF Policy - it used to filter vf-module instances i.e. base on their attributes from the AAI like *provStatus*, *cloudRegionId* etc.
333 - Query Policy - it is used to declare extra inpt parameters for OOF placement request - in our case we need to specify cloud region name
334 - Affinity Policy - it is used to specify the placement rule used for selection vf-module candiate pairs of vFW vf-module instance (traffic destination) and vPGN vf-module instance (anchor point). In this case the match is done by belonging to the same cloud region
336 Enter vFWDT tutorial directory on Rancher server (already created in `Preparation of Workflow Script Environment`_) and create policy types from the following files
340 root@sb01-rancher:~/demo/tutorials/vFWDT# ls policies/types/
341 affinityPolicy-v20181031.yml queryPolicy-v20181031.yml vnfPolicy-v20181031.yml
343 For each file press *Create* button, choose the policy type file, select the *Micro Service Option* (always one available) and enter the *Version* which must be the same like the one specified for policy instances. In this case pass value *OpenSource.version.1*
345 .. figure:: files/vfwdt-add-micro-service-policy.png
349 Figure 9 Creation of new MicroService policy type for OOF
351 In a result you should see in the dictionary all three new types of policies declared
353 .. figure:: files/vfwdt-completed-policy-type-list.png
357 Figure 10 Completed list of MicroService policy types in the Policy portal
359 3. Push the policies into the PDP
361 In order to push policies into the PDP it is required to execute already prepared *uploadPolicies.sh* script that builds policy creation/update requests and automatically sends them to the Policy PDP pod
365 root@sb01-rancher:~/demo/tutorials/vFWDT# ls policies/rules/
366 QueryPolicy_vFW_TD.json affinity_vFW_TD.json uploadPolicies.sh vnfPolicy_vFW_TD.json vnfPolicy_vPGN_TD.json
368 When necessary, you can modify policy json files. Script will read these files and will build new PDP requests based on them. To create new policies execute script in the following way
372 ./policies/rules/uploadPolicies.sh
374 To update existing policies execute script with an extra argument
378 ./policies/rules/uploadPolicies.sh U
380 The result can be verified in the Policy portal, in the *Editor* section, after entering *OSDF_DUBLIN* directory
382 .. figure:: files/vfwdt-policy-editor-osdf-dublin.png
386 Figure 11 List of policies for OOF and vFW traffic distribution
388 Testing Gathered Facts on Workflow Script
389 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
391 Having collected *vnf-id* and *vnf-type* parameters we can execute Traffic Distribution Workflow Python script. It works in two modes. First one executes ony initial phase where AAI and OOF
392 is used to collect neccessary information for configuration of APPC and for further execution phase. The second mode performs also second phase which executes APPC LCM actions.
394 At this stage we will execute script in the initial mode to generate some configuration helpful in CDT and Ansible configuration.
396 1. Enter vFWDT tutorial directory on Rancher server (already created in `Preparation of Workflow Script Environment`_) and execute there workflow script with follwoing parameters
400 python3 workflow.py <VNF-ID> <K8S-NODE-IP> True False True True
402 For now and for further use workflow script has following input parameters:
404 - vnf-id of vFW VNF instance that traffic should be migrated out from
405 - External IP of ONAP Rancher Node i.e. 10.12.5.160 (If Rancher Node is missing this is NFS node)
406 - External IP of ONAP K8s Worker Node i.e. 10.12.5.212
407 - if script should use and build OOF response cache (cache it speed-ups further executions of script)
408 - if instead of vFWDT service instance vFW or vFWCL one is used (should be False always)
409 - if only configuration information will be collected (True for initial phase and False for full execution of workflow)
410 - if APPC LCM action status should be verified and FAILURE should stop workflow (when False FAILED status of LCM action does not stop execution of further LCM actions)
412 2. The script at this stage should give simmilar output
416 Executing workflow for VNF ID '909d396b-4d99-4c6a-a59b-abe948873303' on Rancher with IP 10.0.0.10 and ONAP with IP 10.12.5.217
418 OOF Cache True, is CL vFW False, only info False, check LCM result True
420 vFWDT Service Information:
422 "vf-module-id": "0dce0e61-9309-449a-8e3e-f001635aaab1",
424 "global-customer-id": "DemoCust_ccc04407-1740-4359-b3c4-51bbcb62d9f6",
425 "service-type": "vFWDT",
426 "service-instance-id": "ab37d391-95c6-4844-b7c3-23d111bfa2ce"
429 "model-version-id": "f7fc17ba-48b9-456b-acc1-f89f31eda8cc",
430 "vnf-type": "vFWDT 2019-05-20 21:10:/vFWDT_vFWSNK b463aa83-b1fc 0",
431 "model-invariant-id": "0dfe8d6d-21c1-42f6-867a-1867cebb7751",
432 "vnf-name": "Ete_vFWDTvFWSNK_ccc04407_1"
435 "model-version-id": "0f8a2467-af44-4d7c-ac55-a346dcad9e0e",
436 "vnf-type": "vFWDT 2019-05-20 21:10:/vFWDT_vPKG a646a255-9bee 0",
437 "model-invariant-id": "75e5ec48-f43e-40d2-9877-867cf182e3d0",
438 "vnf-name": "Ete_vFWDTvPKG_ccc04407_0"
444 vofwl01pgn4407 ansible_ssh_host=10.0.210.103 ansible_ssh_user=ubuntu
446 vofwl01vfw4407 ansible_ssh_host=10.0.110.1 ansible_ssh_user=ubuntu
447 vofwl02vfw4407 ansible_ssh_host=10.0.110.4 ansible_ssh_user=ubuntu
449 The result should have almoast the same information for *vnf-id's* of both vFW VNFs. *vnf-type* for vPKG and vFW VNFs should be the same like those collected in previous steps.
450 Ansible Inventory section contains information about the content Ansible Inventor file that will be configured later on `Configuration of Ansible Server`_
452 Configuration of VNF in the APPC CDT tool
453 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
455 Following steps aim to configure DistributeTraffic LCM action for our vPKG and vFW-SINK VNFs in APPC CDT tool.
457 1. Enter the Controller Design Tool portal
461 https://<K8S-NODE-IP>:30289/index.html
463 2. Click on *MY VNFS* button and login to CDT portal giving i.e. *demo* user name
465 3. Click on the *CREATE NEW VNF TYPE* button
467 .. figure:: files/vfwdt-create-vnf-type.png
471 Figure 12 Creation of new VNF type in CDT
473 4. Enter previously retrieved VNF Type for vPKG VNF and press the *NEXT* button
475 .. figure:: files/vfwdt-enter-vnf-type.png
479 Figure 13 Creation of new VNF type in CDT
481 5. For already created VNF Type (if the view does not open itself) click the *View/Edit* button. In the LCM action edit view in the first tab please choose:
483 - *DistributeTraffic* as Action name
485 - *ANSIBLE* as Device Protocol
487 - *Y* value in Template dropdown menu
489 - *admin* as User Name
491 - *8000* as Port Number
494 .. figure:: files/vfwdt-new-lcm-ref-data.png
498 Figure 14 DistributeTraffic LCM action editing
500 6. Go to the *Template* tab and in the editor paste the request template of the DistributeTraffic LCM action for vPKG VNF type
505 "InventoryNames": "VM",
506 "PlaybookName": "${()=(book_name)}",
509 "ne_id": "${()=(ne_id)}",
510 "fixed_ip_address": "${()=(fixed_ip_address)}"
516 "ConfigFileName": "../traffic_distribution_config.json",
517 "vnf_instance": "vfwdt",
520 "traffic_distribution_config.json": "${()=(file_parameter_content)}"
525 .. note:: For all this VNF types and for all actions CDT template is the same except **vnfc-type** parameter that for vPKG VNF type should have value *vpgn* and for vFW-SINK VNF type should have value *vfw-sink*
527 The meaning of selected template parameters is following:
529 - **EnvParameters** group contains all the parameters that will be passed directly to the Ansible playbook during the request's execution. *vnf_instance* is an obligatory parameter for VNF Ansible LCMs. In our case for simplification it has predefined value
530 - **InventoryNames** parameter is obligatory if you want to have NodeList with limited VMs or VNFCs that playbook should be executed on. It can have value *VM* or *VNFC*. In our case *VM* valuye means that NodeList will have information about VMs on which playbook should be executed. In this use case this is always only one VM
531 - **NodeList** parameter value must match the group of VMs like it was specified in the Ansible inventory file. *PlaybookName* must be the same as the name of playbook that was uploaded before to the Ansible server.
535 .. figure:: files/vfwdt-create-template.png
539 Figure 15 LCM DistributeTraffic request template
541 7. Afterwards press the *SYNCHRONIZE WITH TEMPLATE PARAMETERS* button. You will be moved to the *Parameter Definition* tab. The new parameters will be listed there.
543 .. figure:: files/vfwdt-template-parameters.png
547 Figure 16 Summary of parameters specified for DistributeTraffic LCM action.
549 .. note:: For each parameter you can define its: mandatory presence; default value; source (Manual/A&AI). For our case modification of this settings is not necessary
551 8. Finally, go back to the *Reference Data* tab and click *SAVE ALL TO APPC*.
553 .. note:: Remember to configure DistributeTraffic and DistributeTrafficCheck actions for vPKG VNF type and DistributeTrafficCheck action for vFW-SINK
555 Configuration of Ansible Server
556 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
558 After an instantiation of the vFWDT service the Ansible server must be configured in order to allow it a reconfiguration of vPKG VM.
560 1. Copy from Rancher server private key file used for vFWDT VMs' creation and used for access to Rancher server into the :file:`/opt/ansible-server/Playbooks/onap.pem` file
564 sudo kubectl cp <path/to/file>/onap.pem onap/`kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-ansible`:/opt/ansible-server/Playbooks/
566 .. note:: The private key file must be the same like configured at this stage `vFWDT Service Instantiation`_
568 2. Enter the Rancher server and then enter the APPC Ansible server container
572 kubectl exec -it -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-ansible` -- sh
574 3. Give the private key file a proper access rights
578 cd /opt/ansible-server/Playbooks/
580 chown ansible:ansible onap.pem
582 4. Edit the :file:`/opt/ansible-server/Playbooks/Ansible\ \_\ inventory` file including all the hosts of vFWDT service instance used in this use case.
583 The content of the file is generated by workflow script `Testing Gathered Facts on Workflow Script`_
588 vofwl01pgn4407 ansible_ssh_host=10.0.210.103 ansible_ssh_user=ubuntu
590 vofwl01vfw4407 ansible_ssh_host=10.0.110.1 ansible_ssh_user=ubuntu
591 vofwl02vfw4407 ansible_ssh_host=10.0.110.4 ansible_ssh_user=ubuntu
593 .. note:: Names of hosts and their IP addresses will be different. The names of the host groups are the same like 'vnfc-type' attributes configured in the CDT templates
595 5. Configure the default private key file used by Ansible server to access hosts over ssh
599 vi /etc/ansible/ansible.cfg
604 host_key_checking = False
605 private_key_file = /opt/ansible-server/Playbooks/onap.pem
608 .. note:: This is the default privaye key file. In the `/opt/ansible-server/Playbooks/Ansible\ \_\ inventory` different key could be configured but APPC in time of execution of playbbok on Ansible server creates its own dedicated inventory file which does not have private key file specified. In consequence, this key file configured is mandatory for proper execution of playbooks by APPC
611 6. Test that the Ansible server can access over ssh vFWDT hosts configured in the ansible inventory
615 ansible –i Ansible_inventory vpgn,vfw-sink –m ping
618 7. Download the distribute traffic playbook into the :file:`/opt/ansible-server/Playbooks` directory
620 Exit Ansible server pod and enter vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server. Afterwards, copy playbooks into Ansible server pod
624 sudo kubectl cp playbooks/vfw-sink onap/`kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-ansible`:/opt/ansible-server/Playbooks/
625 sudo kubectl cp playbooks/vpgn onap/`kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-ansible`:/opt/ansible-server/Playbooks/
627 8. After the configuration of Ansible serverthe structure of `/opt/ansible-server/Playbooks` directory should be following
631 /opt/ansible-server/Playbooks $ ls -R
633 Ansible_inventory onap.pem vfw-sink vpgn
641 ./vfw-sink/latest/ansible:
642 distributetrafficcheck
644 ./vfw-sink/latest/ansible/distributetrafficcheck:
653 ./vpgn/latest/ansible:
654 distributetraffic distributetrafficcheck
656 ./vpgn/latest/ansible/distributetraffic:
659 ./vpgn/latest/ansible/distributetrafficcheck:
663 Configuration of APPC DB for Ansible
664 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
666 For each VNF that uses the Ansible protocol you need to configure *PASSWORD* and *URL* field in the *DEVICE_AUTHENTICATION* table. This step must be performed after configuration in CDT which populates data in *DEVICE_AUTHENTICATION* table.
668 1. Enter the APPC DB container
672 kubectl exec -it -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-db-0` -- sh
674 2. Enter the APPC DB CLI (password is *gamma*)
680 3. Execute the following SQL commands
684 MariaDB [(none)]> use sdnctl;
685 MariaDB [sdnctl]> UPDATE DEVICE_AUTHENTICATION SET URL = 'http://appc-ansible-server:8000/Dispatch' WHERE ACTION LIKE 'DistributeTraffic%';
686 MariaDB [sdnctl]> UPDATE DEVICE_AUTHENTICATION SET PASSWORD = 'admin' WHERE ACTION LIKE 'DistributeTraffic%';
687 MariaDB [sdnctl]> select * from DEVICE_AUTHENTICATION;
689 Result should be simmilar to the following one:
693 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
694 | DEVICE_AUTHENTICATION_ID | VNF_TYPE | PROTOCOL | ACTION | USER_NAME | PASSWORD | PORT_NUMBER | URL |
695 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
696 | 137 | vFWDT 2019-05-20 21:10:/vFWDT_vPKG a646a255-9bee 0 | ANSIBLE | DistributeTraffic | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
697 | 143 | vFWDT 2019-05-20 21:10:/vFWDT_vFWSNK b463aa83-b1fc 0 | ANSIBLE | DistributeTraffic | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
698 | 149 | vFWDT 2019-05-20 21:10:/vFWDT_vFWSNK b463aa83-b1fc 0 | ANSIBLE | DistributeTrafficCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
699 | 152 | vFWDT 2019-05-20 21:10:/vFWDT_vPKG a646a255-9bee 0 | ANSIBLE | DistributeTrafficCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
700 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
701 4 rows in set (0.00 sec)
704 Testing Traffic Distribution Workflow
705 -------------------------------------
707 Since all the configuration of components of ONAP is already prepared it is possible to enter second phase of Traffic Distribution Workflow execution -
708 the execution of DistributeTraffic and DistributeTrafficCheck LCM actions with configuration resolved before by OptimizationFramework.
714 In order to run Traffic Distribution Workflow execute following commands from the vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server.
719 python3 workflow.py 909d396b-4d99-4c6a-a59b-abe948873303 10.12.5.217 10.12.5.63 True False False True
722 The order of executed LCM actions is following:
724 1. DistributeTrafficCheck on vPKG VM - ansible playbook checks if traffic destinations specified by OOF is not configued in the vPKG and traffic does not go from vPKG already.
725 If vPKG send alreadyt traffic to destination the playbook will fail and workflow will break.
726 2. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF. When everything is fine at this stage
727 change of the traffic should be observed on following dashboards (please turn on automatic reload of graphs)
731 http://<vSINK-1-IP>:667/
732 http://<vSINK-2-IP>:667/
734 3. DistributeTrafficCheck on vFW-1 VM - ansible playbook checks if traffic is not present on vFW from which traffic should be migrated out. If traffic is still present after 30 seconds playbook fails
735 4. DistributeTrafficCheck on vFW-2 VM - ansible playbook checks if traffic is present on vFW from which traffic should be migrated out. If traffic is still not present after 30 seconds playbook fails
741 Expected result of workflow execution, when everythin is fine, is following:
745 Distribute Traffic Workflow Execution:
746 APPC REQ 0 - DistributeTrafficCheck
747 Request Accepted. Receiving result status...
748 Checking LCM DistributeTrafficCheck Status
754 APPC REQ 1 - DistributeTraffic
755 Request Accepted. Receiving result status...
756 Checking LCM DistributeTraffic Status
777 APPC REQ 2 - DistributeTrafficCheck
778 Request Accepted. Receiving result status...
779 Checking LCM DistributeTrafficCheck Status
790 APPC REQ 3 - DistributeTrafficCheck
791 Request Accepted. Receiving result status...
792 Checking LCM DistributeTrafficCheck Status
802 In case of failure the result can be following:
806 Distribute Traffic Workflow Execution:
807 APPC REQ 0 - DistributeTrafficCheck
808 Request Accepted. Receiving result status...
809 Checking LCM DistributeTrafficCheck Status
826 Traceback (most recent call last):
827 File "workflow.py", line 563, in <module>
828 sys.argv[5].lower() == 'true', sys.argv[6].lower() == 'true')
829 File "workflow.py", line 557, in execute_workflow
830 confirm_appc_lcm_action(onap_ip, req, check_result)
831 File "workflow.py", line 529, in confirm_appc_lcm_action
832 raise Exception("LCM {} {} - {}".format(req['input']['action'], status['status'], status['status-reason']))
833 Exception: LCM DistributeTrafficCheck FAILED - FAILED
835 .. note:: When CDT and Ansible is configured properly Traffic Distribution Workflow can fail when you pass as a vnf-id argument the ID of vFW VNF which does not handle traffic at the moment. To solve that pass the VNF ID of the other vFW VNF instance. Because of the same reason you cannot execute twice in a row workflow for the same VNF ID if first execution succedds.