diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/OnboardInstantiateTests.rst | 157 |
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. |