"Using Onap" section content and structure changed to reflect content and structure of the wiki

Fixed missing CLI section
Issue-ID: DOC-450

Change-Id: I2ad3f57e854e9e64023887fa54656d8f01bf87e0
Signed-off-by: thmsdt <thomas.kulik@telekom.de>

1 files changed, 126 insertions, 0 deletions

diff --git a/docs/guides/onap-user/design/pre-onboarding/index.rst b/docs/guides/onap-user/design/pre-onboarding/index.rst
new file mode 100644
index 000000000..155ec56fb
--- /dev/null
+++ b/docs/guides/onap-user/design/pre-onboarding/index.rst
@@ -0,0 +1,126 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2019 ONAP Contributors. All rights reserved.
+
+Pre-Onboarding
+==============
+
+    * `Create a Tenant`_
+    * `Validate VFs (Virtual Functions)`_
+    * `Generate Manifest and Package Artifacts`_
+
+Create a Tenant
+---------------
+
+Each service requires a tenant_ (a group of users who share a common access)
+in which resources are stored in the cloud. This process is performed using
+facilities of the network cloud, outside of ONAP. Confirm that the tenant is
+created and note the tenant ID.
+
+ONAP admin users can configure a cloud-owner to add new cloud resources.
+These are the computing and networking resources, that will support
+running VNFs. A cloud-owner holds a keystone URL, login, region and
+password, in the case of an Openstack cluster. A cloud-owner also
+belongs to a region. The region name should be the same as the Openstack
+region. Prior to creation of a cloud-owner, its region must be created
+first. Multiple tenants can share the same cloud-owner. Note that these
+tenants are ONAP tenants, not Openstack tenants. Tenant register
+services that customers are allowed to deploy. Finally, the customer is
+like an instance of the tenant.
+
+Note: there is no GUI (yet) to configure these objects. REST requests
+are sent to AAI to achieve the configuration. For a detailed list of
+required REST commands see:
+
+https://wiki.onap.org/display/DW/running+vFW+Demo+on+ONAP+Amsterdam+Release
+
+The overall process is as follows:
+
+ #. Create a region and a cloud-owner. This steps registers Openstack
+    credentials. This is the only step requiring entering Openstack specific
+    parameters.
+
+ #. Create a complex. The complex describes the coverage of the region with
+    a street address etc.
+
+ #. Create a service. The service name should match the name of the service
+    onboarded in SDC.
+
+ #. Create a tenant. Tenant in ONAP stores a design for a generic customer.
+
+ #. Associate tenants with their allowed services.
+
+ #. Create an instance of the tenant or customer. The customer is visible in
+    VID. A VID user can deploy allowed services on this new customer.
+
+   |image1|
+
+
+Validate VFs (Virtual Functions)
+--------------------------------
+
+Prior to resource onboarding, the Certification Group does the following:
+
+ - onboards the Heat template(s) and metadata to the SDC catalog
+ - creates a test VF
+ - runs the Heat scanning tools
+ - shares the results with any group that approves Virtual Functions
+
+In parallel, the Certification Group onboards the VF Image and OS to a
+standalone ONAP instance (the "sandbox") and performs the following:
+
+ - security scan
+ - compatibility test for the OS and vendor binary
+ - malware scan
+
+The Certification group then instantiates the VF image using the vendor
+Heat (if provided) in order to validate that the VM can run on the Network
+Cloud.
+
+No VF functionality testing is performed at this stage.
+
+
+Generate Manifest and Package Artifacts
+---------------------------------------
+
+Before onboarding resources, run generate-manifest.py to generate a
+MANIFEST file. These steps are performed outside SDC.
+
+OBSOLETE: **Prerequisites:** Obtain Heat/ENV files and other files required for
+onboarding. See the reference document `VNF Heat Template Requirements
+for OpenECOMP <https://wiki.onap.org/download/attachments/1015849/VNF%20Heat%20Template%20Requirements%20for%20OpenECOMP.pdf?version=2&modificationDate=1487262292000&api=v2>`__ for details.
+
+UPDATE: see VNF Modeling Requirements / HEAT: https://onap.readthedocs.io/en/casablanca/submodules/vnfrqts/requirements.git/docs/Chapter5/Heat/index.html
+
+#. Put the Heat, ENV, nested Heat, and other files used by get-file in templates
+   in a directory.
+
+   Naming guidelines:
+
+    - The base Heat should include "base" in the name.
+    - The ENV file name should match the name of the Heat file with which it
+      is associated.
+    - All get-file file names need to be unique.
+
+#. Put the python script in a directory one level above the directory that
+   contains the Heat/ENV and other files.
+
+   For example, [dir x]/[dir y]
+
+    - [dir y] contains the Heat/ENV files and other files
+    - [dir x] contains the python script
+
+#. Run the script on the Windows command line:
+
+   .. code-block::
+
+    python generate-manifest.py -f "dir y"
+
+#. Examine the manifest file and confirm that is correct.
+
+#. Package all Heat/ENV files, all other files, and the MANIFEST.json
+   into one .zip file.
+
+
+.. |image1| image:: media/tenant.png
+.. _tenant: https://wiki.onap.org/display/DW/Glossary#Glossary-tenant