VNF Package¶
VNF Package is a ZIP file including VNFD, software images for VM, and other artifact resources such as scripts and config files. The directory structure and file contents are defined in NFV-SOL004 v2.6.1.
According to NFV-SOL004 v2.6.1, VNF Package should be the ZIP file format with the TOSCA-Simple-Profile-YAML-v1.1 Specifications. The ZIP file is called TOSCA YAML Cloud Service Archive (CSAR), and two different structures are available:
CSAR with TOSCA-Metadata directory
CSAR zip without TOSCA-Metadata directory
Note
VNF LCM API version 1 supports both structures. VNF LCM API version 2 supports only CSAR with TOSCA-Metadata directory.
Note
For more detailed definitions of CSAR, see section 16 in TOSCA-Simple-Profile-YAML-v1.1.
Some examples for VNF Package are available in Tacker repository.
CSAR with TOSCA-Metadata directory¶
The directory structure:
TOSCA-Metadata/TOSCA.meta
Definitions/
Files/images/
(optional) Scripts/
(optional) <manifest file name>.mf
(optional) BaseHOT/
(optional) UserData/
Note
BaseHOT and UserData are optional, but they are required when running LCM operation user data. This methodology is under discussion within NFV-SOL014 v2.8.1 and there is no clear directory structure yet. Please check with ETSI NFV-SOL VNF Deployment as VM with LCM Operation User Data.
The specification can be modified according to standardization NFV-SOL014 v2.8.1.
!----TOSCA-Metadata
!---- TOSCA.meta
!----Definitions
!---- etsi_nfv_sol001_common_types.yaml
!---- etsi_nfv_sol001_vnfd_types.yaml
!---- vnfd_top.yaml
!---- vnfd_df_1.yaml
!---- ..
!---- vnfd_df_x.yaml
!---- vnfd_types.yaml
!----Files
!---- images
!---- image_1.img
!---- ..
!---- image_x.img
!----Scripts (optional)
!---- install.sh
!---- manifest.mf
!----BaseHOT (optional)
!---- df_1
!---- base_hot_df_1.yaml
!---- ..
!---- df_x
!---- base_hot_df_x.yaml
!----UserData (optional)
!---- __init__.py
!---- lcm_user_data.py
TOSCA-Metadata/TOSCA.meta¶
According to TOSCA-Simple-Profile-YAML-v1.1 specifications, the
TOSCA.meta metadata file is described in TOSCA-1.0-specification,
and it should have the following contents:
TOSCA-Meta-File-Version: This is the version number of the TOSCA meta file format and must be “1.0”.
CSAR-Version: This is the version number of the CSAR specification and must be “1.1”
Created-By: The person or vendor, respectively, who created the CSAR.
Entry-Definitions: This is the reference to the top-level VNFD file in Definitions/ directory.
(optional) ETSI-Entry-Manifest: This is the reference to the manifest file. When this key/value is not provided, Tacker tries to find the manifest file with the name of top-level VNF file as
<VNFD file name>.mf.
In TOSCA.meta file, artifact resources related information, which is also
possible to locate in manifest file, can be described in the following manner
according to TOSCA-1.0-specification section 16.2:
Note
It is highly recommended to put artifacts information in the manifest file other than in TOSCA.meta file because it’s more simple and easy to understand.
(optional) artifact info - describes location and digest of all files other than VNFD YAML files.
Name: The path and identifier of the file.
Content-Type: The type of the file described. This type is a MIME type complying with the type/subtype structure.
Algorithm: The name of hash algorithm. “SHA-224”, “SHA-256”, “SHA-384”, and “SHA-512” are supported.
Hash: Text string corresponding to the hexadecimal representation.
Note
For software images, note that the algorithm of hash calculation is the same as the Glance configuration, the default is “SHA-512”. The software images are not additionalArtifacts but softwareImages according to NFV-SOL005 v2.6.1.
Note
The “Name” and “Content-Type” attributes are defined in TOSCA-1.0-specification section 16.2. The “Algorithm” and “Hash” are requirement from NFV-SOL004 v2.6.1 section 5.3 and NFV-SOL005 v2.6.1 section 9.5.3.3, the checksum field is required and the manner should be the same with the manifest file.
Example:
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-By: Tacker
Entry-Definitions: vnfd_top.yaml
ETSI-Entry-Manifest: manifest.mf
Name: manifest.mf
Content-Type: text/plain
Algorithm: SHA-256
Hash: 09e5a788acb180162c51679ae4c998039fa6644505db2415e35107d1ee213943
Name: scripts/install.sh
Content-Type: application/x-sh
Algorithm: SHA-256
Hash: d0e7828293355a07c2dccaaa765c80b507e60e6167067c950dc2e6b0da0dbd8b
Name: https://www.example.com/example.sh
Content-Type: application/x-sh
Algorithm: SHA-256
Hash: 36f945953929812aca2701b114b068c71bd8c95ceb3609711428c26325649165
Definitions/¶
All VNFD YAML files are located here. How to create VNFD composed of plural deployment flavours is described in VNF Descriptor (VNFD) based on ETSI NFV-SOL001.
VNFD type files provided from ETSI NFV-SOL001 repository are also included:
etsi_nfv_sol001_common_types.yaml
etsi_nfv_sol001_vnfd_types.yaml
Files/images/¶
VNF Software Images are located here. These files are also described in
TOSCA.meta or manifest file as artifacts.
Scripts/¶
Any script files are located here. These scripts are executed in Action
Driver or Management Driver. All these files also appear in TOSCA.meta
or manifest file as artifacts.
<manifest file name>.mf¶
The manifest file contains two types of information, metadata and artifact
info. metadata is optional and artifact info is required when one or
more artifacts are included in the VNF Package file such as software images,
scripts or config files. This artifact info is also possible to be in
TOSCA.meta file.
(optional) metadata - is optional metadata for the VNF Package file.
vnf_product_name: The product name of VNF.
vnf_provider_id: The ID of VNF provider.
vnf_package_version: The version of the VNF Package file.
vnf_release_date_time: The format according to IETF RFC 3339.
Note
The metadata in manifest file is not stored in Tacker DB.
artifact info - describes location and digest of all files other than VNFD YAML files.
Source: The path and identifier of the file.
Algorithm: The name of hash algorithm. “SHA-224”, “SHA-256”, “SHA-384”, and “SHA-512” are supported.
Hash: Text string corresponding to the hexadecimal representation.
Example:
metadata:
vnf_product_name: VNF
vnf_provider_id: Tacker
vnf_package_version: 1.0
vnf_release_date_time: 2020-01-01T10:00:00+09:00
Source: VNFD.yaml
Algorithm: SHA-256
Hash: 09e5a788acb180162c51679ae4c998039fa6644505db2415e35107d1ee213943
Source: scripts/install.sh
Algorithm: SHA-256
Hash: d0e7828293355a07c2dccaaa765c80b507e60e6167067c950dc2e6b0da0dbd8b
Source: https://www.example.com/example.sh
Algorithm: SHA-256
Hash: 36f945953929812aca2701b114b068c71bd8c95ceb3609711428c26325649165
BaseHOT/¶
Base HOT file is a Native cloud orchestration template, HOT in this context, which is commonly used for LCM operations in different VNFs. This Base HOT can work on OpenStack API and be filled by Heat input parameters generated by LCM operation user data. It is the responsibility of the user to prepare this file, and it is necessary to make it consistent with VNFD placed under the Definitions/ directory.
Note
Place the directory corresponding to deployment-flavour stored in the Definitions/ under the BaseHOT/ directory, and store the Base HOT files in it. In this DQ example, it is assumed that there is a deployment-flavour from df_1 to` df_x`. For more information on deployment-flavour, see NFV-SOL001 v2.6.1 Annex A.
Example:
heat_template_version: 2013-05-23
description: 'Template for test _generate_hot_from_tosca().'
parameters:
nfv:
type: json
resources:
VDU1:
type: OS::Nova::Server
properties:
flavor:
get_resource: VDU1_flavor
name: VDU1
image: { get_param: [ nfv, VDU, VDU1, image ] }
networks:
- port:
get_resource: CP1
CP1:
type: OS::Neutron::Port
properties:
network: { get_param: [ nfv, CP, CP1, network ] }
VDU1_flavor:
type: OS::Nova::Flavor
properties:
ram: { get_param: [ nfv, VDU, VDU1, flavor, ram ] }
vcpus: { get_param: [ nfv, VDU, VDU1, flavor, vcpus ] }
disk: { get_param: [ nfv, VDU, VDU1, flavor, disk ] }
outputs: {}
Note
For property (e.g. image in VDU1) whose value is “get_param”, the Heat input parameters generated by script placed under UserData/ directory.
UserData/¶
LCM operation user data is a script that returns key/value data as Heat input parameters used for Base HOT. As Heat input parameter, OpenStack parameters that are not statically defined in the VNFD(e.g. flavors, images, hardware acceleration, driver-setup, etc.) can be assigned.
Note
It is necessary to generate Heat input parameters for HOT file This script has the following advantages/disadvantages for VNF package creators/users. The advantage is that this script has no operational restrictions, so it can be freely described by creators and operated by users. The disadvantage is that creators can write a script that involves DB operations, which can lead to unexpected behavior for users. The trade-off between being able to write scripts freely and limiting operations is an issue for the future.
Note
User data script is incompatible between VNF LCM API version 1 and 2 due to different requirements for them.
The requirements of User data script for VNF LCM API version 2 is described in UserData script (VNF LCM v2).
Following shows an example of user data script for VNF LCM API version 1.
import tacker.vnfm.lcm_user_data.utils as UserDataUtil
from tacker.vnfm.lcm_user_data.abstract_user_data import AbstractUserData
class SampleUserData(AbstractUserData):
@staticmethod
def instantiate(base_hot_dict=None,
vnfd_dict=None,
inst_req_info=None,
grant_info=None):
# Create HOT input parameter using util functions.
initial_param_dict = UserDataUtil.create_initial_param_dict(
base_hot_dict)
vdu_flavor_dict = UserDataUtil.create_vdu_flavor_dict(vnfd_dict)
vdu_image_dict = UserDataUtil.create_vdu_image_dict(grant_info)
cpd_vl_dict = UserDataUtil.create_cpd_vl_dict(
base_hot_dict, inst_req_info)
final_param_dict = UserDataUtil.create_final_param_dict(
initial_param_dict, vdu_flavor_dict, vdu_image_dict, cpd_vl_dict)
return final_param_dict
Note
It is necessary to generate Heat input parameters for HOT file placed under BaseHOT/ directory by this scprit.
CSAR zip without TOSCA-Metadata directory¶
The file structure:
<VNFD file name>.yaml
Definitions/
<manifest file name>.yaml
!---- vnfd_top.yaml
!----Definitions/
!---- etsi_nfv_sol001_common_types.yaml
!---- etsi_nfv_sol001_vnfd_types.yaml
!---- vnfd_top.yaml
!---- vnfd_df_1.yaml
!---- ..
!---- vnfd_df_x.yaml
!---- vnfd_types.yaml
!---- vnfd_top.mf
<VNFD file name>.yaml¶
This is the top-level VNFD file. It can import additional VNFD files from the Definitions/ directory.
Definitions/¶
All VNFD YAML files other than top-level VNFD are located here. How to create VNFD composed of plural deployment flavours is described in VNF Descriptor (VNFD) based on ETSI NFV-SOL001.
VNFD type files provided from ETSI NFV-SOL001 repository may be included:
etsi_nfv_sol001_common_types.yaml
etsi_nfv_sol001_vnfd_types.yaml
<manifest file name>.yaml¶
The manifest file has an extension .mf, the same name as the top-level VNFD YAML file. The contents is exactly same as described in the previous section.
