diff options
Diffstat (limited to 'docs/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst')
| -rw-r--r-- | docs/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst | 2249 |
1 files changed, 2249 insertions, 0 deletions
diff --git a/docs/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst b/docs/VNF_Heat_Templates_for_OpenEcomp/VNF_Heat_Template_Requirements_for_OpenECOMP_2_15_NO_track_changes.rst new file mode 100644 index 0000000..a6147e9 --- /dev/null +++ b/docs/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 |