1. Scope

DESCRIPTION: What do we mean by onboarding? A design time activity that brings "onboard" a resource into ONAP for later use in services. This flow describes the the onboarding of resources into SDC. This can apply to a new resource or an upgraded resource. A resource can be a VNF or PNF. Resources are onboarded into the SDC catalog during design time. This flow will describe what happens when a resource is brought into SDC. A resource in the SDC catalog can then be used in design time to define a service.

...

PREONBOARDING

ONBOARDING

 - Types on Onboarding: TOSCA Onboarding, HEAT Onboarding, Manual Onboarding #@#

For PNFs

Stage view for PNF pre-onboarding/onboarding

PACKAGE DELIVERY - A vendor delivers a package that is to be onboarded. Note: that if you use Manual onboarding in SDC you do not need to have a PNF package.

...

ONBOARDING - SDC allows you to create a xNF resource without a PNF package (manual onboarding). Before services are created, SDC creates resources. You can (1) use HEAT template, or (2) use TOSCA template, or (3) use a SDC GUI to manually create a resource.

For VNFs:

#@# (Add for VNFs)

2. Pre-Conditions

ONAP is ready:

• SDC - SDC is ready to ingest a package. Platform Information & Platform Data model are available.
• CERTIFICATION STUDIO - The Certification Studio has certified the Package ready for distribution
• ONAP SOFTWARE - There is an ONAP installation. Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.

...

2.1 xNF ONBOARDING PACKAGE

Vendors will prepare the Onboarding package (if you are not manually onboarding) The Onboarding Package Contains:

...

• PNF DESCRIPTORS (PNFD) - (Instantiation/Design Time) PNFD and VNFD have been mapped to ONAP platform data/information model. That is, the onboarded descriptor models (vendor provided) have been mapped onto ONAP platform data & information models that are useable and known to ONAP.
• TOSCA METADATA - This file provided by the vendor describes the meta-information about the package. Notably it gives the key files in the package and their locations in the package as directory paths.
• MANIFEST FILE - The Manifest file include basic information about the package itself.
  • metadata with following keynames: pnfd_ provider, pnfd_name, pnfd_release_date_time, pnfd_archive_version
  • a list of all files contained in or referenced from the package with their location, expressed using a Source: location/name key-value pair. 
  • Non-mano-artifact tag: ONAP defined tags
• VES EVENT REGISTRATION - This file describes all of the events that are supported by the PNF. It defines the possible events that the PNF can support, such as faults, heartbeating, Performance measurements. These are defined in the VES Event specification document available in the repository. The Event Registration also defines all of the fields that each of these events have also
• PM DICTIONARY - Performance Measurements definitions. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• ANSIBLE PLAYBOOKS - Ansible playbooks define the "scripts" that are used for remote ansible communications from ONAP towards a PNF. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• NETCONF YANG MODELS - Defines the NetConf Yang Models that are used for NetConf communications between ONAP and the PNF. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• CHEF COOKBOOKS - When Chef communications are supported between ONAP and the PNF, these define the communication playbooks that are used by Chef. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• MANUALS - Manuals can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• HELP FILES - Help files can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• CUSTOMER DOCUMENTATION PRODUCTS - Customer documentation products can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• TEST FILES - Manuals can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin.
• LICENSING AGREEMENTS - Licensing agreements can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin and has been postponed.
• RESOURCE CONFIGURATION INFORMATION - Resource Configuration Information can be included in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• CONTROLLER BLUEPRINT ARTIFACT - From a controller perspective, there is a TOSCA implementation to execute template for configuration. These include Velocity templates, Jinja template. They can be generic or per PNF type (customized). This is OPTIONAL, a PNF package does NOT necessarily have this artifact. In future releases this could be incorporated into the PNF package. In R4/Dublin a ONAP user would manually upload the Controller Blueprint Artifact.

2.2 EXAMPLE xNF PACKAGE w/ FILES & DIRECTORIES

This section describes what an example of an actual package might look like, showing some of the key files and directories and how they might be arranged and delivered.

The onboarding PNF Package must be defined as specified as ETSI SOL004v2.6.1 + NFV CR NFVSOL(18)000746r3 

The package structure must be a CSAR with TOSCA-Metadata as specified in SOL004 section 4.1.2
The TOSCA.meta file keyname extension: SOL004 section 4.1.2.3

Image Added

3. Information Flow

The following UML diagram shows the PNF Pre-onboarding Flow

...

@startuml
participant ONAPUSER
participant VNFSDK
participant SDC
autonumber 

group PNF PACKAGE DELIVERY
	hnote over ONAPUSER : Onboarding API
	hnote over ONAPUSER : Vendor Delivery
	USER -> SDC : PNF Package Delivery 	
end

group PACKAGE VALIDATION
	hnote over VNFSDK : VNF SDK Package Validation
	VNFSDK -> VNFSDK : License File Check
	VNFSDK -> VNFSDK : Certificate File Check
	VNFSDK -> VNFSDK : Manifest file & destination cross-check
	VNFSDK -> VNFSDK : Manifest file tag Validation
	VNFSDK -> VNFSDK : TOSCA Metadata file validation
	hnote over VNFSDK : Certification Studio
	VNFSDK -> ONAPUSER : User checks validation
end

group SDC PACKAGE ONBOARDING
	hnote over SDC : xNF Resources, Service ID
	SDC -> SDC : UUID Metadata added
 	SDC -> SDC: TOSCA MetaData added
	SDC -> SDC : TOSCA Descriptor Added
	SDC -> SDC : X License Model Files Added
	ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
end

@enduml

3.1 Flow Description: PNF PACKAGE DELIVERY

1. PNF PACKAGE DELIVERY – Vendor Delivers the Package.

3.2 Flow Description: PACKAGE VALIDATION (VNF-SDK)

2. LICENSE FILE CHECK – VNF-SDK performs a license file check within the vendor-delivered PNF package.

...

7. USER CHECKS VALIDATION – The end user may then inspect that the PNF package has been appropriately verified in the Certification studio.

3.3 Flow Description: SDC PACKAGE ONBOARDING

8. UUID IDENTIFIER – SDC adds a UUID identifier.

...

12. ADDITIONAL ARTIFACTS – The User may optionally manually add additional artifacts.

4. Post Condition

The post-conditions for this flow are:

...