Update Tosca VNF test case description

Issue-ID: VNFSDK-451

Change-Id: I38fb6da9257282254297db06d6089c127b7f26fd
Signed-off-by: guochuyicmri <guochuyi@chinamobile.com>

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.