diff options
Diffstat (limited to 'docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp')
4 files changed, 2256 insertions, 0 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.docx 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.docx Binary files differnew file mode 100644 index 0000000..4ed205a --- /dev/null +++ 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.docx 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 new file mode 100644 index 0000000..d022032 --- /dev/null +++ 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 @@ -0,0 +1,2249 @@ +.. 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:: python + + 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:: python + + outputs: + {vm-type}\_volume\_id\_0: + value: {get\_resource: {vm-type}\_volume\_0} + ... + +*(+ additional volume outputs)* + +*Example (VNF module template):* + +.. code-block:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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:: python + + 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.** + +This paper is licensed to you under the Creative Commons License: + +**Creative Commons Attribution-ShareAlike 4.0 International Public +License** + +You may obtain a copy of the License at: + +https://creativecommons.org/licenses/by-sa/4.0/legalcode + +**You are free to:** + +- Share — copy and redistribute the material in any medium or format + +- Adapt — remix, transform, and build upon the material for any + purpose, even commercially. + +- The licensor cannot revoke these freedoms as long as you follow the + license terms. + +**Under the following terms:** + +- Attribution — You must give appropriate credit, provide a link to the + license, and indicate if changes were made. You may do so in any + reasonable manner, but **not** in any way that suggests the + licensor endorses you or your use. + +- ShareAlike — If you remix, transform, or build upon the material, you + must distribute your contributions under the same license as the + original. + +- No additional restrictions — You may not apply legal terms or + technological measures that legally restrict others from doing + anything the license permits. + +**Notices:** + +- You do not have to comply with the license for elements of the + material in the public domain or where your use is permitted by an + applicable exception or limitation. + +- No warranties are given. The license may not give you all of the + permissions necessary for your intended use. For example, other + rights such as publicity, privacy, or moral rights may limit how you + use the material. + +.. |image0| image:: VNF_VNFC_Relation.jpg + :width: 4.26181in + :height: 3.42847in +
\ No newline at end of file diff --git a/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_VNFC_Relation.jpg b/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_VNFC_Relation.jpg Binary files differnew file mode 100644 index 0000000..0457e86 --- /dev/null +++ b/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/VNF_VNFC_Relation.jpg diff --git a/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/index.rst b/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/index.rst new file mode 100644 index 0000000..51e1391 --- /dev/null +++ b/docs/all_vnfrqts_seed_docs/open_ecomp/inital_seed_ecomp/VNF_Heat_Templates_for_OpenEcomp/index.rst @@ -0,0 +1,7 @@ +VNF Heat Templates for OpenEcomp +----------------------------------- + +.. toctree:: + :maxdepth: 2 + + VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes
\ No newline at end of file |