diff options
Diffstat (limited to 'docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst')
| -rw-r--r-- | docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst | 2233 |
1 files changed, 0 insertions, 2233 deletions
diff --git a/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst b/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst deleted file mode 100644 index 072a475..0000000 --- a/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst +++ /dev/null @@ -1,2233 +0,0 @@ -.. contents:: - :depth: 3 -.. - -| VNF -| Heat Template Requirements for -| OpenECOMP - -Revision 1.0 - -Revision Date 2/1/2017 - -**Document Revision History** - -+------------+------------+-----------------------------------------------------------------------+ -| Date | Revision | Description | -+============+============+=======================================================================+ -| 2/1/2017 | 1.0 | Initial publication of VNF Heat Template Requirements for OpenECOMP | -+------------+------------+-----------------------------------------------------------------------+ - -**Table of Contents** - -**Definitions** - -Throughout the document, these terms have the following meaning: - -**MUST** This word, or the terms "REQUIRED" or "SHALL", mean that the -definition is an absolute requirement of the specification. - -**MUST** **NOT** This phrase, or the phrase "SHALL NOT", mean that the -definition is an absolute prohibition of the specification. - -**SHOULD** This word, or the adjective "RECOMMENDED", mean that there -may exist valid reasons in particular circumstances to ignore a -particular item, but the full implications must be understood and -carefully weighed before choosing a different course. - -**SHOULD** **NOT** This phrase, or the phrase "NOT RECOMMENDED" mean -that there may exist valid reasons in particular circumstances when the -particular behavior is acceptable or even useful, but the full -implications should be understood and the case carefully weighed before -implementing any behavior described with this label. - -**MAY** This word, or the adjective "OPTIONAL", mean that an item is -truly optional. One vendor may choose to include the item because a -particular marketplace requires it or because the vendor feels that it -enhances the product while another vendor may omit the same item. An -implementation which does not include a particular option must be -prepared to interoperate with another implementation which does include -the option, though perhaps with reduced functionality. In the same vein -an implementation which does include a particular option must be -prepared to interoperate with another implementation which does not -include the option (except, of course, for the feature the option -provides.) - -Introduction -============ - -This reference document is the **VNF Heat Template Requirements for OpenECOMP** -and supports the first release of OpenECOMP. - -Program and Document Structure ------------------------------- - -This document is part of a hierarchy of documents that describes the -overall Requirements and Guidelines for OpenECOMP. The diagram below -identifies where this document fits in the hierarchy. - -+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| OpenECOMP Requirements and Guidelines | -+===============================================================================================================================================================================================================+ -| VNF Guidelines for Network Cloud and OpenECOMP | Future OpenECOMP Subject Documents | -+------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| VNF Cloud Readiness Requirements for OpenECOMP | VNF Management Requirements for OpenECOMP | VNF Heat Template Requirements for OpenECOMP | Future,VNF Requirements Documents | Future Requirements Documents | -+------------------------------------------------+-------------------------------------------+----------------------------------------------+-----------------------------------+-------------------------------+ - -Document Summary - -**VNF Guidelines for Network Cloud and OpenECOMP** - -- Describes VNF environment and overview of requirements - -*VNF Cloud Readiness Requirements for OpenECOMP* - -- Cloud readiness requirements for VNFs (Design, Resiliency, Security, - and DevOps) - -*VNF Management Requirements for OpenECOMP* - -- Requirements for how VNFs interact and utilize OpenECOMP - -**VNF Heat Template Requirements for OpenECOMP** - -- Provides recommendations and standards for building Heat templates - compatible with OpenECOMP– initial implementations of Network Cloud - are assumed to be OpenStack based. - -Intended Audience ------------------ - -This document is intended for persons developing Heat templates that -will be orchestrated by OpenECOMP. - -Scope ------ - -The first implementations of Network Cloud are assumed to be OpenStack -based and thus OpenECOMP will be supporting Heat Orchestration -Templates, also referred to as Heat templates or Heat in this document. - -OpenECOMP requires the Heat Templates to follow a specific format. This -document provides the mandatory, recommended, and optional requirements -associated with this format. - -In addition, the OpenStack version deployed in the Network Cloud may -impose additional constraints on the Heat. These constraints are not -covered in this document. - -VNF Modularity Overview ------------------------ - -OpenECOMP supports a modular Heat design pattern, referred to as *VNF -Modularity.* With this approach, a single VNF may be composed from one -or more Heat templates, each of which represents some subset of the -overall VNF. These component parts are referred to as “\ *VNF -Modules*\ ”. During orchestration, these modules may be deployed -incrementally to build up the complete VNF. - -A Heat template can be either one of the following types of modules: - -1. Base Module - -2. Incremental Modules - -3. Independent Cinder Volume Modules - -The OpenECOMP Heat template naming convention must be followed (Section -2.1). The naming convention identifies the module type. - -A VNF must be composed of one “base” VNF module (also called a base -module) and zero to many “incremental” or “add on” VNF modules. The base -module must be deployed first, prior to the add-on modules. - -A module can be thought of as equivalent to a Heat template, where a -Heat template is composed of a YAML file and an environment file (also -referred to as an ENV file). A given YAML file must have a corresponding -environment file; OpenECOMP requires it. - -A Heat template is used to create or deploy a Heat stack. Therefore, a -module is also equivalent to a Heat Stack. - -OpenECOMP supports the concept of an optional, independent deployment of -a Cinder volume via separate Heat templates. This allows the volume to -persist after VNF deletion so that the volume can be reused on another -instance (e.g. during a failover activity). - -The scope of a volume module, when it exists, must be 1:1 with the VNF -Module (base or add-on). A single volume module must create only the -volumes needed by a single VNF module (base or add-on). - -These concepts will be described in more detail throughout the document. -This overview is provided to set the stage and help clarify the concepts -that will be introduced. - -General Guidelines -================== - -The Heat templates supported by OpenECOMP must follow the requirements -enumerated in this section. - -Filenames ---------- - -In order to enable OpenECOMP to understand the relationship between Heat -files, the following Heat file naming convention must be followed. - -- The file name for the base module Heat template must include “base” - in the filename. - - - Examples: *base\_xyz.yml* or *base\_xyz.yaml*; *xyz\_base.yml* or - *xyz\_base.yaml* - -- There is no explicit naming convention for the add-on modules. - - - Examples: *module1.yml* or *module1.yaml* - -- All Cinder volume templates must be named the same as the - corresponding Heat template with “\_volume” appended to the file - name. - - - Examples: *base\_xyz\_volume.yml* or *base\_xyz\_volume.yaml*; - *xyz\_base\_volume.yml* or *xyz\_base\_volume.yaml*; - *module1\_volume.yml* or *module1\_volume.yaml* (referencing the - above base module Heat template name) - -- The file name of the environment files must fully match the - corresponding Heat template filename and have *.env* or *.ENV* - extension. - - - Examples: *base\_xyz.env* or *base\_xyz.ENV*; *xyz\_base.env* or - *xyz\_base.ENV*; *base\_xyz\_volume.env* or - *base\_xyz\_volume.ENV*; *module1.env* or *module1.ENV; - module1\_volume.env* or *module1\_volume.ENV* (referencing the - above base module Heat template name) - -- A YAML file must have a corresponding ENV file, even if the ENV file - enumerates no parameters. It is an OpenECOMP requirement. - -Valid YAML Format ------------------ - -A Heat template (a YAML file and its corresponding environment file) -must be formatted in valid YAML. For a description of YAML, refer to the -following OpenStack wiki: -https://wiki.openstack.org/wiki/Heat/YAMLTemplates - -A Heat template must follow a specific format. The OpenStack Heat -Orchestration Template (HOT) specification explains in detail all -elements of the HOT template format. -http://docs.openstack.org/developer/heat/template_guide/hot_spec.html - -Parameter Categories & Specification ------------------------------------- - -Parameter Categories -~~~~~~~~~~~~~~~~~~~~ - -OpenECOMP requires the Heat template parameters to follow certain -requirements in order for it to be orchestrated or deployed. OpenECOMP -classifies parameters into eight broad categories. - -- **OpenECOMP Metadata**: OpenECOMP mandatory and optional metadata - parameters in the resource *OS::Nova::Server*. - - - OpenECOMP dictates the naming convention of these Metadata - parameters and must be adhered to (See Section 4.4). - - - Metadata parameters must not be enumerated in the environment - file. - - - The OpenECOMP Metadata are generated and/or assigned by OpenECOMP - and supplied to the Heat by OpenECOMP at orchestration time. - -- **OpenECOMP Orchestration Parameters**: The data associated with - these parameters are VNF instance specific. - - - OpenECOMP enforces the naming convention of these parameters and - must be adhered to (See Section 4). - - - These parameters must not be enumerated in the environment file. - - - The OpenECOMP Orchestration Parameters are generated and/or - assigned by OpenECOMP and supplied to the Heat by OpenECOMP at - orchestration time. - -- **VNF Orchestration Parameters**: The data associated with these - parameters are VNF instance specific. - - - While OpenECOMP does not enforce a naming convention, the - parameter names should include {vm-type} and {network-role} when - appropriate. (See Section 4) - - - These parameters must not be enumerated in the environment file. - - - The VNF Orchestration Parameters Heat are generated and/or - assigned by OpenECOMP and supplied to the Heat by OpenECOMP at - orchestration time. - -- **OpenECOMP Orchestration Constants**: The data associated with these - parameters must be constant across all VNF instances. - - - OpenECOMP enforces the naming convention of these parameters and - must be adhered to (See Section 4). - - - These parameters must be enumerated in the environment file. - -- **VNF Orchestration Constants**: The data associated with these - parameters must be constant across all VNF instances. - - - While OpenECOMP does not enforce a naming convention, the - parameter names should include {vm-type} and {network-role} when - appropriate. (See Section 4) - - - These parameters must be enumerated in the environment file. - -- **OpenECOMP Base Template Output Parameters** (also referred to as - Base Template Output Parameters): The output section of the base - template allows for specifying output parameters available to add-on - modules once the base template has been instantiated. The parameter - defined in the output section of the base must be identical to the - parameter defined in the add-on module(s) where the parameter is - used. - -- **OpenECOMP Volume Template Output Parameters** (also referred to as - Volume Template Output Parameters): The output section of the volume - template allows for specifying output parameters available to the - corresponding Heat template (base or add-on) once the volume template - has been instantiated. The parameter defined in the output section of - the volume must be identical to the parameter defined in the base or - add-on module. - -- **OpenECOMP Predefined Output Parameters** (also referred to as - Predefined Output Parameters): OpenECOMP will look for a small set of - pre-defined Heat output parameters to capture resource attributes for - inventory in OpenECOMP. These parameters are specified in Section - 4.6. - -The table below summarizes the Parameter Types. If the user is -orchestrating a manual spin up of Heat (e.g. OpenStack command line), -the parameter values that OpenECOMP supplies must be enumerated in the -environment file. However, when the Heat is to be loaded into OpenECOMP -for orchestration, the parameters that OpenECOMP supplies must be -deleted or marked with a comment (i.e., a “#” placed at the beginning of -a line). - -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| Parameter Type | Naming Convention | Parameter Value Source | -+===============================================+=====================+=================================================================================+ -| OpenECOMP Metadata | Explicit | OpenECOMP | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| OpenECOMP Orchestration Parameters | Explicit | OpenECOMP | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| VNF Orchestration Parameters | Recommended | OpenECOMP | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| OpenECOMP Orchestration Constants | Explicit | Environment File | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| VNF Orchestration Constants | Recommended | Environment File | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| OpenECOMP Base Template Output Parameters | Recommended | Heat Output Statement for base, OpenECOMP supplied to add-on modules | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| OpenECOMP Volume Template Output Parameters | Recommended | Heat Output Statement for volume, OpeneECOMP supplies to corresponding module | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ -| OpenECOMP Predefined Output Parameters | Explicit | Heat Output Statement | -+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+ - -Table 1 Parameter Types - -Parameter Specifications -~~~~~~~~~~~~~~~~~~~~~~~~ - -OpenECOMP METADATA Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -OpenECOMP defines four “metadata” parameters: vnf\_id, vf\_module\_id, -vnf\_name, vf\_module\_name. These parameters must not define any -constraints in the Heat template, including length restrictions, ranges, -default value and/or allowed patterns. - -OpenECOMP Base Template & Volume Template Output Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The base template and volume template output parameters are defined as -input parameters in subsequent modules. When defined as input -parameters, these parameters must not define any constraints in the Heat -template, including length restrictions, ranges, default value and/or -allowed patterns. The parameter name defined in the output statement of -the Heat must be identical to the parameter name defined in the Heat -that is to receive the value. - -OpenECOMP Predefined Output Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -These parameters must not define any constraints in the Heat template, -including length restrictions, ranges, default value and/or allowed -patterns. - -OpenECOMP Orchestration Parameters, VNF Orchestration Parameters, OpenECOMP Orchestration Constants, VNF Orchestration Constants -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -OpenECOMP Orchestration Parameters, VNF Orchestration Parameters, -OpenECOMP Orchestration Constants, VNF Orchestration Constants must -adhere to the following: - -- All parameters should be clearly documented in the template, - including expected values. - -- All parameters should be clearly specified, including constraints and - description. - -- Numeric parameter constraints should include range and/or allowed - values. - -- When the parameter type is a string and the parameter name contains - an index, the index must be zero based. That is, the index starts at - zero. - -- When the parameter type is a Comma Delimited List (CDL), the - reference index must start at zero. - -- Default values must only be supplied in a Heat environment file to - keep the template itself as clean as possible. - -- Special characters must not be used in parameter names, as currently - only alphanumeric characters and “\_” underscores are allowed. - -Use of Heat Environments ------------------------- - -A YAML file must have a corresponding environment file (also referred to -as ENV file), even if the environment file defines no parameters. It is -an OpenECOMP requirement. - -The environment file must contain parameter values for the OpenECOMP -Orchestration Constants and VNF Orchestration Constants. These -parameters are identical across all instances of a VNF type, and -expected to change infrequently. The OpenECOMP Orchestration Constants -are associated with OS::Nova::Server image and flavor properties (See -Section 4.3). Examples of VNF Orchestration Constants are the networking -parameters associated with an internal network (e.g. private IP ranges) -and Cinder volume sizes. - -The environment file must not contain parameter values for parameters -that are instance specific (OpenECOMP Orchestration Parameters, VNF -Orchestration Parameters). These parameters are supplied to the Heat by -OpenECOMP at orchestration time. The parameters are generated and/or -assigned by OpenECOMP at orchestration time - -Independent Volume Templates ----------------------------- - -OpenECOMP supports independent deployment of a Cinder volume via -separate Heat templates. This allows the volume to persist after VNF -deletion so that they can be reused on another instance (e.g. during a -failover activity). - -A VNF Incremental Module or Base Module may have an independent volume -module. Use of separate volume modules is optional. A Cinder volume may -be embedded within the Incremental or Base Module if persistence is not -required. - -If a VNF Incremental Module or Base Module has an independent volume -module, the scope of volume templates must be 1:1 with Incremental -module or Base module. A single volume module must create only the -volumes required by a single Incremental module or Base module. - -The following rules apply to independent volume Heat templates: - -- Cinder volumes must be created in a separate Heat template from the - Incremental and Base Modules. - - - A single volume module must include all Cinder volumes needed by - the Incremental/Base module. - - - The volume template must define “outputs” for each Cinder volume - resource universally unique identifier (UUID) (i.e. OpenECOMP - Volume Template Output Parameters). - -- The VNF Incremental Module or Base Module must define input - parameters that match each Volume output parameter (i.e., OpenECOMP - Volume Template Output Parameters). - - - OpenECOMP will supply the volume template outputs automatically to - the bases/incremental template input parameters. - -- Volume modules may utilize nested Heat templates. - -**Example (volume template):** - - In this example, the {vm-type} has been left as a variable. - {vm-type} is described in section 4.1. If the VM was a load - balancer, the {vm-type} could be defined as “lb” - -.. code-block:: yaml - - parameters: - vm-typevnf\_name: - type: string - {vm-type}\_volume\_size\_0: - type: number - ... - - resources: - {vm-type}\_volume\_0: - type: OS::Cinder::Volume - properties: - name: - str\_replace: - template: VNF\_NAME\_volume\_0 - params: - VNF\_NAME: { get\_param: vnf\_name } - size: {get\_param: {vm-type}\_volume\_size\_0} - ... - -*(+ additional volume definitions)* - -.. code-block:: yaml - - outputs: - {vm-type}\_volume\_id\_0: - value: {get\_resource: {vm-type}\_volume\_0} - ... - -*(+ additional volume outputs)* - -*Example (VNF module template):* - -.. code-block:: yaml - - parameters: - {vm-type}\_name\_0: - type: string - {vm-type}\_volume\_id\_0: - type: string - ... - - resources: - {vm-type}\_0: - type: OS::Nova::Server - properties: - name: {get\_param: {vm-type}\_name\_0} - networks: - ... - - {vm-type}\_0\_volume\_attach: - type: OS::Cinder::VolumeAttachment - properties: - instance\_uuid: { get\_resource: {vm-type}\_0 } - volume\_id: { get\_param: {vm-type}\_volume\_id\_0 } - -Nested Heat Templates ---------------------- - -OpenECOMP supports nested Heat templates per the OpenStack -specifications. Nested templates may be suitable for larger VNFs that -contain many repeated instances of the same VM type(s). A common usage -pattern is to create a nested template for each VM type along with its -supporting resources. The master VNF template (or VNF Module template) -may then reference these component templates either statically (by -repeated definition) or dynamically (via *OS::Heat::ResourceGroup*). - -Nested template support in OpenECOMP is subject to the following -limitations: - -- Heat templates for OpenECOMP must only have one level of nesting. - OpenECOMP only supports one level of nesting. - -- Nested templates must be referenced by file name in the master - template - - - i.e. use of *resource\_registry* in the .env file is *not* - currently supported - -- Nested templates must have unique file names within the scope of the - VNF - -- OpenECOMP does not support a directory hierarchy for nested - templates. All templates must be in a single, flat directory (per - VNF) - -- A nested template may be shared by all Modules (i.e., Heat templates) - within a given VNF - -Networking -=========== - -External Networks ------------------ - -VNF templates must not include any resources for external networks -connected to the VNF. In this context, “external” is in relation to the -VNF itself (not with regard to the Network Cloud site). External -networks may also be referred to as “inter-VNF” networks. - -- External networks must be orchestrated separately, so they can be - shared by multiple VNFs and managed independently. When the external - network is created, it must be assigned a unique {network-role} (See - section 4.2). - -- External networks must be passed into the VNF template as parameters, - including the network-id (i.e. the neutron network UUID) and optional - subnet ID. - -- VNF templates must pass the appropriate external network IDs into - nested VM templates when nested Heat is used. - -- VNFs may use DHCP assigned IP addresses or assign fixed IPs when - attaching VMs to an external network. - -- OpenECOMP enforces a naming convention for parameters associated with - external networks. - -- Parameter values associated with an external network will be - generated and/or assigned by OpenECOMP at orchestration time. - -- Parameter values associated with an external network must not be - enumerated in the environment file. - -Internal Networks ------------------ - -Orchestration activities related to internal networks must be included -in VNF templates. In this context, “internal” is in relation to the VNF -itself (not in relation to the Network Cloud site). Internal networks -may also be referred to as “intra-VNF” networks or “private” networks. - -- Internal networks must not attach to any external gateways and/or - routers. Internal networks are for intra-VM communication only. - -- In the modular approach, internal networks must be created in the - Base Module template, with their resource IDs exposed as outputs - (i.e., OpenECOMP Base Template Output Parameters) for use by all - add-on module templates. When the external network is created, it - must be assigned a unique {network-role} (See section 4.2). - -- VNFs may use DHCP assigned IP addresses or assign fixed IPs when - attaching VMs to an internal network. - -- OpenECOMP does not enforce a naming convention for parameters for - internal network, however, a naming convention is provided that - should be followed. - -- Parameter values associated with an internal network must either be - passed as output parameter from the base template (i.e., OpenECOMP - Base Template Output Parameters) into the add-on modules or be - enumerated in the environment file. - -IP Address Assignment ---------------------- - -- VMs connect to external networks using either fixed (e.g. statically - assigned) IP addresses or DHCP assigned IP addresses. - -- VMs connect to internal networks using either fixed (e.g. statically - assigned) IP addresses or DHCP assigned IP addresses. - -- Neutron Floating IPs must not be used. OpenECOMP does not support - Neutron Floating IPs. - -- OpenECOMP supports the OS::Neutron::Port property - “allowed\_address\_pairs.” See Section 4.4.3. - -Parameter Naming Convention -=========================== - -{vm-type} ---------- - -A common *{vm-type}* identifier must be used throughout the Heat -template in naming parameters, for each VM type in the VNF with the -following exceptions: - -- The four OpenECOMP Metadata parameters must not be prefixed with a - common {vm-type} identifier. They are *vnf\_name*, *vnf\_id*, - *vf\_module\_id*, *vf\_module\_name*. - -- Parameters only referring to a network or subnetwork must not be - prefixed with a common {vm-type} identifier. - -- The parameter referring to the OS::Nova::Server property - availability\_zone must not be prefixed with a common {vm-type} - identifier. - -- {vm-type} must be unique to the VNF. It does not have to be globally - unique across all VNFs that OpenECOMP supports. - -{network-role} --------------- - -VNF templates must not include any resources for external networks -connected to the VNF. In this context, “external” is in relation to the -VNF itself (not with regard to the Network Cloud site). External -networks may also be referred to as “inter-VNF” networks. - -External networks must be orchestrated separately, so they can be shared -by multiple VNFs and managed independently. When the external network is -created, it must be assigned a unique {network-role}. - -“External” networks must be passed into the VNF template as parameters. -Examples include the network-id (i.e. the neutron network UUID) and -optional subnet ID. See section 4.4.3. - -Any parameter that is associated with an external network must include -the {network-role} as part of the parameter name. - -Internal network parameters must also define a {network-role}. Any -parameter that is associated with an internal network must include -int\_{network-role} as part of the parameter name. - -Resource: OS::Nova::Server - Parameters ---------------------------------------- - -The following OS::Nova::Server Resource Property Parameter Names must -follow the OpenECOMP parameter Naming Convention. All the parameters -associated with OS::Nova::Server are classified as OpenECOMP -Orchestration Parameters. - -+----------------------+-----------------------------------------+------------------+ -| OS::Nova::Server | -+======================+=========================================+==================+ -| Property | OpenECOMP Parameter Naming Convention | Parameter Type | -+----------------------+-----------------------------------------+------------------+ -| image | {*vm-type*}\_image\_name | string | -+----------------------+-----------------------------------------+------------------+ -| flavor | {*vm-type*}\_flavor\_name | string | -+----------------------+-----------------------------------------+------------------+ -| name | {*vm-type*}\_name\_{*index*} | string | -+----------------------+-----------------------------------------+------------------+ -| | {vm-type}\_names | CDL | -+----------------------+-----------------------------------------+------------------+ -| availability\_zone | availability\_zone\_{index} | string | -+----------------------+-----------------------------------------+------------------+ - -Table 2 Resource Property Parameter Names - -Property: image -~~~~~~~~~~~~~~~ - -Image is an OpenECOMP Orchestration Constant parameter. The image must -be referenced by the Network Cloud Service Provider (NCSP) image name, -with the parameter enumerated in the Heat environment file. - -The parameters must be named *“{vm-type}\_image\_name”* in the VNF. - -Each VM type (e.g., {vm-type}) should have a separate parameter for -images, even if several share the same image. This provides maximum -clarity and flexibility. - -Property: flavor -~~~~~~~~~~~~~~~~ - -Flavor is an OpenECOMP Orchestration Constant parameter. The flavors -must be referenced by the Network Cloud Service Provider (NCSP) flavor -name, with the parameter enumerated in the Heat environment file. - -The parameters must be named *“{vm-type}\_flavor\_name”* for each -*{vm-type}* in the VNF. - -Each VM type should have separate parameters for flavors, even if more -than one VM shares the same flavor. This provides maximum clarity and -flexibility. - -Property: Name -~~~~~~~~~~~~~~ - -Name is an OpenEOMP Orchestration parameter; the value is provided to -the Heat template by OpenECOMP. - -VM names (hostnames) for assignment to VM instances must be passed to -Heat templates either as - -- an array (comma delimited list) for each VM type - -- a set of fixed-index parameters for each VM type instance. - -Each element in the VM Name list should be assigned to successive -instances of that VM type. - -The parameter names must reflect the VM Type (i.e., include the -{vm-type} in the parameter name.) The parameter name format must be one -of the following: - -- If the parameter type is a comma delimited list: {**vm-type**}\_names - -- If the parameter type is a string with a fixed index: - {**vm-type**}\_name\_{**index**} - -If a VNF contains more than three instances of a given {vm-type}, the -CDL form of the parameter name (i.e., *{vm-type}*\ \_names} should be -used to minimize the number of unique parameters defined in the Heat. - -*Examples:* - -.. code-block:: yaml - - parameters: - {vm-type}\_names: - type: comma\_delimited\_list - description: VM Names for {vm-type} VMs - {vm-type}\_name\_{index}: - type: string - description: VM Name for {vm-type} VM {index} - -*Example (CDL):* - -In this example, the {vm-type} has been defined as “lb” for load -balancer. - -.. code-block:: yaml - - parameters: - lb\_names: - type: comma\_delimited\_list - description: VM Names for lb VMs - resources: - lb\_0: - type: OS::Nova::Server - properties: - name: { get\_param: [lb\_names, 0] } - ... - - lb\_1: - type: OS::Nova::Server - properties: - name: { get\_param: [lb\_names, 1] } - ... - -**Example (fixed-index):** - -In this example, the {vm-type} has been defined as “lb” for load -balancer. - -.. code-block:: yaml - - parameters: - lb\_name\_0: - type: string - description: VM Name for lb VM 0 - lb\_name\_1: - type: string - description: VM Name for lb VM 1 - - resources: - lb\_0: - type: OS::Nova::Server - properties: - name: { get\_param: lb\_name\_0 } - ... - - lb\_1: - type: OS::Nova::Server - properties: - name: { get\_param: lb\_name\_1 } - ... - -Property: availability\_zone -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Availability\_zone is an OpenECOMP Orchestration parameter; the value is -provided to the Heat template by OpenECOMP. - -Availability zones must be passed as individual numbered parameters (not -as arrays) so that VNFs with multi-availability zone requirements can -clearly specify that in its parameter definitions. - -The availability zone parameter must be defined as -“availability\_zone\_{index}”, with the {index} starting at zero. - -*Example:* - -In this example, the {vm-type} has been defined as “lb” for load -balancer. - -.. code-block:: yaml - - parameters: - lb\_names: - type: comma\_delimited\_list - description: VM Names for lb VMs - availability\_zone\_0: - type: string - description: First availability zone ID or Name - - resources: - lb\_0: - type: OS::Nova::Server - properties: - name: { get\_param: [lb\_names, 0] } - availability\_zone: { get\_param: availability\_zone\_0 } - ... - -Resource: OS::Nova::Server - Metadata -------------------------------------- - -This section describes the OpenECOMP Metadata parameters. - -OpenECOMP Heat templates must include the following three parameters -that are used as metadata under the resource OS::Nova:Server: vnf\_id, -vf\_module\_id, vnf\_name - -OpenECOMP Heat templates may include the following parameter that is -used as metadata under the resource OS::Nova:Server: vf\_module\_name. - -These parameters are all classified as OpenECOMP Metadata. - -+---------------------------+------------------+----------------------+ -| Metadata Parameter Name | Parameter Type | Mandatory/Optional | -+===========================+==================+======================+ -| vnf\_id | string | mandatory | -+---------------------------+------------------+----------------------+ -| vf\_module\_id | string | mandatory | -+---------------------------+------------------+----------------------+ -| vnf\_name | string | mandatory | -+---------------------------+------------------+----------------------+ -| vf\_module\_name | string | optional | -+---------------------------+------------------+----------------------+ - - Table 3 OpenECOMP Metadata - -Required Metadata Elements -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The vnf\_id, vf\_module\_id, and vnf\_name metadata elements are -required (must) for *OS::Nova::Server* resources. The metadata -parameters will be used by OpenECOMP to associate the servers with the -VNF instance. - -- vnf\_id - - - *“vnf\_id”* parameter value will be supplied by OpenECOMP. - OpenECOMP generates the UUID that is the vnf\_id and supplies it - to the Heat at orchestration time. - -- vf\_module\_id - - - “\ *vf\_module\_id”* parameter value will be supplied by - OpenECOMP. OpenECOMP generates the UUID that is the vf\_module\_id - and supplies it to the Heat at orchestration time. - -- vnf\_name - - - “\ *vnf\_name”* parameter value will be generated and/or assigned - by OpenECOMP and supplied to the Heat by OpenECOMP at - orchestration time. - -Optional Metadata Elements -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The following metadata element is optional for *OS::Nova::Server* -resources: - -- *vf\_module\_name* - - - The vf\_module\_name is the name of the name of the Heat stack - (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g. - Heat stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The - <STACK\_NAME> needs to be specified as part of the orchestration - process. - - - *“vf\_module\_name”* parameter value, when used, will be supplied - by OpenECOMP to the Heat at orchestration time. The parameter will - be generated and/or assigned by OpenECOMP and supplied to the Heat - by OpenECOMP at orchestration time. - -*Example* - -In this example, the {vm-type} has been defined as “lb” for load -balancer. - -.. code-block:: yaml - - parameters: - vnf\_name: - type: string - description: Unique name for this VNF instance - vnf\_id: - type: string - description: Unique ID for this VNF instance - vf\_module\_name: - type: string - description: Unique name for this VNF Module instance - vf\_module\_id: - type: string - description: Unique ID for this VNF Module instance - - resources: - lb\_server\_group: - type: OS::Nova::ServerGroup - properties: - name: - str\_replace: - template: VNF\_NAME\_lb\_ServerGroup - params: - VNF\_NAME: { get\_param: VNF\_name } - policies: [ ‘anti-affinity’ ] - - lb\_vm\_0: - type: OS::Nova::Server - properties: - name: { get\_param: lb\_name\_0 } - scheduler\_hints: - group: { get\_resource: lb\_server\_group } - metadata: - vnf\_name: { get\_param: vnf\_name } - vnf\_id: { get\_param: vnf\_id } - vf\_module\_name: { get\_param: vf\_module\_name } - vf\_module\_id: { get\_param: vf\_module\_id } - ... - -Resource: OS::Neutron::Port - Parameters ----------------------------------------- - -The following four OS::Neutron::Port Resource Property Parameters must -adhere to the OpenECOMP parameter naming convention. - -- network - -- subnet - -- fixed\_ips - -- allowed\_address\_pairs - -These four parameters reference a network, which maybe an external -network or an internal network. Thus the parameter will include -{network-role} in its name. - -When the parameter references an external network, the parameter is an -OpenECOMP Orchestration Parameter. The parameter value must be supplied -by OpenECOMP. The parameters must adhere to the OpenECOMP parameter -naming convention. - -+---------------------------+-----------------------------------------------+------------------+ -| OS::Neutron::Port | -+===========================+===============================================+==================+ -| Property | Parameter Name for External Networks | Parameter Type | -+---------------------------+-----------------------------------------------+------------------+ -| Network | {network-role}\_net\_id | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {network-role}\_net\_name | string | -+---------------------------+-----------------------------------------------+------------------+ -| Subnet | {network-role}\_subnet\_id | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {network-role}\_v6\_subnet\_id | string | -+---------------------------+-----------------------------------------------+------------------+ -| fixed\_ips | {vm-type}\_{network-role}\_ip\_{index} | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_ips | CDL | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_v6\_ip\_{index} | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_v6\_ips | CDL | -+---------------------------+-----------------------------------------------+------------------+ -| allowed\_address\_pairs | {vm-type}\_{network-role}\_floating\_ip | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_floating\_v6\_ip | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_ip\_{index} | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_ips | CDL | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_v6\_ip\_{index} | string | -+---------------------------+-----------------------------------------------+------------------+ -| | {vm-type}\_{network-role}\_v6\_ips | CDL | -+---------------------------+-----------------------------------------------+------------------+ - -Table 4 Port Resource Property Parameters (External Networks) - -When the parameter references an internal network, the parameter is a -VNF Orchestration Parameters. The parameter value(s) must be supplied -either via an output statement(s) in the base module (i.e., OpenECOMP -Base Template Output Parameters) or be enumerated in the environment -file. The parameters must adhere to the following parameter naming -convention. - -+---------------------------+----------------------------------------------------+------------------+ -| OS::Neutron::Port | -+===========================+====================================================+==================+ -| Property | Parameter Name for Internal Networks | Parameter Type | -+---------------------------+----------------------------------------------------+------------------+ -| Network | int\_{network-role}\_net\_id | string | -+---------------------------+----------------------------------------------------+------------------+ -| | int\_{network-role}\_net\_name | string | -+---------------------------+----------------------------------------------------+------------------+ -| Subnet | int\_{network-role}\_subnet\_id | string | -+---------------------------+----------------------------------------------------+------------------+ -| | Int\_{network-role}\_v6\_subnet\_id | string | -+---------------------------+----------------------------------------------------+------------------+ -| fixed\_ips | {vm-type}\_int\_{network-role}\_ip\_{index} | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_ips | CDL | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_v6\_ips | CDL | -+---------------------------+----------------------------------------------------+------------------+ -| allowed\_address\_pairs | {vm-type}\_int\_{network-role}\_floating\_ip | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_ip\_{index} | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_ips | CDL | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string | -+---------------------------+----------------------------------------------------+------------------+ -| | {vm-type}\_int\_{network-role}\_v6\_ips | CDL | -+---------------------------+----------------------------------------------------+------------------+ - -Table 5 Port Resource Property Parameters (Internal Networks) - -Property: network & subnet -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The property “networks” in the resource OS::Neutron::Port must be -referenced by Neutron Network ID, a UUID value, or by the network name -defined in OpenStack. - -When the parameter is referencing an “external” network, the parameter -must adhere to the following naming convention - -- *“{*\ network-role}\_net\_id”, for the Neutron network ID - -- “{network-role}\_net\_name”, for the network name in OpenStack - -When the parameter is referencing an “internal” network, the parameter -must adhere to the following naming convention. - -- “\ *int\_{network-role}\_net\_id*\ ”, for the Neutron network ID - -- “\ *int\_{network-role}\_net\_name*\ ”, for the network name in - OpenStack - -The property “subnet\_id” must be used if a DHCP IP address assignment -is being requested and the DHCP IP address assignment is targeted at a -specific subnet. - -The property “subnet\_id” should not be used if all IP assignments are -fixed, or if the DHCP assignment does not target a specific subnet - -When the parameter is referencing an “external” network subnet, the -“subnet\_id” parameter must adhere to the following naming convention. - -- “\ *{network-role}\_subnet\_id*\ ” if the subnet is an IPv4 subnet - -- “\ *{network-role}\_v6\_subnet\_id”* if the subnet is an IPv6 subnet - -When the parameter is referencing an “internal” network subnet, the -“subnet\_id” parameter must adhere to the following naming convention. - -- “\ *int\_{network-role}\_subnet\_id*\ ” if the subnet is an IPv4 - subnet - -- “\ *int\_{network-role}\_v6\_subnet\_id*\ ” if the subnet is an IPv6 - subnet - -*Example:* - -.. code-block:: yaml - - parameters: - {network-role}\_net\_id: - type: string - description: Neutron UUID for the {network-role} network - {network-role}\_net\_name: - type: string - description: Neutron name for the {network-role} network - {network-role}\_subnet\_id: - type: string - description: Neutron subnet UUID for the {network-role} network - {network-role}\_v6\_subnet\_id: - type: string - description: Neutron subnet UUID for the {network-role} network - -*Example:* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “lb” for -load balancer. - -.. code-block:: yaml - - parameters: - oam\_net\_id: - type: string - description: Neutron UUID for the oam network - - resources: - lb\_port\_1: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - -Property: fixed\_ips -~~~~~~~~~~~~~~~~~~~~ - -The property “fixed\_ips” in the resource OS::Neutron::Port must be used -when statically assigning IP addresses. - -An IP address is assigned to a port on a type of VM (i.e., {vm-type}) -that is connected to a type of network (i.e., {network-role}). These two -tags are components of the parameter name. - -When the “fixed\_ips” parameter is referencing an “external” network, -the parameter must adhere to the naming convention below. The parameter -may be a comma delimited list or a string. - -There must be a different parameter name for IPv4 IP addresses and IPv6 -addresses - -- **Comma-delimited list:** Each element in the IP list should be - assigned to successive instances of that VM type on that network. - - - *Format for IPv4 addresses:* {vm-type}\_{network-role}\_ips - - - *Format for IPv6 addresses:* {vm-type}\_{network-role}\_v6\_ips - -- **A set of fixed-index parameters:** In this case, the parameter - should have “\ *type: string*\ ” and must be repeated for every IP - expected for each {vm-type} + {network-role} pair. - - - *Format for IPv4 addresses:* - {vm-type}\_{network-role}\_ip\_{index} - - - *Format for IPv6 addresses:* - {vm-type}\_{network-role}\_v6\_ip\_{index} - -When the “fixed\_ips” parameter is referencing an “internal” network, -the parameter must adhere to the naming convention below. The parameter -may be a comma delimited list or a string. - -There must be a different parameter name for IPv4 IP addresses and IPv6 -addresses - -- **Comma-delimited list:** Each element in the IP list should be - assigned to successive instances of that VM type on that network. - - - *Format for IPv4 addresses:* {vm-type}\_int\_{network-role}\_ips - - - *Format for IPv6 addresses:* - {vm-type}\_int\_{network-role}\_v6\_ips - -- **A set of fixed-index parameters:** In this case, the parameter - should have “\ *type: string*\ ” and must be repeated for every IP - expected for each {vm-type} and {network-role}pair. - - - *Format for IPv4 addresses:* - {vm-type}\_int\_{network-role}\_ip\_{index} - - - *Format for IPv6 addresses:* - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} - -If a VNF contains more than three IP addresses for a given {vm-type} and -{network-role} combination, the CDL form of the parameter name should be -used to minimize the number of unique parameters defined in the Heat. - -*Example (external network)* - -.. code-block:: yaml - - parameters: - {vm-type}\_{network-role}\_ips: - type: comma\_delimited\_list - description: Fixed IPv4 assignments for {vm-type} VMs on the - {network-role} network - {vm-type}\_{network-role}\_v6\_ips: - type: comma\_delimited\_list - description: Fixed IPv6 assignments for {vm-type} VMs on the - {network-role} network - {vm-type}\_{network-role}\_ip\_{index}: - type: string - description: Fixed IPv4 assignment for {vm-type} VM {index} on the - {network-role} network - {vm-type}\_{network-role}\_v6\_ip\_{index}: - type: string - description: Fixed IPv6 assignment for {vm-type} VM {index} on the - {network-role} network - -*Example (CDL parameter for IPv4 Address Assignments to an external -network):* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “db” for -database. - -.. code-block:: yaml - - parameters: - oam\_net\_id: - type: string - description: Neutron UUID for a oam network - db\_oam\_ips: - type: comma\_delimited\_list - description: Fixed IP assignments for db VMs on the oam network - - resources: - db\_0\_port\_1: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [ db\_oam\_ips, 0] - }}] - db\_1\_port\_1: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [ db\_oam\_ips, 1] - }}] - -*Example (string parameters for IPv4 Address Assignments to an external -network):* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “db” for -database. - -.. code-block:: yaml - - parameters: - oam\_net\_id: - type: string - description: Neutron UUID for an OAM network - db\_oam\_ip\_0: - type: string - description: First fixed IP assignment for db VMs on the OAM network - db\_oam\_ip\_1: - type: string - description: Second fixed IP assignment for db VMs on the OAM network - - resources: - db\_0\_port\_1: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: db\_oam\_ip\_0}}] - db\_1\_port\_1: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: db\_oam\_ip\_1}}] - -Property: allowed\_address\_pairs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The property “allowed\_address\_pairs” in the resource OS::Neutron::Port -allows the user to specify mac\_address/ip\_address (CIDR) pairs that -pass through a port regardless of subnet. This enables the use of -protocols such as VRRP, which floats an IP address between two instances -to enable fast data plane failover. An “allowed\_address\_pairs” is -unique to a {vm-type} and {network-role} combination. The management of -these IP addresses (i.e. transferring ownership between active and -standby VMs) is the responsibility of the application itself. - -Note that these parameters are *not* intended to represent Neutron -“Floating IP” resources, for which OpenStack manages a pool of public IP -addresses that are mapped to specific VM ports. In that case, the -individual VMs are not even aware of the public IPs, and all assignment -of public IPs to VMs is via OpenStack commands. OpenECOMP does not -support Neutron-style Floating IPs. - -Both IPv4 and IPv6 “allowed\_address\_pairs” addresses are supported. - -If property “allowed\_address\_pairs” is used with an external network, -the parameter name must adhere to the following convention: - -- *Format for IPv4 addresses: {vm-type}\_{network-role}\_floating\_ip* - -- *Format for IPv6 addresses: - {vm-type}\_{network-role}\_floating\_v6\_ip* - -*Example:* - -.. code-block:: yaml - - parameters: - {vm-type}\_{network-role}\_floating\_ip: - type: string - description: VIP for {vm-type} VMs on the {network-role} network - {vm-type}\_{network-role}\_floating\_v6\_ip: - type: string - description: VIP for {vm-type} VMs on the {network-role} network - -*Example:* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “db” for -database. - -.. code-block:: yaml - - parameters: - db\_oam\_ips: - type: comma\_delimited\_list - description: Fixed IPs for db VMs on the oam network - db\_oam\_floating\_ip: - type: string - description: Floating IP for db VMs on the oam network - resources: - db\_0\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,0] }}] - allowed\_address\_pairs: [ - { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}] - db\_1\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,1] }}] - allowed\_address\_pairs: [ - { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}] - -If property “allowed\_address\_pairs” is used with an internal network, -the parameter name should adhere to the following convention: - -- *Format for IPv4 addresses: - {vm-type}\_int\_{network-role}\_floating\_ip* - -- *Format for IPv6 addresses: - {vm-type}\_int\_{network-role}\_floating\_v6\_ip* - -Using the parameter *{vm-type}\_{network-role}\_floating\_ip* or -*{vm-type}\_{network-role}\_floating\_v6\_ip* provides only one floating -IP per Vm-type{vm-type} and {network-role} pair. If there is a need for -multiple floating IPs (e.g., Virtual IPs (VIPs)) for a given {vm-type} -and {network-role} combination within a VNF, then the parameter names -defined for the “fixed\_ips” should be used with the -“allowed\_address\_pairs” property. The examples below illustrate this. - -Below example reflects two load balancer pairs in a single VNF. Each -pair has one VIP. - -*Example: A VNF has four load balancers. Each pair has a unique VIP.* - -*Pair 1:* lb\_0 and lb\_1 share a unique VIP - -*Pair 2:* lb\_2 and lb\_3 share a unique VIP - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “lb” for -load balancer. - -.. code-block:: yaml - - resources: - lb\_0\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,0] }}] - allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,2] }}] - - lb\_1\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,1] }}] - allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,2] }}] - - lb\_2\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,3] }}] - allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,5] }}] - - lb\_3\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,4] }}] - allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,5] }}] - -Below example reflects a single app VM pair within a VNF with two VIPs: - -*Example: A VNF has two load balancers. The pair of load balancers share -two VIPs.* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “lb” for -load balancer. - -.. code-block:: yaml - - resources: - lb\_0\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,0] }}] - allowed\_address\_pairs: [{ "ip\_address": {get\_param: [lb\_oam\_ips,2] }, {get\_param: [lb\_oam\_ips,3] }}] - - lb\_1\_port\_0: - type: OS::Neutron::Port - network: { get\_param: oam\_net\_id } - fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,1] }}] - allowed\_address\_pairs: [{ "ip\_address": {get\_param: [lb\_oam\_ips,2] }, {get\_param: [lb\_oam\_ips,3] }}] - -As a general rule, provide the fixed IPs for the VMs indexed first in -the CDL and then the VIPs as shown in the examples above. - -Resource Property: name ------------------------ - -The parameter naming standard for the resource OS::Nova::Server has been -defined in Section 4.3.3. This section describes how the name property -of all other resources must be defined. - -Heat templates must use the Heat “str\_replace” function in conjunction -with the OpenECOMP supplied metadata parameter *vnf\_name* or -*vnf\_module\_id* to generate a unique name for each VNF instance. This -prevents the use of unique parameters values for resource “name” -properties to be enumerated in a per instance environment file. - -Note that - -- In most cases, only the use of the vnf\_name is necessary to create a - unique name - -- the Heat pseudo parameter 'OS::stack\_name’ can also be used in the - ‘str\_replace’ construct to generate a unique name when the vnf\_name - does not provide uniqueness - -.. code-block:: yaml - - type: OS::Cinder::Volume - properities: - name: - str\_replace: - template: VF\_NAME\_STACK\_NAME\_oam\_volume - params: - VF\_NAME: { get\_param: vnf\_name } - STACK\_NAME: { get\_param: 'OS::stack\_name' } - - type: OS::Neutron::SecurityGroup - properties: - description: Security Group of Firewall - name: - str\_replace: - template: VNF\_NAME\_Firewall\_SecurityGroup - params: - VNF\_NAME: { get\_param: vnf\_name } - -Output Parameters ------------------ - -OpenECOMP defines three type of Output Parameters. - -Base Template Output Parameters: -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The base template output parameters are available for use as input -parameters in all add-on modules. The add-on modules may (or may not) -use these parameters. - -Volume Template Output Parameters: -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The volume template output parameters are only available only for the -module (base or add on) that the volume is associated with. - -Predefined Output Parameters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -OpenECOMP currently defines one predefined output parameter. - -OAM Management IP Addresses -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Many VNFs will have a management interface for application controllers -to interact with and configure the VNF. Typically, this will be via a -specific VM that performs a VNF administration function. The IP address -of this interface must be captured and inventoried by OpenECOMP. This -might be a VIP if the VNF contains an HA pair of management VMs, or may -be a single IP address assigned to one VM. - -The Heat template may define either (or both) of the following Output -parameters to identify the management IP address. - -- *oam\_management\_v4\_address* - -- *oam\_management\_v6\_address* - -*Notes*: - -- The Management IP Address should be defined only once per VNF, so it - would only appear in one Module template - -- If a fixed IP for the admin VM is passed as an input parameter, it - may be echoed in the output parameters - -- If the IP for the admin VM is obtained via DHCP, it may be obtained - from the resource attributes - -*Example:* - -.. code-block:: yaml - - resources: - admin\_server: - type: OS::Nova::Server - properties: - networks: - - network: {get\_param: oam\_net\_id } - ... - - Outputs: - oam\_management\_v4\_address: - value: {get\_attr: [admin\_server, networks, {get\_param: oam\_net\_id}, 0] } - -Heat Template Constructs -======================== - -External References -------------------- - -Heat templates *should not* reference any HTTP-based resource -definitions, any HTTP-based nested configurations, or any HTTP-based -environment files. - -- During orchestration, OpenECOMP *should not* retrieve any such - resources from external/untrusted/unknown sources. - -- VNF images should not contain such references in user-data or other - configuration/operational scripts that are specified via Heat or - encoded into the VNF image itself. - -*Note:* HTTP-based references are acceptable if the HTTP-based reference -is accessing information with the VM private/internal network. - -Heat Files Support (get\_file) ------------------------------- - -Heat Templates may contain the inclusion of text files into Heat -templates via the Heat “get\_file” directive. This may be used, for -example, to define a common “user-data” script, or to inject files into -a VM on startup via the “personality” property. - -Support for Heat Files is subject to the following limitations: - -- The ‘get\_files’ targets must be referenced in Heat templates by file - name, and the corresponding files should be delivered to OpenECOMP - along with the Heat templates. - - - URL-based file retrieval must not be used; it is not supported. - -- The included files must have unique file names within the scope of - the VNF. - -- OpenECOMP does not support a directory hierarchy for included files. - - - All files must be in a single, flat directory per VNF. - -- Included files may be used by all Modules within a given VNF. - -- get\_file directives may be used in both non-nested and nested - templates - -Use of Heat ResourceGroup -------------------------- - -The *OS::Heat::ResourceGroup* is a useful Heat element for creating -multiple instances of a given resource or collection of resources. -Typically it is used with a nested Heat template, to create, for -example, a set of identical *OS::Nova::Server* resources plus their -related *OS::Neutron::Port* resources via a single resource in a master -template. - -*ResourceGroup* may be used in OpenECOMP to simplify the structure of a -Heat template that creates multiple instances of the same VM type. -However, there are important caveats to be aware of. - -*ResourceGroup* does not deal with structured parameters -(comma-delimited-list and json) as one might typically expect. In -particular, when using a list-based parameter, where each list element -corresponds to one instance of the *ResourceGroup*, it is not possible -to use the intrinsic “loop variable” %index% in the *ResourceGroup* -definition. - -For instance, the following is **not** valid Heat for a *ResourceGroup*: - -.. code-block:: yaml - - type: OS::Heat::ResourceGroup - resource: - type: my\_nested\_vm\_template.yaml - properties: - name: {get\_param: [vm\_name\_list, %index%]} - -Although this appears to use the nth entry of the *vm\_name\_list* list -for the nth element of the *ResourceGroup*, it will in fact result in a -Heat exception. When parameters are provided as a list (one for each -element of a *ResourceGroup*), you must pass the complete parameter to -the nested template along with the current index as separate parameters. - -Below is an example of an **acceptable** Heat Syntax for a -*ResourceGroup*: - -.. code-block:: yaml - - type: OS::Heat::ResourceGroup - resource: - type: my\_nested\_vm\_template.yaml - properties: - names: {get\_param: vm\_name\_list} - index: %index% - -You can then reference within the nested template as: - -{ get\_param: [names, {get\_param: index} ] } - -Note that this is workaround has very important limitations. Since the -entire list parameter is passed to the nested template, any change to -that list (e.g., adding an additional element) will cause Heat to treat -the entire parameter as updated within the context of the nested -template (i.e., for each *ResourceGroup* element). As a result, if -*ResourceGroup* is ever used for scaling (e.g., increment the count and -include an additional element to each list parameter), Heat will often -rebuild every existing element in addition to adding the “deltas”. For -this reason, use of *ResourceGroup* for scaling in this manner is not -supported. - -Key Pairs ---------- - -When Nova Servers are created via Heat templates, they may be passed a -“keypair” which provides an ssh key to the ‘root’ login on the newly -created VM. This is often done so that an initial root key/password does -not need to be hard-coded into the image. - -Key pairs are unusual in OpenStack, because they are the one resource -that is owned by an OpenStack User as opposed to being owned by an -OpenStack Tenant. As a result, they are usable only by the User that -created the keypair. This causes a problem when a Heat template attempts -to reference a keypair by name, because it assumes that the keypair was -previously created by a specific OpenECOMP user ID. - -When a keypair is assigned to a server, the SSH public-key is -provisioned on the VMs at instantiation time. They keypair itself is not -referenced further by the VM (i.e. if the keypair is updated with a new -public key, it would only apply to subsequent VMs created with that -keypair). - -Due to this behavior, the recommended usage of keypairs is in a more -generic manner which does not require the pre-requisite creation of a -keypair. The Heat should be structured in such a way as to: - -- Pass a public key as a parameter value instead of a keypair name - -- Create a new keypair within the VNF Heat templates (in the base - module) for use within that VNF - -By following this approach, the end result is the same as pre-creating -the keypair using the public key – i.e., that public key will be -provisioned in the new VM. However, this recommended approach also makes -sure that a known public key is supplied (instead of having OpenStack -generate a public/private pair to be saved and tracked outside of -OpenECOMP). It also removes any access/ownership issues over the created -keypair. - -The public keys may be enumerated as a VNF Orchestration Constant in the -environment file (since it is public, it is not a secret key), or passed -at run-time as an instance-specific parameters. OpenECOMP will never -automatically assign a public/private key pair. - -*Example (create keypair with an existing ssh public-key for {vm-type} -of lb (for load balancer)):* - -.. code-block:: yaml - - parameters: - vnf\_name: - type: string - ssh\_public\_key: - type: string - resources: - my\_keypair: - type: OS::Nova::Keypair - properties: - name: - str\_replace: - template: VNF\_NAME\_key\_pair - params: - VNF\_NAME: { get\_param: vnf\_name } - public\_key: {get\_param: lb\_ssh\_public\_key} - save\_private\_key: false - -Security Groups ---------------- - -OpenStack allows a tenant to create Security groups and define rules -within the security groups. - -Security groups, with their rules, may either be created in the Heat -template or they can be pre-created in OpenStack and referenced within -the Heat template via parameter(s). There can be a different approach -for security groups assigned to ports on internal (intra-VNF) networks -or external networks (inter-VNF). Furthermore, there can be a common -security group across all VMs for a specific network or it can vary by -VM (i.e., {vm-type}) and network type (i.e., {network-role}). - -Anti-Affinity and Affinity Rules --------------------------------- - -Anti-affinity or affinity rules are supported using normal OpenStack -*“OS::Nova::ServerGroup”* resources. Separate ServerGroups are typically -created for each VM type to prevent them from residing on the same host, -but they can be applied to multiple VM types to extend the -affinity/anti-affinity across related VM types as well. - -*Example:* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} have been defined as “lb” for -load balancer and “db” for database. - -.. code-block:: yaml - - resources: - db\_server\_group: - type: OS::Nova::ServerGroup - properties: - name: - str\_replace: - params: - $vnf\_name: {get\_param: vnf\_name} - template: $vnf\_name-server\_group1 - policies: - - *anti-affinity* - - lb\_server\_group: - type: OS::Nova::ServerGroup - properties: - name: - str\_replace: - params: - $vnf\_name: {get\_param: vnf\_name} - template: $vnf\_name-server\_group2 - policies: - - *affinity* - - *db\_0:* - *type: OS::Nova::Server* - *properties:* - *...* - scheduler\_hints: - group: {get\_param: db\_server\_group} - - db\_1: - type: OS::Nova::Server - properties: - ... - scheduler\_hints: - group: {get\_param: db\_server\_group} - - lb\_0: - type: OS::Nova::Server - properties: - ... - scheduler\_hints: - group: {get\_param: lb\_server\_group} - -Design Pattern: VNF Modularity -============================== - -OpenECOMP supports the concept of *VNF Modularity*. With this approach, -a single VNF may be composed from one or more Heat templates, each of -which represents some subset of the overall VNF. These component parts -are referred to as “\ *VNF Modules*\ ”. During orchestration, these -modules may be deployed incrementally to build up the complete VNF. - -A Heat template can be either one for the following types of modules - -1. Base Module - -2. Incremental Modules - -3. Independent Cinder Volume Modules - -The OpenECOMP Heat template naming convention must be followed (Section -2.1). The naming convention identifies the module type. - -A VNF must be composed of one “base” VNF module (also called a base -module) and zero to many “incremental” or “add on” VNF modules. The base -module must be deployed first prior to the add-on modules. - -A module can be thought of as equivalent to a Heat template, where a -Heat template is composed of a YAML file and an environment file. A -given YAML file must have a corresponding environment file; OpenECOMP -requires it. A Heat template is used to create or deploy a Heat stack. -Therefore, a module is also equivalent to a Heat Stack. - -However, there are cases where a module maybe composed of more than one -Heat stack and/or more than one YAML file. - -As discussed in Section 2.5, Independent Volume Templates, each VNF -Module may have an associated Volume template. - -- When a volume template is utilized, it must correspond 1:1 with - add-on module template or base template it is associated with - -- A Cinder volume may be embedded within the add-on module template - and/or base template if persistence is not required, thus not - requiring the optional Volume template. - -A VNF module may support nested templates. In this case, there will be -one or more additional YAML files. - -Any shared resource defined in the base module template and used across -the entire VNF (e.g., private networks, server groups), must be exposed -to the incremental or add-on modules by declaring their resource UUIDs -as Heat outputs (i.e., OpenECOMP Base Template Output Parameter in the -output section of the Heat template). Those outputs will be provided by -OpenECOMP as input parameter values to all add-on module Heat templates -in the VNF that have declared the parameter in the template. - -*Note:* A Cinder volume is *not* considered a shared resource. A volume -template must correspond 1:1 with a base template or add-on module -template. - -There are two suggested usage patterns for modular VNFs, though any -variation is supported. - -A. **Modules per VNFC type** - - a. Group all VMs (VNFCs) of a given type into its own module - - b. Build up the VNF one VNFC type at a time - - c. Base module contains only the shared resources (and possibly - initial Admin VMs) - - d. Suggest one or two modules per VNFC type - - i. one for initial count - - ii. one for scaling increment (if different from initial count) - -B. **Base VNF + Growth Units** - - a. Base module (template) contains a complete initial VNF instance - - b. Growth modules for incremental scaling units - - i. May contain VMs of multiple types in logical scaling - combinations - - ii. May be separated by VM type for multi-dimensional scaling - - c. With no growth units, this is equivalent to the “\ *One Heat - Template per VNF*\ ” model - -Note that modularization of VNFs is not required. A single Heat template -(a base template) may still define a complete VNF, which might be -appropriate for smaller VNFs without a lot of scaling options. - -There are some rules to follow when building modular VNF templates: - -1. All VNFs must have one Base VNF Module (template) that must be the - first one deployed. The base template: - - a. Must include all shared resources (e.g., private networks, server - groups, security groups) - - b. Must expose all shared resources (by UUID) as “outputs” in its - associated Heat template (i.e., OpenECOMP Base Template Output - Parameters) - - c. May include initial set of VMs - - d. May be operational as a stand-alone “minimum” configuration of the - VNF - -2. VNFs may have one or more Add-On VNF Modules (templates) which: - - a. Defines additional resources that can be added to an existing VNF - - b. Must be complete Heat templates - - i. i.e. not snippets to be incorporated into some larger template - - c. Should define logical growth-units or sub-components of an overall - VNF - - d. On creation, receives all Base VNF Module outputs as parameters - - i. Provides access to all shared resources (by UUID) - - ii. must not be dependent on other Add-On VNF Modules - - e. Multiple instances of an Add-On VNF Module type may be added to - the same VNF (e.g. incrementally grow a VNF by a fixed “add-on” - growth units) - -3. Each VNF Module (base or add-on) may have (optional) an associated - Volume template (*see Section 2.5*) - - a. Volume templates should correspond 1:1 with Module (base or - add-on) templates - - b. A Cinder volume may be embedded within the Module template (base - or add-on) if persistence is not required - -4. Shared resource UUIDs are passed between the base template and add-on - template via Heat Outputs Parameters (i.e., Base Template Output - Parameters) - - a. The output parameter name in the base must match the parameter - name in the add-on module - -*Examples:* - -In this example, the {vm-type} have been defined as “lb” for load -balancer and “admin” for admin server. - -1. **Base VNF Module Heat Template (partial)** - -Heat\_template\_version: 2013-05-23 - -.. code-block:: yaml - - parameters: - admin\_name\_0: - type: string - - resources: - int\_oam\_network: - type: OS::Neutron::Network - properties: - name: {… } - - admin\_server: - type: OS::Nova::Server - properties: - name: {get\_param: admin\_name\_0} - image: ... - - outputs: - int\_oam\_net\_id: - value: {get\_resource: int\_oam\_network } - - -2. **Add-on VNF Module Heat Template (partial)** - -Heat\_template\_version: 2013-05-23 - -.. code-block:: yaml - - Parameters: - int\_oam\_net\_id: - type: string - description: ID of shared private network from Base template - lb\_name\_0: - type: string - description: name for the add-on VM instance - - Resources: - lb\_server: - type: OS::Nova::Server - properties: - name: {get\_param: lb\_name\_0} - networks: - - port: { get\_resource: lb\_port } - ... - - lb\_port: - type: OS::Neutron::Port - properties: - network\_id: { get\_param: int\_oam\_net\_id } - ... - -Scaling Considerations -====================== - -Scaling of a VNF may be manually driven to add new capacity (**static -scaling**) or it may be driven in near real-time by the OpenECOMP -controllers based on a real-time need **(dynamic scaling).** - -With VNF Modularity, the recommended approach for scaling is to provide -additional “growth unit” templates that can be used to create additional -resources in logical scaling increments. This approach is very -straightforward, and has minimal impact on the currently running VNFCs -and must comply with the following: - -- Combine resources into reasonable-sized scaling increments; do not - just scale by one VM at a time in potentially large VNFs. - -- Combine related resources into the same growth template where - appropriate, e.g. if VMs of different types are always deployed in - pairs, include them in a single growth template. - -- Growth templates can use the private networks and other shared - resources exposed by the Base Module template. - -VNF Modules may also be updated “in-place” using the OpenStack Heat -Update capability, by deploying an updated Heat template with different -VM counts to an existing stack. This method requires another VNF module -template that includes the new resources *in addition to all resources -contained in the original module template*. Note that this also requires -re-specification of all existing parameters as well as new ones. - -*For this approach:* - -- Use a fixed number of pre-defined VNF module configurations - -- Successively larger templates must be identical to the next smaller - one, plus add the additional VMs of the scalable type(s) - -- VNF is scalable by sending a stack-update with a different template - -*Please do note that:* - -- If properties do not change for existing VMs, those VMs should remain - unchanged - -- If the update is performed with a smaller template, the Heat engine - recognizes and deletes no-longer-needed VMs (and associated - resources) - -- Nested templates for the various server types will simplify reuse - across multiple configurations - -- Per the section on Use of Heat ResourceGroup, if *ResourceGroup* is - ever used for scaling (e.g. increment the count and include an - additional element to each list parameter), Heat will often rebuild - every existing element in addition to adding the “deltas”. For this - reason, use of *ResourceGroup* for scaling in this manner is not - supported. - -High Availability -================== - -VNF/VM parameters may include availability zone IDs for VNFs that -require high availability. - -The Heat must comply with the following requirements to specific -availability zone IDs: - -- The Heat template should spread Nova and Cinder resources across the - availability zones as desired - -Resource Data Synchronization -============================== - -For cases where synchronization is required in the orchestration of Heat -resources, two approaches are recommended: - -- Standard Heat *“depends\_on”* property for resources - - - Assures that one resource completes before the dependent resource - is orchestrated. - - - Definition of completeness to OpenStack may not be sufficient - (e.g., a VM is considered complete by OpenStack when it is ready - to be booted, not when the application is up and running). - -- Use of Heat Notifications - - - Create *OS::Heat::WaitCondition* and - *OS::Heat::WaitConditionHandle* resources. - - - Pre-requisite resources issue *wc\_notify* commands in user\_data. - - - Dependent resource define *“depends\_on”* in the - *OS::Heat::WaitCondition* resource. - -*Example: “depends\_on” case* - -In this example, the {network-role} has been defined as “oam” to -represent an oam network and the {vm-type} has been defined as “oam” to -represent an oam server. - -.. code-block:: yaml - - oam\_server\_01: - type: OS::Nova::Server - properties: - name: {get\_param: [oam\_ names, 0]} - image: {get\_param: oam\_image\_name} - flavor: {get\_param: oam\_flavor\_name} - availability\_zone: {get\_param: availability\_zone\_0} - networks: - - port: {get\_resource: oam01\_port\_0} - - port: {get\_resource: oam01\_port\_1} - user\_data: - scheduler\_hints: {group: {get\_resource: oam\_servergroup}} - user\_data\_format: RAW - - oam\_01\_port\_0: - type: OS::Neutron::Port - properties: - network: {get\_resource: oam\_net\_name} - fixed\_ips: [{"ip\_address": {get\_param: [oam\_oam\_net\_ips, 1]}}] - security\_groups: [{get\_resource: oam\_security\_group}] - - oam\_01\_port\_1: - type: OS::Neutron::Port - properties: - network: {get\_param: oam\_net\_name} - fixed\_ips: [{"ip\_address": {get\_param: [oam\_oam\_net\_ips, 2]}}] - security\_groups: [{get\_resource: oam\_security\_group}] - - - - oam\_01\_vol\_attachment: - type: OS::Cinder::VolumeAttachment - depends\_on: oam\_server\_01 - properties: - volume\_id: {get\_param: oam\_vol\_1} - mountpoint: /dev/vdb - instance\_uuid: {get\_resource: oam\_server\_01} - -Appendix A - Glossary -====================== - -**VM** Virtual Machine (VM) is a virtualized computation environment -that behaves very much like a physical computer/server. A VM has all its -ingredients (processor, memory/storage, interfaces/ports) of a physical -computer/server and is generated by a hypervisor, which partitions the -underlying physical resources and allocates them to VMs. Virtual -Machines are capable of hosting a virtual network function component -(VNFC). - -**VNF** Virtual Network Function (VNF) is the software implementation of -a function that can be deployed on a Network Cloud. It includes network -functions that provide transport and forwarding. It also includes other -functions when used to support network services, such as -network-supporting web servers and database. - -**VNFC** Virtual Network Function Component (VNFC) are the -sub-components of a VNF providing a VNF Provider a defined sub-set of -that VNF's functionality, with the main characteristic that a single -instance of this component maps 1:1 against a single Virtualization -Container. See **Figure 1** for the relationship between VNFC and -VNFs. - -|image0| - -Figure 1. Virtual Function Entity Relationship - - -**Copyright © 2017 AT&T Intellectual Property. All rights reserved.** - -Unless otherwise specified, all software contained herein is licensed -under the Apache License, Version 2.0 (the “License”); -you may not use this software except in compliance with the License. -You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, software -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. - -Unless otherwise specified, all documentation contained herein is licensed -under the Creative Commons License, Attribution 4.0 Intl. (the “License”); -you may not use this documentation except in compliance with the License. -You may obtain a copy of the License at - - https://creativecommons.org/licenses/by/4.0/ - -Unless required by applicable law or agreed to in writing, documentation -distributed under the License is distributed on an "AS IS" BASIS, -WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -See the License for the specific language governing permissions and -limitations under the License. - -ECOMP is a trademark and service mark of AT&T Intellectual Property. - -.. |image0| image:: VNF_VNFC_Relation.jpg - :width: 4.26181in - :height: 3.42847in -
\ No newline at end of file |