docs/guides/onap-user/design/pre-onboarding/index.rst

   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 .. _doc_guide_user_des_pre-onb:
   6
   7 Pre-Onboarding
   8 ==============
   9
  10     * `Create a Tenant`_ (will be moved to "Service Deployment")
  11     * `Generate Manifest and Package Artifacts`_ (for HEAT based VNFs)
  12     * `Validate xNF Package (VNF/PNF)`_
  13
  14 .. _doc_guide_user_des_pre-onb_cre-ten:
  15
  16 Create a Tenant
  17 ---------------
  18
  19 .. note::
  20    This section is not really belonging to the "Design" phase,
  21    but to the preparation of the "Service Deployment" and will be
  22    moved in the next release
  23
  24 Each service requires a tenant_ (a group of users who share a common access)
  25 in which resources are stored in the cloud. This process is performed using
  26 facilities of the network cloud, outside of ONAP. Confirm that the tenant is
  27 created and note the tenant ID.
  28
  29 ONAP admin users can configure a cloud-owner to add new cloud resources.
  30 These are the computing and networking resources, that will support
  31 running VNFs. A cloud-owner holds a keystone URL, login, region and
  32 password, in the case of an Openstack cluster. A cloud-owner also
  33 belongs to a region. The region name should be the same as the Openstack
  34 region. Prior to creation of a cloud-owner, its region must be created
  35 first. Multiple tenants can share the same cloud-owner. Note that these
  36 tenants are ONAP tenants, not Openstack tenants. Tenant register
  37 services that customers are allowed to deploy. Finally, the customer is
  38 like an instance of the tenant.
  39
  40 Note: there is no GUI (yet) to configure these objects. REST requests
  41 are sent to AAI to achieve the configuration. For a detailed list of
  42 required REST commands see:
  43
  44 https://wiki.onap.org/display/DW/running+vFW+Demo+on+ONAP+Amsterdam+Release
  45
  46 The overall process is as follows:
  47
  48  #. Create a region and a cloud-owner. This steps registers Openstack
  49     credentials. This is the only step requiring entering Openstack specific
  50     parameters.
  51
  52  #. Create a complex. The complex describes the coverage of the region with
  53     a street address etc.
  54
  55  #. Create a service. The service name should match the name of the service
  56     onboarded in SDC.
  57
  58  #. Create a tenant. Tenant in ONAP stores a design for a generic customer.
  59
  60  #. Associate tenants with their allowed services.
  61
  62  #. Create an instance of the tenant or customer. The customer is visible in
  63     VID. A VID user can deploy allowed services on this new customer.
  64
  65    |image1|
  66
  67
  68 .. _doc_guide_user_des_pre-onb_gen-man:
  69
  70 Generate Manifest and Package Artifacts
  71 ---------------------------------------
  72
  73 .. note::
  74    This section describes the steps required to package a given HEAT
  75    template into a zip-file, which can be onboarded to SDC. Instructions
  76    to create TOSCA based VNF or PNF Onboarding Packages are not described
  77    here
  78
  79 Before onboarding resources, run generate-manifest.py to generate a
  80 MANIFEST file. These steps are performed outside SDC.
  81
  82 **Prerequisites:** Obtain Heat/ENV files and other files required for
  83 onboarding. The requirements are found in the following document.
  84
  85 .. toctree::
  86    :maxdepth: 1
  87    :titlesonly:
  88
  89    Heat requirements <../../../../submodules/vnfrqts/requirements.git/docs/Chapter5/Heat/index.rst>
  90
  91 #. Put the Heat, ENV, nested Heat, and other files used by get-file in templates
  92    in a directory.
  93
  94    Naming guidelines:
  95
  96     - The base Heat should include "base" in the name.
  97     - The ENV file name should match the name of the Heat file with which it
  98       is associated.
  99     - All get-file file names need to be unique.
 100
 101 #. Put the python script in a directory one level above the directory that
 102    contains the Heat/ENV and other files.
 103
 104    For example, [dir x]/[dir y]
 105
 106     - [dir y] contains the Heat/ENV files and other files
 107     - [dir x] contains the python script
 108
 109 #. Run the script on the Windows command line (not valid anymore):
 110
 111    .. code-block:: python
 112
 113       python generate-manifest.py -f "dir y"
 114
 115 #. Examine the manifest file and confirm that is correct.
 116
 117 #. Package all Heat/ENV files, all other files, and the MANIFEST.json
 118    into one .zip file.
 119
 120 .. _doc_guide_user_des_pre-onb_val:
 121
 122 Validate xNF Package (VNF/PNF)
 123 ------------------------------
 124
 125 VNF and PNF packages have to follow the requirements described in:
 126
 127 .. toctree::
 128    :maxdepth: 1
 129    :titlesonly:
 130
 131    VNF and PNF Modeling Requirements <../../../../submodules/vnfrqts/requirements.git/docs/Chapter5/index.rst>
 132    ONAP Management Requirements <../../../../submodules/vnfrqts/requirements.git/docs/Chapter7/index.rst>
 133
 134 For Validation of VNF and PNF packages the tools delivered by VNFSDK can be
 135 used:
 136
 137 .. toctree::
 138    :maxdepth: 1
 139    :titlesonly:
 140
 141    ../../../onap-provider/vnfvalidator.rst
 142
 143 Prior to resource onboarding, the Certification Group does the following:
 144
 145  - for VNF and PNF
 146      - Validation of the delivered xNF package and artifacts
 147      - using the VNF Validation Tools
 148  - in case of VNF
 149     - onboards the Heat template(s) and metadata to the SDC catalog
 150     - creates a test VF
 151     - runs the Heat scanning tools
 152  - shares the results with any group that approves Virtual Functions
 153
 154 In parallel, the Certification Group onboards the VF Image and OS to a
 155 standalone ONAP instance (the "sandbox") and performs the following:
 156
 157  - security scan
 158  - compatibility test for the OS and vendor binary
 159  - malware scan
 160
 161 The Certification group then instantiates the VF image using the vendor
 162 Heat (if provided) in order to validate that the VM can run on the Network
 163 Cloud.
 164
 165 No VF functionality testing is performed at this stage.
 166
 167
 168 .. |image1| image:: media/tenant.png
 169 .. _tenant: https://wiki.onap.org/display/DW/Glossary#Glossary-tenant