blob: 0c13886d2024f8c01835181e0808043210eadf86 [file] [log] [blame]
helenc8783e58ef52018-11-30 16:10:10 -08001.. This work is licensed under a Creative Commons Attribution 4.0
2 International License. http://creativecommons.org/licenses/by/4.0
mrichommea958b982020-04-13 18:46:35 +02003
helenc8783e58ef52018-11-30 16:10:10 -08004.. _docs_vfw_traffic:
5
mrichommee4643892020-11-30 18:31:29 +01006:orphan:
Gary Wucd47a012018-11-30 07:18:36 -08007
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02008vFW In-Place Software Upgrade with Traffic Distribution Use Case
9----------------------------------------------------------------
mrichommee4643892020-11-30 18:31:29 +010010
Gary Wucd47a012018-11-30 07:18:36 -080011Description
12~~~~~~~~~~~
13
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020014The purpose of this work is to show In-Place Software Upgrade Traffic Distribution functionality implemented in Frankfurt release for vFW Use Case.
15The use case is an evolution of vFW Traffic Distribution Use Case which was developed for Casablanca and Dublin releases.
16The orchestration workflow triggers a change of the software on selected instance of the firewall. The change is proceeded with minimization of disruption of the
17service since the firewall being upgraded must have all the traffic migrated out before the upgrade can be started. The traffic migration (redistribution) is done by
18a traffic balancing/distribution entity (aka anchor point). 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.
mrichommea958b982020-04-13 18:46:35 +020019Traffic distribution (weight) changes intended to take a VNF instance out of service are completed only when all in-flight traffic/transactions have been completed.
20DistributeTrafficCheck command may be used to verify initial conditions of redistribution or can be used to verify the state of VNFs and redistribution itself.
21To complete the traffic redistribution process, gracefully taking a VNF instance out-of-service/into-service, without dropping in-flight calls or sessions,
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020022QuiesceTraffic/ResumeTraffic command may need to follow traffic distribution changes. The upgrade operation consist of the UpgradePreCheck operation which can used to verify
23initial conditions for the operation like difference of the software version to the one requested, SoftwareUpgrade operation is responsible for modification of the software on
24selected vFW instance and UpgradePostCheck LCM actions is used to verify if the software was properly installed on vFW. After the completion of the software upgrade the traffic is migrated to the
25instance of the vFW which was before being upgraded. The workflow can be configured also in such a way to perform only singular migration of the traffic without upgrade of the software
26what allows to experiment with the version of the workflow implemented in the previous releases. All the LCM operations are executed by APPC controller and they are implemented with Ansible protocol. In order to avoid the inconsistency in the VNFs state the Lock/Unlocks
27mechanisms is used to prevent parallel execution of LCM actions on VNFs that are under maintenance because of the workflow that is currently executed on them.
28The VNF application remains in an active state.
Gary Wucd47a012018-11-30 07:18:36 -080029
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020030Traffic Distribution and In-Place Software Upgrade functionality is an outcome of Change Management project. Further details can be found on the following pages
Gary Wucd47a012018-11-30 07:18:36 -080031
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020032- Frankfurt: https://wiki.onap.org/display/DW/Change+Management+Frankfurt+Extensions (Traffic Distribution workflow enhancements)
Lukasz Rajewski80726d82019-06-04 13:47:17 +020033
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020034- Dublin: https://wiki.onap.org/display/DW/Change+Management+Extensions (DistributeTraffic LCM and Use Case)
Lukasz Rajewski80726d82019-06-04 13:47:17 +020035
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020036- Casablanca https://wiki.onap.org/display/DW/Change+Management+Dublin+Extensions (Distribute Traffic Workflow with Optimization Framework)
Gary Wucd47a012018-11-30 07:18:36 -080037
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020038Test Scenarios
39~~~~~~~~~~~~~~
Gary Wucd47a012018-11-30 07:18:36 -080040
Lukasz Rajewski80726d82019-06-04 13:47:17 +020041.. figure:: files/dt-use-case.png
Gary Wucd47a012018-11-30 07:18:36 -080042 :scale: 40 %
43 :align: center
44
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020045 Figure 1 The overview of interaction of components in vFW In-Place Software Upgrade with Traffic Distribution Use Case
Gary Wucd47a012018-11-30 07:18:36 -080046
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020047The main idea of the use case and prepared workflow is to show the interaction of different components of ONAP, including AAI, Policy, OOF, APPC for realization of scenario of software upgrade
48of vFW instance with migration of the traffic in time of its upgrade. vFW instance was modified to have two instances of vFW with dedicated vSINKs. The general idea of interaction of ONAP components
49is shown on Figure 1. Software Upgrade is performed on selected vFW instance. vPKG and the other vFW taking action while migration of the traffic out of vFW being upgraded. In a result of the DistributeTraffic
50LCM 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). Result of the change can be observed also on the vSINKs' dashboards which show
51a current incoming traffic. After migration software is upgraded on the vFW and afterwards the traffic can be migrated back to this vFW instance. Observation of the dashboard from vSINK 1 and vSINK 2 proves workflow works properly.
Gary Wucd47a012018-11-30 07:18:36 -080052
Lukasz Rajewski80726d82019-06-04 13:47:17 +020053.. figure:: files/dt-result.png
54 :scale: 60 %
Gary Wucd47a012018-11-30 07:18:36 -080055 :align: center
56
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020057 Figure 2 The result of traffic distribution in time of the upgrade
Gary Wucd47a012018-11-30 07:18:36 -080058
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020059The traffic distribution sub-workflow 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.
60Further LCM actions are executed in order to present the idea of vFW In-Place Software Upgrade with Traffic Distribution. In this use case also APPC locking mechanisms is demonstrated, changes in APPC for VNFC level Ansible
61actions support and changes for APPC Ansible automation also are used in the use case. The APPC Ansible automation scripts allows to configure LCM actions without the need to enter the CDT portal, however there is
62possibility to do it manually and documentation describes also how to do it. In the same sense, the upload of policy types and policy instances is automated but the documentation describes how to do it manually.
Lukasz Rajewski80726d82019-06-04 13:47:17 +020063
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020064The demonstration scripts can be used to execute two different scenarios:
65
661. Simple distribution of traffic from selected vFW instance to the other one
67
682. Upgrade of the software on selected vFW instance. Both are preceded with shared phase of identification of VF-modules for reconfiguration what is done with help of Optimization Framework.
69
70Workflows
71~~~~~~~~~
72
73Whole vFW In-Place Software Upgrade with Traffic Distribution use case can be decomposed into following workflows:
74
751. High level workflow (simplified workflow on Figure 3 and more detailed on Figure 4)
76
77.. figure:: files/vfwdt-workflow-general.png
78 :scale: 100 %
Lukasz Rajewski80726d82019-06-04 13:47:17 +020079 :align: center
80
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020081 Figure 3 The In-Place Software Upgrade with Traffic Distribution general workflow
Lukasz Rajewski80726d82019-06-04 13:47:17 +020082
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020083* Identification of vFW instances (**I**) for migration of the traffic (source and destination) and identification of vPKG instance (anchor point) which would be responsible for reconfiguration of the traffic distribution. This operation id performed by Optimization Framework, HAS algorithm in particular
Lukasz Rajewski80726d82019-06-04 13:47:17 +020084
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020085* Before any operation is started workflow Locks (**II-IV**) with APPC all the VNFs involved in the procedure: vFW 1, vFW 2 and vPKG. In fact this is the vFW being upgraded, vFW which will be used to migrate traffic to and vPKG which performs the traffic distribution procedure. The VNFs needs to be locked in order to prevent the execution of other LCM actions in time of the whole workflow execution. Workflow checks state of the Lock on each VNF (**II**)(**1-6**), if the Locs are free (**III**)(**7**) the Locs are being acquired (**IV**)(**8-14**). If any Lock Check or Lock fails (**7, 14**), workflow is stopped.
86
87* Depending on the workflow type different (Traffic Distribution or In-Place Software Upgrade with Traffic Distribution) LCM action are executed by APPC (**V**). All with Ansible protocol and with VNF and VF-modules identified before by Optimization Framework or the input parameters like selected vFW VNF instance. Workflows are conditional and will not be performed if the preconditions were not satisfied. In case of failure of LCM operation any other actions are canceled.
88
89* At the end workflow Unlocks with APPC the previously Locked VNFs (**VI**)(**15-21**). This operations is performed always even when some steps before were not completed. The purpose is to not leave VNFs in locked state (in maintenance status) as this will prevent future execution of LCM actions or workflows on them. The locks are being automatically released after longer time.
90
91.. figure:: files/vfwdt-general-workflow-sd.png
92 :scale: 80 %
93 :align: center
94
95 Figure 4 The In-Place Software Upgrade with Traffic Distribution detailed workflow
96
972. Identification of VF-modules candidates for migration of traffic (detailed workflow is shown on Figure 5)
98
99.. figure:: files/vfwdt-identification-workflow-sd.png
100 :scale: 80 %
101 :align: center
102
103 Figure 5 Identification of VF-Module candidates for migration of traffic
104
105- 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 upgrade.
106 Optimization Framework role is to find the vFW-SINK VNF/VF-module instance where traffic should be migrated to in time of the upgrade and vPKG which will be associated with this vFW.
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200107 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.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200108
109- 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)
110
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200111- Optimization Framework, base on the information from the policies and service topology information taken from A&AI (**4-11**), offers traffic distribution anchor and destination candidates' 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**).
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200112
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200113- Information from Optimization Framework can be used to construct APPC LCM requests for DistributeTrafficCheck, DistributeTraffic, UpgradePreCheck, SoftwareUpgrade and UpgradePostCheck commands. This information is used to fill CDT templates with proper data for further Ansible playbooks execution. Script generates also here CDT templates for LCM actions which can be uploaded automatically to APPC DB.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200114
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02001153. The Traffic Distribution sub-workflow (simplified workflow on Figure 6 and more detailed on Figure 7)
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200116
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200117.. figure:: files/vfwdt-workflow-traffic.png
118 :scale: 100 %
119 :align: center
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200120
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200121 Figure 6 The Traffic Distribution general workflow
122
123- In the first DistributeTrafficCheck LCM request on vPGN VNF/VF-Module APPC, over Ansible, checks if already configured destination of vPKG packages is different than already configured one (**I-III**)(**1-8**). If not workflow is stopped (**9**).
124
125- Next, APPC performs the DistributeTraffic action (**IV**)(**10-17**). If operation is completed properly traffic should be redirected to vFW 2 and vSINK 2 instance. If not, workflow is stopped (**18**).
126
127- Finally, APPC executes the DistributeTrafficCheck action (**V**) on vFW 1 in order to verify that it does not receive any traffic anymore (**19-26**) and on vFW 2 in order to verify that it receives traffic forwarded from vFW 2 (**28-35**). Workflow is stopped with failed state (**37**) if one of those conditions was not satisfied (**27, 36**)
128
129.. figure:: files/vfwdt-td-workflow-sd.png
130 :scale: 80 %
131 :align: center
132
133 Figure 7 The Traffic Distribution detailed workflow
134
1354. The In-Place Software Upgrade with Traffic Distribution sub-workflow (simplified workflow on Figure 8 and more detailed on Figure 9)
136
137.. figure:: files/vfwdt-workflow-upgrade.png
138 :scale: 100 %
139 :align: center
140
141 Figure 8 The In-Place Software Upgrade general workflow
142
143- Firstly there is performed the UpgradePreCheck LCM operation on selected vFW instance (**I**)(**1-8**). The Ansible script executed by the APPC checks if the software version is different than the one indicated in workflow's input. If it is the same the workflow is stopped (**9**).
144
145- When software of selected vFW instance needs to be upgraded (**II**) then the traffic migration procedure needs to be performed (**III** - see sub-workflow 3). If migration of traffic fails workflow is stopped.
146
147- Next APPC performs over Ansible procedure of in place software upgrade. In our case this is simple refresh of the software packages on VM in order to simulate some upgrade process. Successful completion of the script should set the version of the software to the one from the upgrade request. If action fails workflow is stopped without further rollback (**18**).
148
149- Afterwards, APPC performs the UpgradePostCheck LCM action (**IV**)(**19-26**). The script verifies if the version of software is the same like requested before in the upgrade. If not, workflow is stopped without further rollback (**27**).
150
151- Finally, when software upgrade is completed traffic migration procedure needs to be performed again (**VI**) to migrate traffic back to upgraded before vFW instance (see sub-workflow 3). If migration of traffic fails workflow is stopped and rollback is no being performed.
152
153.. figure:: files/vfwdt-upgrade-workflow-sd.png
154 :scale: 80 %
155 :align: center
156
157 Figure 9 The In-Place Software Upgrade detailed workflow
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200158
159Scenario Setup
160--------------
161
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200162In order to setup the scenario and to test workflows with APPC LCM APIs in action you need to perform the following steps:
Gary Wucd47a012018-11-30 07:18:36 -0800163
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02001641. Create an instance of vFWDT (vPKG , 2 x vFW, 2 x vSINK) – dedicated for the traffic migration tests
Gary Wucd47a012018-11-30 07:18:36 -0800165
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200166#. Gather A&AI facts for use case configuration
Gary Wucd47a012018-11-30 07:18:36 -0800167
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200168#. Install Software Upgrade and Traffic Distribution workflow packages
Gary Wucd47a012018-11-30 07:18:36 -0800169
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200170#. Configure Optimization Framework for Traffic Distribution candidates gathering
Gary Wucd47a012018-11-30 07:18:36 -0800171
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200172#. Configure vPKG and vFW VNFs in APPC CDT tool
Gary Wucd47a012018-11-30 07:18:36 -0800173
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200174#. Configure Ansible Server to work with vPKG and vFW VMs
Gary Wucd47a012018-11-30 07:18:36 -0800175
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200176#. Execute Traffic Distribution or In-Place Upgrade Workflows
Gary Wucd47a012018-11-30 07:18:36 -0800177
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200178You will use the following ONAP K8s VMs or containers:
Gary Wucd47a012018-11-30 07:18:36 -0800179
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200180- ONAP Rancher Server – workflow setup and its execution
Gary Wucd47a012018-11-30 07:18:36 -0800181
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200182- APPC MariaDB container – setup Ansible adapter for vFWDT VNFs
Gary Wucd47a012018-11-30 07:18:36 -0800183
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200184- APPC Ansible Server container – setup of Ansible Server, configuration of playbook and input parameters for LCM actions
Gary Wucd47a012018-11-30 07:18:36 -0800185
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200186.. note:: In all occurrences *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
Gary Wucd47a012018-11-30 07:18:36 -0800187
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200188vFWDT Service Instantiation
189~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gary Wucd47a012018-11-30 07:18:36 -0800190
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200191In order to test workflows 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 migration of traffic from one vFW instance to the other one – there is no need to use the ScaleOut function to test workflows what simplifies preparations for tests.
Gary Wucd47a012018-11-30 07:18:36 -0800192
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200193In 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:
Gary Wucd47a012018-11-30 07:18:36 -0800194
1951. Please use the following HEAT templates:
196
197https://github.com/onap/demo/tree/master/heat/vFWDT
198
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02001992. Create Virtual Service in SDC with composition like it is shown on Figure 10
Gary Wucd47a012018-11-30 07:18:36 -0800200
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200201.. figure:: files/vfwdt-service.png
202 :scale: 60 %
Gary Wucd47a012018-11-30 07:18:36 -0800203 :align: center
204
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200205 Figure 10 Composition of vFWDT Service
Gary Wucd47a012018-11-30 07:18:36 -0800206
2073. Use the following payload files in the SDNC-Preload phase during the VF-Module instantiation
208
209- :download:`vPKG preload example <files/vpkg-preload.json>`
210
211- :download:`vFW/SNK 1 preload example <files/vfw-1-preload.json>`
212
213- :download:`vFW/SNK 2 preload example <files/vfw-2-preload.json>`
214
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200215.. note:: Use public-key that is a pair for private key files used to log into ONAP OOM Rancher server. It will simplify further configuration
Gary Wucd47a012018-11-30 07:18:36 -0800216
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200217.. note:: vFWDT has a specific configuration of the networks – different than the one in original vFW use case (see Figure 11). 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.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200218
219.. figure:: files/vfwdt-networks.png
220 :scale: 15 %
Gary Wucd47a012018-11-30 07:18:36 -0800221 :align: center
222
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200223 Figure 11 Configuration of networks for vFWDT service
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200224
2254. Go to *robot* folder in Rancher server (being *root* user)
226
227Go 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
228
2295. Run robot *heatbridge* in order to upload service topology information into A&AI
230
231::
232
233 ./demo-k8s.sh onap heatbridge <stack_name> <service_instance_id> <service> <oam-ip-address>
234
235where:
236
237- <stack_name> - HEAT stack name from: OpenStack -> Orchestration -> Stacks
238- <service_instance_id> - is service_instance_id which you can get from VID or AAI REST API
239- <service> - in our case it should be vFWDT but may different (vFW, vFWCL) if you have assigned different service type in SDC
240- <oam-ip-address> - it is the name of HEAT input which stores ONAP management network name
241
242Much 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:
243
2441. Go to *robot* folder in Rancher server (being *root* user)
245
246Go 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
247
2482. Run robot scripts for vFWDT instantiation
249
250::
251
252 ./demo-k8s.sh onap init
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200253 ./ete-k8s.sh onap instantiateVFWDTGRA
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200254
255
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200256.. note:: You can verify the status of robot's service instantiation process by going to https://K8S_NODE_IP:30209/logs/ (login/password: test/test)
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200257
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200258After 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 prove that further ansible configuration action will be possible
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200259
260::
261
262 ssh -i <rancher_private_key> ubuntu@<VM-IP>
263
264
265.. note:: The same private key file is used to ssh into Rancher server and VMs created by ONAP
266
267Preparation of Workflow Script Environment
268~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
269
2701. Enter over ssh Rancher server using root user
271
272::
273
274 ssh -i <rancher_private_key> root@<K8S-RANCHER-IP>
275
2762. Clone onap/demo repository
277
278::
279
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200280 git clone --single-branch --branch frankfurt "https://gerrit.onap.org/r/demo"
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200281
2823. Enter vFWDT tutorial directory
283
284::
285
286 cd demo/tutorials/vFWDT
287 ls
288
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200289what should show following folders
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200290
291::
292
293 root@sb01-rancher:~/demo/tutorials/vFWDT# ls
Lukasz Rajewski61a35bc2020-05-14 11:08:43 +0200294 get_secret.sh playbooks policies preloads workflow
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200295
296
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200297.. note:: Remember vFWDT tutorial directory `~/demo/tutorials/vFWDT` for the further use
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200298
2994. Install python dependencies
300
301::
302
303 sudo apt-get install python3-pip
304 pip3 install -r workflow/requirements.txt --user
305
306Gathering Scenario Facts
307------------------------
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200308In order to configure CDT tool for execution of Ansible playbooks and for execution of workflows we need following A&AI facts for vFWDT service
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200309
310- **vnf-id** of generic-vnf vFW instance that we want to migrate traffic out from
311- **vnf-type** of vPKG VNF - required to configure CDT for Distribute Traffic LCMs
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200312- **vnf-type** of vFW-SINK VNFs - required to configure CDT for Distribute Traffic and Software Upgrade LCMs
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200313
314Gathering facts from VID Portal
315~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
316
3171. Enter the VID portal
318
mrichommea958b982020-04-13 18:46:35 +0200319::
320
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200321 https://K8S_NODE_IP:30200/vid/welcome.htm
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200322
3232. In the left hand menu enter **Search for Existing Service Instances**
324
3253. Select proper subscriber from the list and press **Submit** button. When service instance of vFWDT Service Type appears Click on **View/Edit** link
326
327.. 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
328
3294. For each VNF in vFWDT service instance note its *vnf-id* and *vnf-type*
330
331.. figure:: files/vfwdt-vid-vpkg.png
332 :scale: 60 %
333 :align: center
334
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200335 Figure 12 vnf-type and vnf-id for vPKG VNF
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200336
337.. figure:: files/vfwdt-vid-vnf-1.png
338 :scale: 60 %
339 :align: center
340
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200341 Figure 13 vnf-type and vnf-id for vFW-SINK 1 VNF
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200342
343.. figure:: files/vfwdt-vid-vnf-2.png
344 :scale: 60 %
345 :align: center
346
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200347 Figure 14 vnf-type and vnf-id for vFW-SINK 2 VNF
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200348
349Gathering facts directly from A&AI
350~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
351
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02003521. Enter OpenStack dashboard on which 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
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200353
3542. Open Postman or any other REST client
355
3563. In Postman in General Settings disable *SSL Certificate verification*
357
3584. You can use also following Postman Collection for AAI :download:`AAI Postman Collection <files/vfwdt-aai-postman.json>`
359
3605. Alternatively create Collection and set its *Authorization* to *Basic Auth* type with login/password: AAI/AAI
361
3626. Create new GET query for *tenants* type with following link and read *tenant-id* value
363
364::
365
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200366 https://K8S_NODE_IP:30233/aai/v14/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200367
368.. note:: *CloudOwner* and *Region* names are fixed for default setup of ONAP
369
3707. 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
371
372::
373
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200374 https://K8S_NODE_IP:30233/aai/v14/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/RegionOne/tenants/tenant/<tenant-id>/vservers/?vserver-name=<vm-name>
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200375
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200376Read from the response (relationship with *generic-vnf* type) vnf-id of vPKG VNF
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200377
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200378.. note:: If you do not receive any vserver candidate it means that heatbridge procedure was not performed or was not completed successfully. It is mandatory to continue this tutorial
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200379
3808. Create new GET query for *generic-vnf* type with following link replacing <vnf-id> with value read from previous GET response
381
382::
383
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200384 https://K8S_NODE_IP:30233/aai/v14/network/generic-vnfs/generic-vnf/<vnf-id>
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200385
3869. Repeat this procedure also for 2 vFW VMs and note their *vnf-type* and *vnf-id*
387
388Configuration of ONAP Environment
389---------------------------------
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200390This 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
391
392Configuration of Policies for Optimization Framework
393~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200394We need to upload neccessary optimization policy rules required for the demo. The policies are required for the Optimization Framework and they guide OOF how to determine
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200395vFW and vPGN instances used in the Traffic Distribution workflow.
396
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +02003971. Push the policies into the PDP
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200398
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200399In order to push policies into the PDP it is required to execute already prepared *uploadPolicies.sh* script that prepares policy upload requests and automatically sends them to the Policy PDP pod
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200400
401::
402
403 root@sb01-rancher:~/demo/tutorials/vFWDT# ls policies/rules/
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200404 QueryPolicy_vFW_TD.json affinity_vFW_TD.json uploadPolicies.sh dt-policies.sh vnfPolicy_vFW_TD.json vnfPolicy_vPGN_TD.json
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200405
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200406When necessary, you can modify policy json files. Script will read these files and will build new PDP requests based on them. To create or update policies execute the script in the following way
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200407
408::
409
410 ./policies/rules/uploadPolicies.sh
411
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200412Testing Gathered Facts on Workflow Script
413~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
414
mrichommea958b982020-04-13 18:46:35 +0200415Having 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
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200416is 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.
417
418At this stage we will execute script in the initial mode to generate some configuration helpful in CDT and Ansible configuration.
419
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02004201. Enter vFWDT tutorial directory on Rancher server (already created in `Preparation of Workflow Script Environment`_). In the *workflow* folder you can find workflow script used to gather necessary configuration and responsible for execution of the LCM actions. It has following syntax
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200421
422::
423
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200424 python3 workflow.py <VNF-ID> <RANCHER_NODE_IP> <K8S_NODE_IP> <IF-CACHE> <IF-VFWCL> <INITIAL-ONLY> <CHECK-STATUS> <VERSION>
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200425
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200426- <VNF-ID> - vnf-id of vFW VNF instance that traffic should be migrated out from
427- <RANCHER_NODE_IP> - External IP of ONAP Rancher Node i.e. 10.12.5.160 (If Rancher Node is missing this is NFS node)
428- <K8S_NODE_IP> - External IP of ONAP K8s Worker Node i.e. 10.12.5.212
429- <IF-CACHE> - If script should use and build OOF response cache (cache it speed-ups further executions of script)
430- <IF-VFWCL> - If instead of vFWDT service instance vFW or vFWCL one is used (should be False always)
431- <INITIAL-ONLY> - If only configuration information will be collected (True for initial phase and False for full execution of workflow)
432- <CHECK-STATUS> - 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)
433- <VERSION> - New version of vFW - for tests '1.0' or '2.0'. Ignore when you want to test traffic distribution workflow
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200434
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02004352. Execute there workflow script with following parameters
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200436
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200437::
438
439 python3 workflow.py <VNF-ID> <RANCHER_NODE_IP> <K8S_NODE_IP> True False True True 2.0
440
4413. The script at this stage should give simmilar output
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200442
443::
444
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200445 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
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200446
447 OOF Cache True, is CL vFW False, only info False, check LCM result True
448
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200449 New vFW software version 2.0
450
451 Starting OSDF Response Server...
452
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200453 vFWDT Service Information:
454 {
455 "vf-module-id": "0dce0e61-9309-449a-8e3e-f001635aaab1",
456 "service-info": {
457 "global-customer-id": "DemoCust_ccc04407-1740-4359-b3c4-51bbcb62d9f6",
458 "service-type": "vFWDT",
459 "service-instance-id": "ab37d391-95c6-4844-b7c3-23d111bfa2ce"
460 },
461 "vfw-model-info": {
462 "model-version-id": "f7fc17ba-48b9-456b-acc1-f89f31eda8cc",
463 "vnf-type": "vFWDT 2019-05-20 21:10:/vFWDT_vFWSNK b463aa83-b1fc 0",
464 "model-invariant-id": "0dfe8d6d-21c1-42f6-867a-1867cebb7751",
465 "vnf-name": "Ete_vFWDTvFWSNK_ccc04407_1"
466 },
467 "vpgn-model-info": {
468 "model-version-id": "0f8a2467-af44-4d7c-ac55-a346dcad9e0e",
469 "vnf-type": "vFWDT 2019-05-20 21:10:/vFWDT_vPKG a646a255-9bee 0",
470 "model-invariant-id": "75e5ec48-f43e-40d2-9877-867cf182e3d0",
471 "vnf-name": "Ete_vFWDTvPKG_ccc04407_0"
472 }
473 }
474
475 Ansible Inventory:
476 [vpgn]
477 vofwl01pgn4407 ansible_ssh_host=10.0.210.103 ansible_ssh_user=ubuntu
478 [vfw-sink]
479 vofwl01vfw4407 ansible_ssh_host=10.0.110.1 ansible_ssh_user=ubuntu
480 vofwl02vfw4407 ansible_ssh_host=10.0.110.4 ansible_ssh_user=ubuntu
481
mrichommea958b982020-04-13 18:46:35 +0200482The 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.
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200483Ansible Inventory section contains information about the content Ansible Inventor file that will be configured later on `Configuration of Ansible Server`_. The first phase of the workflow script will generate also the CDT artifacts which can be used for automatic configuration of the CDT tool - they can be ignored for manual CDT configuration.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200484
485Configuration of VNF in the APPC CDT tool
486~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
487
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200488.. note:: Automated procedure can be found at the end of the section
489
mrichommee4643892020-11-30 18:31:29 +0100490Following steps aim to configure DistributeTraffic LCM action for our vPKG and vFW-SINK VNFs in APPC CDT tool.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200491
4921. Enter the Controller Design Tool portal
493
494::
495
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200496 https://K8S_NODE_IP:30289/index.html
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200497
4982. Click on *MY VNFS* button and login to CDT portal giving i.e. *demo* user name
499
5003. Click on the *CREATE NEW VNF TYPE* button
501
502.. figure:: files/vfwdt-create-vnf-type.png
503 :scale: 70 %
504 :align: center
505
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200506 Figure 15 Creation of new VNF type in CDT
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200507
5084. Enter previously retrieved VNF Type for vPKG VNF and press the *NEXT* button
509
510.. figure:: files/vfwdt-enter-vnf-type.png
511 :scale: 70 %
512 :align: center
513
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200514 Figure 16 Creation of new VNF type in CDT
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200515
5165. 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:
517
518- *DistributeTraffic* as Action name
519
520- *ANSIBLE* as Device Protocol
521
522- *Y* value in Template dropdown menu
523
524- *admin* as User Name
525
526- *8000* as Port Number
527
528
529.. figure:: files/vfwdt-new-lcm-ref-data.png
530 :scale: 70 %
531 :align: center
532
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200533 Figure 17 DistributeTraffic LCM action editing
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200534
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02005356. Go to the *Template* tab and in the editor paste the request template of LCM actions for vPKG VNF type
536
537For DistributeTraffic and DistributeTrafficCheck LCMs
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200538
539::
540
541 {
542 "InventoryNames": "VM",
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200543 "PlaybookName": "${book_name}",
544 "AutoNodeList": true,
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200545 "EnvParameters": {
546 "ConfigFileName": "../traffic_distribution_config.json",
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200547 "vnf_instance": "vfwdt"
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200548 },
549 "FileParameters": {
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200550 "traffic_distribution_config.json": "${file_parameter_content}"
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200551 },
552 "Timeout": 3600
553 }
554
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200555
556For DistributeTraffic and DistributeTrafficCheck LCMs
557
558::
559
560 {
561 "InventoryNames": "VM",
562 "PlaybookName": "${book_name}",
563 "AutoNodeList": true,
564 "EnvParameters": {
565 "ConfigFileName": "../config.json",
566 "vnf_instance": "vfwdt",
567 "new_software_version": "${new-software-version}",
568 "existing_software_version": "${existing-software-version}"
569 },
570 "FileParameters": {
571 "config.json": "${file_parameter_content}"
572 },
573 "Timeout": 3600
574 }
575
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200576
577The meaning of selected template parameters is following:
578
579- **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
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200580- **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* value means that NodeList will have information about VMs on which playbook should be executed. In this use case this is always only one VM
581- **AutoNodeList** parameter set to True indicates that template does not need the NodeList section specific and it will be generated automatically base on information from AAI - this requires proper data in the vserver and vnfc objects associated with VNFs
582- **PlaybookName** must be the same as the name of playbook that was uploaded before to the Ansible server.
583- **FileParameters** sections contains information about the configuration files with their content necessary to execute the playbook
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200584
585
586.. figure:: files/vfwdt-create-template.png
587 :scale: 70 %
588 :align: center
589
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200590 Figure 18 LCM DistributeTraffic request template
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200591
5927. Afterwards press the *SYNCHRONIZE WITH TEMPLATE PARAMETERS* button. You will be moved to the *Parameter Definition* tab. The new parameters will be listed there.
593
594.. figure:: files/vfwdt-template-parameters.png
595 :scale: 70 %
596 :align: center
597
Lukasz Rajewski1b6431d2020-04-29 18:19:38 +0200598 Figure 19 Summary of parameters specified for DistributeTraffic LCM action.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200599
600.. 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
601
6028. Finally, go back to the *Reference Data* tab and click *SAVE ALL TO APPC*.
603
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200604.. note:: Remember to configure DistributeTraffic and DistributeTrafficCheck actions for vPKG VNF type and UpgradeSoftware, UpgradePreCheck, UpgradePostCheck and DistributeTrafficCheck actions for vFW-SINK
605
6069. Configuration of CDT tool is also automated and all steps above can be repeated with script *configure_ansible.sh*
607
608Enter vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server, make sure that *onap.pem* file is in *playbooks* directory and run
609
610::
611
612 ./playbooks/configure_ansible.sh
Gary Wucd47a012018-11-30 07:18:36 -0800613
614Configuration of Ansible Server
615~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
616
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200617.. note:: Automated procedure can be found at the end of the section
618
Gary Wucd47a012018-11-30 07:18:36 -0800619After an instantiation of the vFWDT service the Ansible server must be configured in order to allow it a reconfiguration of vPKG VM.
620
Lukasz Rajewski80726d82019-06-04 13:47:17 +02006211. 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
Gary Wucd47a012018-11-30 07:18:36 -0800622
623::
624
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200625 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/
Gary Wucd47a012018-11-30 07:18:36 -0800626
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200627.. note:: The private key file must be the same like configured at this stage `vFWDT Service Instantiation`_
628
6292. Enter the Rancher server and then enter the APPC Ansible server container
Gary Wucd47a012018-11-30 07:18:36 -0800630
631::
632
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200633 kubectl exec -it -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-ansible` -- sh
Gary Wucd47a012018-11-30 07:18:36 -0800634
Lukasz Rajewski80726d82019-06-04 13:47:17 +02006353. Give the private key file a proper access rights
Gary Wucd47a012018-11-30 07:18:36 -0800636
637::
638
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200639 cd /opt/ansible-server/Playbooks/
640 chmod 400 onap.pem
641 chown ansible:ansible onap.pem
Gary Wucd47a012018-11-30 07:18:36 -0800642
mrichommea958b982020-04-13 18:46:35 +02006434. Edit the :file:`/opt/ansible-server/Playbooks/Ansible\ \_\ inventory` file including all the hosts of vFWDT service instance used in this use case.
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200644 The content of the file is generated by workflow script `Testing Gathered Facts on Workflow Script`_
Gary Wucd47a012018-11-30 07:18:36 -0800645
646::
647
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200648 [vpgn]
649 vofwl01pgn4407 ansible_ssh_host=10.0.210.103 ansible_ssh_user=ubuntu
650 [vfw-sink]
651 vofwl01vfw4407 ansible_ssh_host=10.0.110.1 ansible_ssh_user=ubuntu
652 vofwl02vfw4407 ansible_ssh_host=10.0.110.4 ansible_ssh_user=ubuntu
Gary Wucd47a012018-11-30 07:18:36 -0800653
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200654.. 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
Gary Wucd47a012018-11-30 07:18:36 -0800655
Lukasz Rajewski80726d82019-06-04 13:47:17 +02006565. Configure the default private key file used by Ansible server to access hosts over ssh
Gary Wucd47a012018-11-30 07:18:36 -0800657
658::
659
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200660 vi /etc/ansible/ansible.cfg
Gary Wucd47a012018-11-30 07:18:36 -0800661
662::
663
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200664 [defaults]
665 host_key_checking = False
666 private_key_file = /opt/ansible-server/Playbooks/onap.pem
Gary Wucd47a012018-11-30 07:18:36 -0800667
Gary Wucd47a012018-11-30 07:18:36 -0800668
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200669.. note:: This is the default private key file. In the `/opt/ansible-server/Playbooks/Ansible\ \_\ inventory` different key could be configured but APPC in time of execution of playbook 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
Gary Wucd47a012018-11-30 07:18:36 -0800670
Gary Wucd47a012018-11-30 07:18:36 -0800671
mrichommea958b982020-04-13 18:46:35 +02006726. Test that the Ansible server can access over ssh vFWDT hosts configured in the ansible inventory
Gary Wucd47a012018-11-30 07:18:36 -0800673
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200674::
675
676 ansible –i Ansible_inventory vpgn,vfw-sink –m ping
677
678
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02006797. Download the LCM playbooks into the :file:`/opt/ansible-server/Playbooks` directory
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200680
681Exit Ansible server pod and enter vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server. Afterwards, copy playbooks into Ansible server pod
682
683::
684
685 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/
686 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/
687
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02006888. Configuration of ansible server is also automated and all steps above can be repeated with script *configure_ansible.sh* introduced in the previous section
689
6909. After the configuration of Ansible server with script the structure of `/opt/ansible-server/Playbooks` directory should be following
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200691
692::
693
694 /opt/ansible-server/Playbooks $ ls -R
695 .:
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200696 ansible.cfg Ansible_inventory configure_ansible.sh onap.pem server.py upgrade.sh vfw-sink vpgn
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200697
698 ./vfw-sink:
699 latest
700
701 ./vfw-sink/latest:
702 ansible
703
704 ./vfw-sink/latest/ansible:
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200705 distributetrafficcheck upgradepostcheck upgradeprecheck upgradesoftware
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200706
707 ./vfw-sink/latest/ansible/distributetrafficcheck:
708 site.yml
709
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200710 ./vfw-sink/latest/ansible/upgradepostcheck:
711 site.yml
712
713 ./vfw-sink/latest/ansible/upgradeprecheck:
714 site.yml
715
716 ./vfw-sink/latest/ansible/upgradesoftware:
717 site.yml
718
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200719 ./vpgn:
720 latest
721
722 ./vpgn/latest:
723 ansible
724
725 ./vpgn/latest/ansible:
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200726 distributetraffic distributetrafficcheck
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200727
728 ./vpgn/latest/ansible/distributetraffic:
729 site.yml
730
731 ./vpgn/latest/ansible/distributetrafficcheck:
732 site.yml
733
734
735Configuration of APPC DB for Ansible
736~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
737
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200738.. note:: Automated procedure can be found at the end of the section
739
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200740For 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.
741
Lukasz Rajewski61a35bc2020-05-14 11:08:43 +02007421. Read APPC DB password
743
744Enter vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server.
745
746::
747
748 ./get_secret.sh `kubectl get secrets | grep appc-db-root-pass`
749
7502. Enter the APPC DB container
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200751
752::
753
754 kubectl exec -it -n onap `kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep appc-db-0` -- sh
755
Lukasz Rajewski61a35bc2020-05-14 11:08:43 +02007563. Enter the APPC DB CLI
Gary Wucd47a012018-11-30 07:18:36 -0800757
758::
759
Lukasz Rajewski61a35bc2020-05-14 11:08:43 +0200760 mysql -u root -p
Gary Wucd47a012018-11-30 07:18:36 -0800761
Lukasz Rajewski61a35bc2020-05-14 11:08:43 +02007624. Execute the following SQL commands
Gary Wucd47a012018-11-30 07:18:36 -0800763
764::
765
766 MariaDB [(none)]> use sdnctl;
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200767 MariaDB [sdnctl]> UPDATE DEVICE_AUTHENTICATION SET URL = 'http://appc-ansible-server:8000/Dispatch' WHERE WHERE PROTOCOL LIKE 'ANSIBLE' AND URL IS NULL;
768 MariaDB [sdnctl]> UPDATE DEVICE_AUTHENTICATION SET PASSWORD = 'admin' WHERE PROTOCOL LIKE 'ANSIBLE' AND PASSWORD IS NULL;
769 MariaDB [sdnctl]> select * from DEVICE_AUTHENTICATION WHERE PROTOCOL LIKE 'ANSIBLE';
Gary Wucd47a012018-11-30 07:18:36 -0800770
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200771Result should be similar to the following one:
Gary Wucd47a012018-11-30 07:18:36 -0800772
773::
774
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200775 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
776 | DEVICE_AUTHENTICATION_ID | VNF_TYPE | PROTOCOL | ACTION | USER_NAME | PASSWORD | PORT_NUMBER | URL |
777 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200778 | 118 | vFWDT 2020-04-21 17-26-/vFWDT_vFWSNK 1faca5b5-4c29 1 | ANSIBLE | DistributeTrafficCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
779 | 121 | vFWDT 2020-04-21 17-26-/vFWDT_vFWSNK 1faca5b5-4c29 1 | ANSIBLE | UpgradeSoftware | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
780 | 124 | vFWDT 2020-04-21 17-26-/vFWDT_vFWSNK 1faca5b5-4c29 1 | ANSIBLE | UpgradePreCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
781 | 127 | vFWDT 2020-04-21 17-26-/vFWDT_vFWSNK 1faca5b5-4c29 1 | ANSIBLE | UpgradePostCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
782 | 133 | vFWDT 2020-04-21 17-26-/vFWDT_vPKG 8021eee9-3a8f 0 | ANSIBLE | DistributeTraffic | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
783 | 136 | vFWDT 2020-04-21 17-26-/vFWDT_vPKG 8021eee9-3a8f 0 | ANSIBLE | DistributeTrafficCheck | admin | admin | 8000 | http://appc-ansible-server:8000/Dispatch |
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200784 +--------------------------+------------------------------------------------------+----------+------------------------+-----------+----------+-------------+------------------------------------------+
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200785
786 6 rows in set (0.00 sec)
787
7884. Configuration of APPC DB is also automated and all steps above can be repeated with script *configure_ansible.sh* introduced in the previous sections
Gary Wucd47a012018-11-30 07:18:36 -0800789
Gary Wucd47a012018-11-30 07:18:36 -0800790
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200791Testing Workflows
792-----------------
Gary Wucd47a012018-11-30 07:18:36 -0800793
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200794Since all the configuration of components of ONAP is already prepared it is possible to enter second phase of workflows execution -
795the execution of APPC LCM actions with configuration resolved before by OptimizationFramework.
Gary Wucd47a012018-11-30 07:18:36 -0800796
Gary Wucd47a012018-11-30 07:18:36 -0800797
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200798Workflow Execution
799~~~~~~~~~~~~~~~~~~
Gary Wucd47a012018-11-30 07:18:36 -0800800
mrichommee4643892020-11-30 18:31:29 +0100801In order to run workflows execute following commands from the vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server.
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200802
803For Traffic Distribution workflow run
Gary Wucd47a012018-11-30 07:18:36 -0800804
805::
806
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200807 cd workflow
Lukasz Rajewski048e0892019-09-12 09:03:47 +0200808 python3 workflow.py 909d396b-4d99-4c6a-a59b-abe948873303 10.12.5.217 10.12.5.63 True False False True
Gary Wucd47a012018-11-30 07:18:36 -0800809
Gary Wucd47a012018-11-30 07:18:36 -0800810
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200811The order of executed LCM actions for Traffic Distribution workflow is following:
Gary Wucd47a012018-11-30 07:18:36 -0800812
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +02008131. CheckLock on vPKG, vFW-1 and vFW-2 VMs
8142. Lock on vPKG, vFW-1 and vFW-2 VMs
8153. DistributeTrafficCheck on vPKG VM - ansible playbook checks if traffic destinations specified by OOF is not configured in the vPKG and traffic does not go from vPKG already.
816 If vPKG send already traffic to destination the playbook will fail and workflow will break.
8174. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF.
8185. 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
8196. 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
8207. Lock on vPKG, vFW-1 and vFW-2 VMs
821
822
823For In-Place Software Upgrade with Traffic Distribution workflow run
824
825::
826
827 cd workflow
828 python3 workflow.py 909d396b-4d99-4c6a-a59b-abe948873303 10.12.5.217 10.12.5.63 True False False True 2.0
829
830
831The order of executed LCM actions for In-Place Software Upgrade with Traffic Distribution workflow is following:
832
8331. CheckLock on vPKG, vFW-1 and vFW-2 VMs
8342. Lock on vPKG, vFW-1 and vFW-2 VMs
8353. UpgradePreCheck on vFW-1 VM - checks if the software version on vFW is different than the one requested in the workflow input
8364. DistributeTrafficCheck on vPKG VM - ansible playbook checks if traffic destinations specified by OOF is not configured in the vPKG and traffic does not go from vPKG already.
837 If vPKG send already traffic to destination the playbook will fail and workflow will break.
8385. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF.
8396. 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
8407. 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
mrichommee4643892020-11-30 18:31:29 +01008418. UpgradeSoftware on vFW-1 VM - ansible playbook modifies the software on the vFW instance and sets the version of the software to the specified one in the request
8429. UpgradePostCheck on vFW-1 VM - ansible playbook checks if the software of vFW is the same like the one specified in the workflows input.
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +020084310. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF (reverse configuration).
84411. DistributeTrafficCheck on vFW-2 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
84512. DistributeTrafficCheck on vFW-1 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
84613. Unlock on vPKG, vFW-1 and vFW-2 VMs
847
848
849For both workflows when everything is fine with both workflows change of the traffic should be observed on following dashboards (please turn on automatic reload of graphs). The observed traffic pattern for upgrade scenario should be similar to the one presented in Figure 2
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200850
851 ::
mrichommea958b982020-04-13 18:46:35 +0200852
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200853 http://vSINK-1-IP:667/
854 http://vSINK-2-IP:667/
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200855
856Workflow Results
857~~~~~~~~~~~~~~~~
858
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200859Expected result of Traffic Distribution workflow execution, when everything is fine, is following:
Gary Wucd47a012018-11-30 07:18:36 -0800860
861::
862
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200863 Distribute Traffic Workflow Execution:
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200864 WORKFLOW << Migrate vFW Traffic Conditionally >>
865 APPC LCM << CheckLock >> [Check vPGN Lock Status]
866 UNLOCKED
867 APPC LCM << CheckLock >> [Check vFW-1 Lock Status]
868 UNLOCKED
869 APPC LCM << CheckLock >> [Check vFW-2 Lock ]
870 UNLOCKED
871 APPC LCM << Lock >> [Lock vPGN]
872 SUCCESSFUL
873 APPC LCM << Lock >> [Lock vFW-1]
874 SUCCESSFUL
875 APPC LCM << Lock >> [Lock vFW-2]
876 SUCCESSFUL
877 APPC LCM << DistributeTrafficCheck >> [Check current traffic destination on vPGN]
878 ACCEPTED
879 APPC LCM << DistributeTrafficCheck >> [Status]
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200880 IN_PROGRESS
881 IN_PROGRESS
882 IN_PROGRESS
883 SUCCESSFUL
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200884 WORKFLOW << Migrate Traffic and Verify >>
885 APPC LCM << DistributeTraffic >> [Migrating source vFW traffic to destination vFW]
886 ACCEPTED
887 APPC LCM << DistributeTraffic >> [Status]
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200888 IN_PROGRESS
889 IN_PROGRESS
890 IN_PROGRESS
891 IN_PROGRESS
892 IN_PROGRESS
893 IN_PROGRESS
894 IN_PROGRESS
895 IN_PROGRESS
896 SUCCESSFUL
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200897 APPC LCM << DistributeTrafficCheck >> [Checking traffic has been stopped on the source vFW]
898 ACCEPTED
899 APPC LCM << DistributeTrafficCheck >> [Status]
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200900 IN_PROGRESS
901 IN_PROGRESS
902 IN_PROGRESS
903 SUCCESSFUL
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200904 APPC LCM << DistributeTrafficCheck >> [Checking traffic has appeared on the destination vFW]
905 ACCEPTED
906 APPC LCM << DistributeTrafficCheck >> [Status]
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200907 IN_PROGRESS
908 IN_PROGRESS
909 SUCCESSFUL
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200910 APPC LCM << Unlock >> [Unlock vPGN]
911 SUCCESSFUL
912 APPC LCM << Unlock >> [Unlock vFW-1]
913 SUCCESSFUL
914 APPC LCM << Unlock >> [Unlock vFW-2]
915 SUCCESSFUL
916
917
918In case we want to execute operation and one of the VNFs is locked because of other operation being executed:
919
920::
921
922 Distribute Traffic Workflow Execution:
923 WORKFLOW << Migrate vFW Traffic Conditionally >>
924 APPC LCM << CheckLock >> [Check vPGN Lock Status]
925 LOCKED
926 Traceback (most recent call last):
927 File "workflow.py", line 1235, in <module>
928 sys.argv[6].lower() == 'true', sys.argv[7].lower() == 'true', new_version)
929 File "workflow.py", line 1209, in execute_workflow
930 _execute_lcm_requests({"requests": lcm_requests, "description": "Migrate vFW Traffic Conditionally"}, onap_ip, check_result)
931 File "workflow.py", line 101, in wrap
932 ret = f(*args, **kwargs)
933 File "workflow.py", line 1007, in _execute_lcm_requests
934 raise Exception("APPC LCM << {} >> FAILED".format(req['input']['action']))
935 Exception: APPC LCM << CheckLock >> FAILED
936
Gary Wucd47a012018-11-30 07:18:36 -0800937
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200938In case of failure the result can be following:
Gary Wucd47a012018-11-30 07:18:36 -0800939
940::
941
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200942 Distribute Traffic Workflow Execution:
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200943 WORKFLOW << Migrate vFW Traffic Conditionally >>
944 APPC LCM << CheckLock >> [Check vPGN Lock Status]
945 UNLOCKED
946 APPC LCM << CheckLock >> [Check vFW-1 Lock Status]
947 UNLOCKED
948 APPC LCM << CheckLock >> [Check vFW-2 Lock ]
949 UNLOCKED
950 APPC LCM << Lock >> [Lock vPGN]
951 SUCCESSFUL
952 APPC LCM << Lock >> [Lock vFW-1]
953 SUCCESSFUL
954 APPC LCM << Lock >> [Lock vFW-2]
955 SUCCESSFUL
956 APPC LCM << DistributeTrafficCheck >> [Check current traffic destination on vPGN]
957 ACCEPTED
958 APPC LCM << DistributeTrafficCheck >> [Status]
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200959 FAILED
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200960 APPC LCM <<DistributeTrafficCheck>> [FAILED - FAILED]
961 WORKFLOW << Migrate Traffic and Verify >> SKIP
962 APPC LCM << Unlock >> [Unlock vPGN]
963 SUCCESSFUL
964 APPC LCM << Unlock >> [Unlock vFW-1]
965 SUCCESSFUL
966 APPC LCM << Unlock >> [Unlock vFW-2]
967 SUCCESSFUL
Lukasz Rajewski80726d82019-06-04 13:47:17 +0200968
Lukasz Rajewskib98b27d2020-04-27 21:30:24 +0200969
970.. 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 succeeds.