summaryrefslogtreecommitdiffstats
path: root/docs/OnboardInstantiateTests.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/OnboardInstantiateTests.rst')
-rw-r--r--docs/OnboardInstantiateTests.rst157
1 files changed, 154 insertions, 3 deletions
diff --git a/docs/OnboardInstantiateTests.rst b/docs/OnboardInstantiateTests.rst
index abe5e29..0377ad1 100644
--- a/docs/OnboardInstantiateTests.rst
+++ b/docs/OnboardInstantiateTests.rst
@@ -228,7 +228,158 @@ 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::
+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 TOSCA 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.
+* All instantiations will use the ONAP Generic Resource API from VFC instead
+ of the legacy VNF API.
+
+
+Prerequisites
+^^^^^^^^^^^^^
+
+* **VNF Provider** has:
+
+ * Provided the **Tester** the VNF package containing OpenStack TOSCA that has
+ been certified compliant by the OPNFV Verification Program for
+ VNFs or validated by the El Alto release of the ONAP VNFSDK
+ * 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 TOSCA 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. Register VIM and VNFM to ONAP environment through ESR.
+
+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 TOSCA 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 SDC. The VF will be
+ auto-assigned a unique name to avoid collisions with other VSPs in the
+ lab environment.
+
+9. Add original VNF CSAR as artifacts to VF.
+
+10. Assign nf_type property with required VNFM driver.
+
+11. Certify VF model
+
+12. Create the Service in SDC. The Service will be
+ auto-assigned a unique name to avoid collisions with other VSPs in the
+ lab environment.
+
+13. Assign the VF/VNF to the Service Model in SDC.
+
+14. Attach original NS CSAR with service model.
+
+15. Test the Service model in SDC.
+
+16. Approve the Service model in SDC.
+
+17. Distribute the Service Model from SDC.
+
+18. Onboard VNF CSAR from SDC to VFC Catalog.
+
+19. Onboard Service CSAR from SDC to VFC Catalog.
+
+20. Call VFC NSLCM Create API to create service instance.
+
+21. Call VFC NSLCM Instantiate API to instantiate service.
+
+**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 virtual machine has been successfully created in OpenStack without errors.
+
+2. If the VNF exposes Operations, Administration, and Management (OAM)
+ interfaces on an OAM network, then each IP address address exposed by the
+ VNF on the OAM network must respond to a PING command. The identification
+ of the OAM network and IPs is left to the implementation and documentation
+ of the **Test Engine**.
+
+3. Each virtual machine in the OpenStack must have a corresponding
+ ``vserver`` ONAP's Available and Active Inventory (AAI) component with all
+ required data elements.
+
+4. The VNF has a ``Generic-VNF`` object recorded in AAI with all required data elements.
- Additional definition of the TOSCA-based flow is required, and will be
- provided at a later date.