Creating a CSAR Package File

When you use Virtual Network Function Manager (VNFM) to deploy SBC SWe in an OpenStack cloud environment, you must provide it with a Cloud Service Archive (CSAR) package file that is appropriate for the type of deployment you want to create. The CSAR package includes a Virtual Network Function Descriptor (VNFD) file that defines the characteristics of your deployment.  

 Ribbon provides the script createVnfmCsar.py and a VNFD template file (vnfmSol001VnfdTemplate.yaml) to create a CSAR file for your deployment.

By default, from SBC 10.1.x onwards, the createVnfmCsar.py creates a 3.5.1 compliant VNFD. You can only use this with VNFM versions 21.2 onwards.

Two additional files are also supplied along with createVnfmCsar.py and vnfmSol001VnfdTemplate.yaml

vnfmSol001VnfdCustomTypes.yaml - types definition file needed for CSARs that are SOL001 3.5.1. compliant.

vnfm_pre_21_2_Sol001VnfdTemplate.yaml - VNFD template file for use with older VNFM versions.

Script Parameters

The following tables describe the script run-time parameters. Help information for these parameters is also available by entering: createVnfmCsar.py --usage

The following parameters address less commonly used instantiation options, but may be necessary to address specific requirements in some customer deployments.

Custom Naming Parameters

You have the option to include script parameters that modify the names assigned to the system and individual node instances when the system is deployed. Refer to System and Instance Naming in SBC SWe N:1 and Cloud-Based Systems for more information on the default naming conventions.

The following table summarizes the custom naming parameters.

Tokens

The following tokens are allowed within the custom naming parameters:

%rg_index%  -- to include the redundancy group index.

%vnftype% or %VNFTYPE% -- to include the VNF type (for example: SSBC) in lower or uppercase.

VNFM tokens –  %orchname%, %basename%, %index%, %vmname%, %vmtype%, %get_param:parmname%
Refer to Using Customized Naming in a VNFD in VNFM documentation for more information on which VNFM tokens apply to which resources. 

Naming Syntax

To construct the SBC parameter actualCeName for each node it is deploying, VNFM begins with the the custom_system_name and appends either the custom_oam_name or custom_sbc_name (based on node type), followed by a VM index. That is:

<custom_system_name><custom_oam_name><VM index> or

<custom_system_name><custom_sbc_name><VM index>

The VM index is a unique instance number for the node type, up to 5 in a 4:1 HA deployment. For clarity, if either the custom_oam_name or custom_sbc_name ends in a digit or the %rg_index% token, VNFM automatically adds a dash before the VM index. Include the custom_vmname_dash parameter to manually include a dash before the VM index.

Custom Naming Example

The following custom naming parameters in a 4:1 HA deployment with two redundancy groups:

--custom_oam_name OAMX --custom_sbc_name GRP%rg_index% --custom_system_name EX-SSBC22

Yields the following node names:

EX-SSBC22-OAMX1, EX-SSBC22-OAMX2

EX-SSBC22-GRP1-1, EX-SSBC22-GRP1-2, EX-SSBC22-GRP1-3,EX-SSBC22-GRP1-4,EX-SSBC22-GRP1-5

EX-SSBC22-GRP2-1, EX-SSBC22-GRP2-2, EX-SSBC22-GRP2-3,EX-SSBC22-GRP2-4,EX-SSBC22-GRP2-5

Environment Variables

For deployments that require even greater flexibility in customizing the names of resources, prior to running the script, you can define environment variables to override the default naming conventions for different types of resources. The environment variables and their use in conjunction with the createVnfmCsar.py script are described in online command help provided with the script. To display the help information on custom naming options, enter:

createVnfmCsar.py --help_custom

Running the Script

Complete the following steps to generate a CSAR file:

1. If you have not already done so, download the script and VNFD template files. The template and associated script are available in the file cloudTemplates.tar.gz.
2. Copy the script and template files to a Linux environment where python is also both installed. Openssl must also be present if you want to sign the package files.  
3. Review the options in the preceding table to determine which options are required for your deployment. The -p and -s parameters are required. All other parameters are optional, but including a specific value for the -f, -h, -i, and --personality parameters ensures you generate a single CSAR file for a single deployment type. 
4. Switch to the directory location where the script and template file reside. 
5. Referring to the syntax shown in the previous table, enter the script name followed by its parameters in a single statement. The location of the CSAR file(s) the script generates is shown in the screen output.

Examples

The following command creates a single CSAR package file for a 1:1 HA S-SBC deployment that uses virtio interfaces:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha -i virtio --personality ssbc

The following command creates a single CSAR package file for a 3:1 HA M-SBC deployment that uses SR-IOV interfaces and includes a 1:1 HA pair of OAM nodes:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h n_1_ha --num_instances 4 -i sriov --personality msbc --num_oam_instances 2

The following command creates a single CSAR package file for a 1:1 HA I-SBC deployment that uses an IPv6 provider network:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha -i provider --ipv6 --personality isbc

The following command creates three CSAR packages file for 1:1 HA S-SBC deployments – one with virtio, one with SR-IOV, and one with provider interfaces:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha --personality ssbc

The following command creates a CSAR Package file for 4:1 HA M-SBC deployment that uses virtio interfaces, includes a HA pair of OAM nodes, and allows scaling up to 6 full Redundancy Groups:

createVnfmCsar.py -p "10.01.00" -s "R000" -f std -h n_1_ha -i virtio --personality ssbc --affinity_across_rgs true --enable_scaling --max_sbc_rg 6 --redundancy_ratio "4:1" --num_oam_instances 2

Creating Multiple Redundancy Groups that Use the Same OAM Nodes 

The createVnfmCsar.py script provides an option to create multiple redundancy groups within the same cluster. These redundancy groups will share the same configuration and are managed by the same OAM nodes. When you set the num_sbc_rg option to a value greater than one, the script generates a VNFD file that includes additional sets of parameters for the number of redundancy groups specified. During instantiation, VNFM presents multiple sets of parameters where appropriate, enabling you to define the parameters that are specific to an individual redundancy group, such as its name. The redundancy groups are uniquely identified in the interface by prepending names with rg#_.

To create multiple SBC redundancy groups that are managed by the same OAM nodes:

1. Run the createVnfmCsar.py script using the option num_sbc_rg to specify the number of SBC redundancy groups you want to create. 
   For example, the following command generates a CSAR package containing a VNFD file that creates two 4:1 HA M-SBC redundancy groups:
   
   createVnfmCsar.py -p 9.01.00 -s R000 -i virtio -f std -h n_1_ha --num_instances 5 --num_oam_instances 2 --personality msbc --omit_ipv6 --num_sbc_rg 2
2. Onboard the resulting CSAR package file to VNFM.

3. Instantiate the VNF using the CSAR package you generated. VNFM replicates any parameters needed to define each redundancy group. The following figure shows a part of the VNFM instantiation screen requesting SBC system names for two redundancy groups.  Similarly, VNFM replicates other instantiation parameters (Networks, Flavors, Manual IP) for each redundancy group. 

   Multiple Redundancy Groups - System Name Options