1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
.. Modifications Copyright © 2019 AT&T Intellectual Property.
.. Licensed under the Creative Commons License, Attribution 4.0 Intl.
(the "License"); you may not use this documentation except in compliance
with the License. You may obtain a copy of the License at
.. https://creativecommons.org/licenses/by/4.0/
.. Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
VNF Onboard and Instantiate Test Specification
==============================================
.. contents::
:local:
Scope
-----
This specification defines the logical steps and activities required
to implement a test case that validates that a arbitrary
Virtual Network Function (VNF) that is packaged in compliance with the
ONAP VNF Requirements can be successfully be onboarded into
ONAP and instantiated. This specification only covers up to
instantiation of the VNF and does not address the VNF's compliance with
requirements governing other lifecycle functions controlled by
ONAP (ex: Lifecycle Management, Monitoring, etc.)
Two test cases will be defined based on the VNF package used:
1. ZIP file containing ONAP-compliant OpenStack Heat
2. Cloud Service Archive (CSAR) containing a Topology and Orchestration
Specification for Cloud Applications (TOSCA) VNF Descriptor
.. _vnfrqts_tc_instantiate_references:
References
----------
* :doc:`ONAP VNF Requirements </../../../vnfrqts/requirements.git/docs/index>`
* :doc:`Setting up ONAP </../../../../../guides/onap-developer/settingup/index>`
* `OPNFV Verification Program for VNFs <https://vnf-verified.lfnetworking.org/#/>`__
Actors
------
The following defines the various actors that will be referenced within this
specification. It is expected and permissable that a given user or entity
can serve in multiple roles for the purposes of the test.
* **VNF Provider** - Responsible for developing, packaging, and distributing a
VNF that is compliant with ONAP VNF Requirements as well as providing any
additional artifacts required to setup the **Test Lab** or **Test Engine**.
* **Test Lab** - Hosts the ONAP and Cloud environment used to execute the test
cases. The environment will host a deployed instance of ONAP using the
official El Alto release of ONAP and a compatible OpenStack cloud instance.
* **Test Lab Provider** - Responsible for establishing the **Test Lab** and
supporting the **Tester** in the configuration of the **Test Lab** for any
VNF specific requirements such as virtual machine images or networks. This
will include providing the **Test Engine** access to the necessary
ONAP APIs/GUIs as well as access to the OpenStack APIs.
* **Tester** - Responsible for:
1. Ensuring the test lab is configured per the VNF's requirements and needs.
2. Configuring the **Test Engine** for execution. The artifacts required
will be provided by the **VNF Provider**.
3. Executing the the test cases using the **Test Engine**.
4. Reporting the results of the test case to the **VNF Provider**.
* **Test Engine** - Provides automation of the test execution and verification
of the success or failure of the individual test cases. The **Test Engine**
must also provide further documentation on how it and the **Test Lab**
must be configured for successful execution and verification of the test
cases.
Test Case Description: VNF Onboarding and Instantiation using OpenStack Heat
----------------------------------------------------------------------------
This test case is specific to executing and validating the onboarding of a VNF
using OpenStack Heat.
Assumptions
^^^^^^^^^^^
* The specific configuration of the Vendor License Model is not relevant to the
successful execution of this test case. The **Test Engine** shall create a
generic Vendor License Model to assign to the VNF for the purposes of this
test.
* Testing will support the instantiation of a SDC Service that is composed
of a single VNF. The scope of this test is focused on the instantiation
of a single VNF defined in a single Heat package. Testing services that
comprise multiple VNFs is beyond the scope of this specification.
* The **Test Engine** will have access to the ONAP APIs in terms of both
network connectivity and API access.
* VNF Instantiation for either ONAP legacy VNF API or Generic Resource API is
supported.
Prerequisites
^^^^^^^^^^^^^
* **VNF Provider** has:
* Provided the **Tester** the VNF package containing OpenStack Heat that has
been certified compliant by the OPNFV Verification Program for
VNFs or validated by the El Alto release of the
:doc:`ONAP VNF Validation Platform </../../../../vvp/documentation.git/docs/index>`
* Provided the **Tester** any custom virtual machine image required by the
VNF
* Provided the **Tester** network requirements for any ONAP external networks
(i.e. networks not created in the Heat template itself) required by the
VNF.
* Provided the **Tester** with any additional artifacts required by the
**Test Engine**. Additional artifacts required by the **Test Engine** are
outside the scope of this document. Please refer to the **Test Engine**
documentation for more details.
* **Test Lab Provider** has:
* Successfully deployed an OpenStack cloud instance for ONAP to deploy and
instantiate the VNF.
* Successfully deployed the certified El Alto release version of ONAP.
* Configured the ONAP instance to work with the OpenStack instance.
* **NOTE:** Documentation of OpenStack and ONAP setup are beyond the
scope of this document. Please refer to the
:ref:`vnfrqts_tc_instantiate_references` section for more information.
* Provided the **Test Engine** network connectivity to both the ONAP and
OpenStack control planes.
* Provided the **Test Engine** permissions to invoke the required ONAP and
OpenStack APIs. Full details to be provided in the **Test Engine**
documentation.
* The **Tester** has:
* Created any external networks in ONAP and OpenStack cloud environment in
compliance with the **VNF Providers** request and specification.
* Registered any custom virtual machine images provided by the
**VNF Provider** in the OpenStack Glance repository.
* Configured the **Test Engine** with the necessary artifacts from the
**VNF Provider** for successful test execution. The **Test Engine**
must provide the full documentation on what is required to configure
it for successful execution.
* Ensured connectivity from the **Test Engine** to any Operations,
Administration, and Management (OAM) interfaces provided by the VNF.
This connectivity must allow PING requests which will be used as part
of the validation process to ensure the VNF has been properly
instantiated.
Execution Steps
^^^^^^^^^^^^^^^
The following steps will all be executed by the **Test Engine**. The steps
depicts the actions that will be taken and which ONAP component the
**Test Engine** will interact with to perform the action.
Failure encountered at any step will halt all subsequent steps and result in
the overall failure of the test case.
Any additional required fields that must be assigned or input within ONAP will
be defined in a configuration file whose format will be defined in the
documentation of the **Test Engine**.
**Steps**
1. Execute VVP validation scripts to ensure VNF Heat Templates are compliant
with the VNF Heat Template Requirements.
2. Create the generic Vendor License Model (VLM) in SDC
3. Create the Vendor Software Product (VSP) in SDC. The VSP will be
auto-assigned a unique name to avoid collisions with other VSPs in the
lab environment.
4. Upload the ONAP-compliant Heat archive (zip file) as an artifact of the VSP in SDC.
5. Assign any "Unassigned Files" in SDC to Artifacts
6. Validate the VSP and ensure no SDC **errors** are raised, but **warnings**
are acceptable. If errors are reported, then halt the test and report a
failure.
7. Assign the generic VLM to the VSP in SDC.
8. Create the Virtual Function (VF) in SD. The VF will be
auto-assigned a unique name to avoid collisions with other VSPs in the
lab environment.
9. Create the Service in SDC. The Service will be
auto-assigned a unique name to avoid collisions with other VSPs in the
lab environment.
10. Assign the VF/VNF to the Service Model in SDC.
11. Distribute the Service Model from SDC.
12. Register Preload (i.e. per instance configuration data) with SDNC
13. For each VF module in the VNF, starting with the base module, trigger
instantiation from VID.
14. After VNF Instantiation, query openstack for heat stack details to
validate successful instantiation.
**Pass/Fail Criteria**
Following, or during, test execution the tests below will be executed to
evaluate the success of the overall test case. As previously stated above, if
any individual test step fails, then the test case will fail.
1. The Heat stack has been successfully created in OpenStack without errors
2. The Heat stack configuration matches the definition from the associated
Heat templates and environment settings provided as input (or derived by)
the **Test Engine**
Test Case Description: VNF Onboarding and Instantiation using TOSCA
-------------------------------------------------------------------
This test case is specific to executing and validating the onboarding of a VNF
written in TOSCA and packaged in a CSAR.
.. note::
Additional definition of the TOSCA-based flow is required, and will be
provided at a later date.
|
