thmsdt | 9803c16 | 2019-04-25 08:16:14 +0200 | [diff] [blame^] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 |
| 2 | .. International License. http://creativecommons.org/licenses/by/4.0 |
| 3 | .. Copyright 2019 ONAP Contributors. All rights reserved. |
| 4 | |
| 5 | Pre-Onboarding |
| 6 | ============== |
| 7 | |
| 8 | * `Create a Tenant`_ |
| 9 | * `Validate VFs (Virtual Functions)`_ |
| 10 | * `Generate Manifest and Package Artifacts`_ |
| 11 | |
| 12 | Create a Tenant |
| 13 | --------------- |
| 14 | |
| 15 | Each service requires a tenant_ (a group of users who share a common access) |
| 16 | in which resources are stored in the cloud. This process is performed using |
| 17 | facilities of the network cloud, outside of ONAP. Confirm that the tenant is |
| 18 | created and note the tenant ID. |
| 19 | |
| 20 | ONAP admin users can configure a cloud-owner to add new cloud resources. |
| 21 | These are the computing and networking resources, that will support |
| 22 | running VNFs. A cloud-owner holds a keystone URL, login, region and |
| 23 | password, in the case of an Openstack cluster. A cloud-owner also |
| 24 | belongs to a region. The region name should be the same as the Openstack |
| 25 | region. Prior to creation of a cloud-owner, its region must be created |
| 26 | first. Multiple tenants can share the same cloud-owner. Note that these |
| 27 | tenants are ONAP tenants, not Openstack tenants. Tenant register |
| 28 | services that customers are allowed to deploy. Finally, the customer is |
| 29 | like an instance of the tenant. |
| 30 | |
| 31 | Note: there is no GUI (yet) to configure these objects. REST requests |
| 32 | are sent to AAI to achieve the configuration. For a detailed list of |
| 33 | required REST commands see: |
| 34 | |
| 35 | https://wiki.onap.org/display/DW/running+vFW+Demo+on+ONAP+Amsterdam+Release |
| 36 | |
| 37 | The overall process is as follows: |
| 38 | |
| 39 | #. Create a region and a cloud-owner. This steps registers Openstack |
| 40 | credentials. This is the only step requiring entering Openstack specific |
| 41 | parameters. |
| 42 | |
| 43 | #. Create a complex. The complex describes the coverage of the region with |
| 44 | a street address etc. |
| 45 | |
| 46 | #. Create a service. The service name should match the name of the service |
| 47 | onboarded in SDC. |
| 48 | |
| 49 | #. Create a tenant. Tenant in ONAP stores a design for a generic customer. |
| 50 | |
| 51 | #. Associate tenants with their allowed services. |
| 52 | |
| 53 | #. Create an instance of the tenant or customer. The customer is visible in |
| 54 | VID. A VID user can deploy allowed services on this new customer. |
| 55 | |
| 56 | |image1| |
| 57 | |
| 58 | |
| 59 | Validate VFs (Virtual Functions) |
| 60 | -------------------------------- |
| 61 | |
| 62 | Prior to resource onboarding, the Certification Group does the following: |
| 63 | |
| 64 | - onboards the Heat template(s) and metadata to the SDC catalog |
| 65 | - creates a test VF |
| 66 | - runs the Heat scanning tools |
| 67 | - shares the results with any group that approves Virtual Functions |
| 68 | |
| 69 | In parallel, the Certification Group onboards the VF Image and OS to a |
| 70 | standalone ONAP instance (the "sandbox") and performs the following: |
| 71 | |
| 72 | - security scan |
| 73 | - compatibility test for the OS and vendor binary |
| 74 | - malware scan |
| 75 | |
| 76 | The Certification group then instantiates the VF image using the vendor |
| 77 | Heat (if provided) in order to validate that the VM can run on the Network |
| 78 | Cloud. |
| 79 | |
| 80 | No VF functionality testing is performed at this stage. |
| 81 | |
| 82 | |
| 83 | Generate Manifest and Package Artifacts |
| 84 | --------------------------------------- |
| 85 | |
| 86 | Before onboarding resources, run generate-manifest.py to generate a |
| 87 | MANIFEST file. These steps are performed outside SDC. |
| 88 | |
| 89 | OBSOLETE: **Prerequisites:** Obtain Heat/ENV files and other files required for |
| 90 | onboarding. See the reference document `VNF Heat Template Requirements |
| 91 | for OpenECOMP <https://wiki.onap.org/download/attachments/1015849/VNF%20Heat%20Template%20Requirements%20for%20OpenECOMP.pdf?version=2&modificationDate=1487262292000&api=v2>`__ for details. |
| 92 | |
| 93 | UPDATE: see VNF Modeling Requirements / HEAT: https://onap.readthedocs.io/en/casablanca/submodules/vnfrqts/requirements.git/docs/Chapter5/Heat/index.html |
| 94 | |
| 95 | #. Put the Heat, ENV, nested Heat, and other files used by get-file in templates |
| 96 | in a directory. |
| 97 | |
| 98 | Naming guidelines: |
| 99 | |
| 100 | - The base Heat should include "base" in the name. |
| 101 | - The ENV file name should match the name of the Heat file with which it |
| 102 | is associated. |
| 103 | - All get-file file names need to be unique. |
| 104 | |
| 105 | #. Put the python script in a directory one level above the directory that |
| 106 | contains the Heat/ENV and other files. |
| 107 | |
| 108 | For example, [dir x]/[dir y] |
| 109 | |
| 110 | - [dir y] contains the Heat/ENV files and other files |
| 111 | - [dir x] contains the python script |
| 112 | |
| 113 | #. Run the script on the Windows command line: |
| 114 | |
| 115 | .. code-block:: |
| 116 | |
| 117 | python generate-manifest.py -f "dir y" |
| 118 | |
| 119 | #. Examine the manifest file and confirm that is correct. |
| 120 | |
| 121 | #. Package all Heat/ENV files, all other files, and the MANIFEST.json |
| 122 | into one .zip file. |
| 123 | |
| 124 | |
| 125 | .. |image1| image:: media/tenant.png |
| 126 | .. _tenant: https://wiki.onap.org/display/DW/Glossary#Glossary-tenant |