This section provides details about updating ETSI API resource definitions.
Updating the VNF Flavour
A VNF flavour can be updated by updating the TOSCA parameters in the VNFD template. You can define the alternate VNF nodes
and deployment flavours for a single VNFD using the following TOSCA parameters:
Import statements—The import statement allows a single, parent VNFD yaml file to conditionally include other files based on an input value
which can be specified dynamically, at run time.
Substitution mappings—The substitution mapping applies only to the node types derived from the tosca.nodes.nfv.VNF. You cannot substitute values of other node types that is, Connection Points, Virtual Links and so on.
In this example, the yaml file contains three import files.
All three files must exist in the VNFD ZIP archive file in the same location as the parent file importing them.
The requirements and capabilities are not defined in the derived tosca.nodes.nfv.VNF node. These are mandatory for defining characteristics of VNFs instantiated using this VNFD. They are defined within the
description: Substitution Mapping Example
. . .
. . .
. . .
# Substitution Mapping #
. . .
flavour_description: Default VNF Deployment Flavour
Example 2:When the VNF is instantiated, the required flavour is sent in the Instantiate request to the VNFM. The TOSCA parser tries
to match the flavour and the VNF node name with the defined substitution mappings. These may be imported or defined within
the VNFD itself. For example, the df_silver.yaml contains the following:
description: Silver Deployment Flavour
flavour_description: Silver VNF Deployment Flavour
- virtual_link: [ vm1_nic1, virtual_link ]
silver is the flavourId passed in the Instantiate Request payload. The parent yaml shown above has its empty requirements section updated with the requirements from the silver profile, and the existing flavour_id and flavour_description properties are updated as well.
description: Deployment Flavour SILVER
virtual_link: [ anECP, external_virtual_link ]
description: 'SILVER Deployment Flavour'
description: 'Default Instantiation Level'
description: 'SILVER Instantiation Level'
description: "SILVER: This is substituted if not already defined"
ESC sends a POST request to update the VNF flavour:
Updating the External VNF Connectivity
You can update the external VNF connectivity in an existing deployment. The API supports the following changes:
Disconnect the existing connection points (CPs) to the existing external virtual link and connect to a different virtual link.
Change the connectivity parameters of the existing external CPs, including changing the addresses.
ESC sends a POST request to update the VNF external connectivity:
Request Payload (Data structure = ChangeExtVnfConnectivityRequest)
The id in the extVirtualLinks, extVL-98345443-7797-4c6d-a0ed-e18771dacf1c in the above example, must also exist in the instantiatedVnfInof in the vnfInstance.
The substitution merges the new values into the VNFD.
For regular scalar properties such as name=joe, the value is replaced in the VNFD.
Arrays such as [list, of, strings] are merged. The new values are added into the array, if they do not exist.
Objects such as where a key is indented under another key, are replaced. The configurable_properties object in the matched
substitution will overwrite that defined in the VNFD.
If the VNF is instantiated by the Test Harness, the flavour is persisted and used in the subsequent LCM operations so that
the VNFD always uses the same mappings.
If the instantiate operation is called from elsewhere (such as cURL or Postman) then the flavour contained in the grant is
persisted and used in the subsequent LCM operations.
If the Test Harness receives a grant request for a VNF not instantiated through it, then the grant is most likely to fail
if no substitution mapping occurs.
After the substitution mappings are made, the parser tries to populate any additionalParams provided. Note that the command fails if the input parameters do not match those in the template.