-**5. VNF Modeling Requirements**
-=====================================
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-a. TOSCA YAML
-=============
+
+VNF Modeling Requirements
+=========================
+
+TOSCA YAML
+----------
Introduction
--------------
+^^^^^^^^^^^^^^
This reference document is the VNF TOSCA Template Requirements for
-OpenO, which provides recommendations and standards for building VNF
-TOSCA templates compatible with OpenO– initial implementations of
+ONAP, which provides recommendations and standards for building VNF
+TOSCA templates compatible with ONAP initial implementations of
Network Cloud. It has the following features:
1. VNF TOSCA template designer supports GUI and CLI.
2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
Draft 04-Revision 06”.
-3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
+3. VNF TOSCA template supports HPA features, such as NUMA, Hyper
Threading, SRIOV， etc.
Intended Audience
------------------
+^^^^^^^^^^^^^^^^^^
This document is intended for persons developing VNF TOSCA templates
-that will be orchestrated by OpenO.
+that will be orchestrated by ONAP.
-Scope
-------
+Scope
+^^^^^^^^^^^^^^^^
-OpenO implementations of Network Cloud supports TOSCA Templates, also
+ONAP implementations of Network Cloud supports TOSCA Templates, also
referred to as TOSCA in this document.
-OpenO requires the TOSCA Templates to follow a specific format. This
+ONAP requires the TOSCA Templates to follow a specific format. This
document provides the mandatory, recommended, and optional requirements
associated with this format.
-Overview
----------
+Overview
+^^^^^^^^^^^^^^^^
-The document includes three charters to help the VNF vendors to use the
+The document includes three charters to help the VNF providers to use the
VNF model design tools and understand the VNF package structure and VNF
TOSCA templates.
-In the OPENO, VNF Package and VNFD template can be designed by manually
+In the ONAP, VNF Package and VNFD template can be designed by manually
or via model designer tools. VNF model designer tools can provide the
-GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD
+GUI and CLI tools for the VNF provider to develop the VNF Package and VNFD
template.
The VNF package structure is align to the NFV TOSCA protocol, and
self-defined node or other extensions.
NFV TOSCA Template
-------------------
+^^^^^^^^^^^^^^^^^^^^
-TOSCA templates supported by OPENO must follow the requirements
+TOSCA templates supported by ONAP must follow the requirements
enumerated in this section.
TOSCA Introduction
-------------------
+^^^^^^^^^^^^^^^^^^^
TOSCA defines a Meta model for defining IT services. This Meta model
defines both the structure of a service as well as how to manage it. A
how many times the component can occur.
|image1|
-Figure 1: Structural Elements of Service Template and their Relations
+
+Figure 1: Structural Elements of Service Template and their Relations
TOSCA Modeling Principles & Data Model
---------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section describing TOSCA modeling principles and data model for
NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
V1.0], or new type based on ETSI NFV requirements, etc.
VNF Descriptor Template
------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
The VNF Descriptor (VNFD) describes the topology of the VNF by means of
ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
The following table defines the TOSCA Type “derived from” values that
SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
-specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
-
-+-----------------------------------------+---------------------------------------+-----------------------+
-| **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
-| | | |
-| **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
-+=========================================+=======================================+=======================+
-| VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Virtual Storage | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Virtual Compute | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Software Image | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Deployment Flavour | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Scaling Aspect | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Element Group | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
-| Instantiation Level | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
+specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD with aggreed
+changes from ETSI SOL001 draft.
+
++---------------------+------------------------------------+-----------------+
+| **ETSI NFV Element**| **TOSCA VNFD** | **Derived from**|
+| | | |
+| **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]**| |
++=====================+====================================+=================+
+| VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root|
++---------------------+------------------------------------+-----------------+
+| Cpd (Connection | tosca.nodes.nfv.Cp | tosca.nodes.Root|
+| Point) | tosca.nodes.nfv.Cp | tosca.nodes.Root|
++---------------------+------------------------------------+-----------------+
+| VduCpd (internal | tosca.nodes.nfv.VduCp | tosca.nodes.\ |
+| connection point) | | nfv.Cp |
++---------------------+------------------------------------+-----------------+
+| VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLink | tosca.nodes.Root|
+| (Virtual Link) | | |
++---------------------+------------------------------------+-----------------+
+| VDU Virtual Storage | tosca.nodes.nfv.VDU.VirtualStorage | tosca.nodes.Root|
++---------------------+------------------------------------+-----------------+
+| VDU Virtual Compute | tosca.nodes.nfv.VDU.Compute | tosca.nodes.Root|
++---------------------+------------------------------------+-----------------+
+| Software Image | | |
++---------------------+------------------------------------+-----------------+
+| Deployment Flavour | | |
++---------------------+------------------------------------+-----------------+
+| Scaling Aspect | | |
++---------------------+------------------------------------+-----------------+
+| Element Group | | |
++---------------------+------------------------------------+-----------------+
+| Instantiation | | |
+| Level | | |
++---------------------+------------------------------------+-----------------+
+
+--------------------------------------------------------------------+
| +--------------------------------------------------------------+ |
+====================================================================+
+--------------------------------------------------------------------+
-EPA Requirements
-----------------
+HPA Requirements
+^^^^^^^^^^^^^^^^^^
1. SR-IOV Passthrought
+------------------------------------------------------+
NFV TOSCA Type Definition
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tosca.capabilites.nfv.VirtualCompute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+---------------------------+-----------------------------------------+
-| **Shorthand Name** | VirtualCompute |
-+===========================+=========================================+
-| **Type Qualified Name** | tosca: VirtualCompute |
-+---------------------------+-----------------------------------------+
-| **Type URI** | tosca.capabilities.nfv.VirtualCompute |
-+---------------------------+-----------------------------------------+
-| **derived from** | tosca.nodes.Root |
-+---------------------------+-----------------------------------------+
-
-Properties
-^^^^^^^^^^
-
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
-+=====================================+============+=====================================================+===============+=========================================================+
-| request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-| virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-| virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-| name | yes | | | |
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
-
-Definition
-^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+-----------------------------------------------------------+
-| tosca.capabilities.nfv.VirtualCompute: |
-| |
-| derived\_from: tosca.capabilities.Root |
-| |
-| properties: |
-| |
-| requested\_additional\_capabilities: |
-| |
-| type: map |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatypes.nfv.RequestedAdditionalCapability |
-| |
-| required: false |
-| |
-| virtual\_memory: |
-| |
-| type: tosca.datatypes.nfv.VirtualMemory |
-| |
-| required: true |
-| |
-| virtual\_cpu: |
-| |
-| type: tosca.datatypes.nfv.VirtualCpu |
-| |
-| required: true |
-+-----------------------------------------------------------+
+This capability is used with the properties specified in ETSI SOL001 draft.
tosca.nodes.nfv.VDU.Compute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NFV Virtualization Deployment Unit (VDU) compute node type
represents a VDU entity which it describes the deployment and
Attributes
-^^^^^^^^^^
+++++++++++++
None
Capabilities
-^^^^^^^^^^^^
-
-+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
-| Name | Type | Constraints | Description |
-+=========================+=================================================+===============+=====================================================================================================+
-| virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
-+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
-| monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
-| | | | |
-| | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
-+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
-| Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
-| | | | |
-| | editor note: need to create a capability type | | |
-+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
+++++++++++++++
+
++------------+--------------------+------------+------------------------------+
+| Name | Type | Constraints| Description |
++============+====================+============+==============================+
+| virtual\ | tosca.\ | | Describes virtual compute |
+| _compute | capabilities.nfv.\ | | resources capabilities. |
+| | VirtualCompute | | |
++------------+--------------------+------------+------------------------------+
+| monitoring\| tosca.\ | None | Monitoring parameter, which |
+| _parameter | capabilities.nfv.\ | | can be tracked for a VNFC |
+| | Metric | | based on this VDU |
+| | | | |
+| | | | Examples include: |
+| | | | memory-consumption, |
+| | | | CPU-utilisation, |
+| | | | bandwidth-consumption, VNFC |
+| | | | downtime, etc. |
++------------+--------------------+------------+------------------------------+
+| Virtual\ | tosca.\ | | Defines ability of |
+| _binding | capabilities.nfv.\ | | VirtualBindable |
+| | VirtualBindable | | |
+| | | | |
+| | editor note: need | | |
+| | to create a | | |
+| | capability type | | |
++------------+--------------------+------------+------------------------------+
Definition
-^^^^^^^^^^
-
-+-----------------------------------------------------------------------------------------------------+
-| tosca.nodes.nfv.VDU.Compute: |
-| |
-| derived\_from: tosca.nodes.Compute |
-| |
-| properties: |
-| |
-| name: |
-| |
-| type: string |
-| |
-| required: true |
-| |
-| description: |
-| |
-| type: string |
-| |
-| required: true |
-| |
-| boot\_order: |
-| |
-| type: list # explicit index (boot index) not necessary, contrary to IFA011 |
-| |
-| entry\_schema: |
-| |
-| type: string |
-| |
-| required: false |
-| |
-| nfvi\_constraints: |
-| |
-| type: list |
-| |
-| entry\_schema: |
-| |
-| type: string |
-| |
-| required: false |
-| |
-| configurable\_properties: |
-| |
-| type: map |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatypes.nfv.VnfcConfigurableProperties |
-| |
-| required: true |
-| |
-| attributes: |
-| |
-| private\_address: |
-| |
-| status: deprecated |
-| |
-| public\_address: |
-| |
-| status: deprecated |
-| |
-| networks: |
-| |
-| status: deprecated |
-| |
-| ports: |
-| |
-| status: deprecated |
-| |
-| capabilities: |
-| |
-| virtual\_compute: |
-| |
-| type: tosca.capabilities.nfv.VirtualCompute |
-| |
-| virtual\_binding: |
-| |
-| type: tosca.capabilities.nfv.VirtualBindable |
-| |
-| #monitoring\_parameter: |
-| |
-| # modeled as ad hoc (named) capabilities in VDU node template |
-| |
-| # for example: |
-| |
-| #capabilities: |
-| |
-| # cpu\_load: tosca.capabilities.nfv.Metric |
-| |
-| # memory\_usage: tosca.capabilities.nfv.Metric |
-| |
-| host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
-| |
-| type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
-| |
-| valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
-| |
-| occurrences: [0,UNBOUNDED] |
-| |
-| endpoint: |
-| |
-| occurrences: [0,0] |
-| |
-| os: |
-| |
-| occurrences: [0,0] |
-| |
-| scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
-| |
-| type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
-| |
-| binding: |
-| |
-| occurrences: [0,UNBOUND] |
-| |
-| requirements: |
-| |
-| - virtual\_storage: |
-| |
-| capability: tosca.capabilities.nfv.VirtualStorage |
-| |
-| relationship: tosca.relationships.nfv.VDU.AttachedTo |
-| |
-| node: tosca.nodes.nfv.VDU.VirtualStorage |
-| |
-| occurences: [ 0, UNBOUNDED ] |
-| |
-| - local\_storage: #For NFV Profile, this requirement is deprecated. |
-| |
-| occurrences: [0,0] |
-| |
-| artifacts: |
-| |
-| - sw\_image: |
-| |
-| file: |
-| |
-| type: tosca.artifacts.nfv.SwImage |
-+-----------------------------------------------------------------------------------------------------+
+++++++++++++
+
++-----------------------------------------------------------------------------+
+| tosca.nodes.nfv.VDU.Compute: |
+| |
+| derived\_from: tosca.nodes.Compute |
+| |
+| properties: |
+| |
+| name: |
+| |
+| type: string |
+| |
+| required: true |
+| |
+| description: |
+| |
+| type: string |
+| |
+| required: true |
+| |
+| boot\_order: |
+| |
+| type: list # explicit index (boot index) not necessary, contrary to IFA011 |
+| |
+| entry\_schema: |
+| |
+| type: string |
+| |
+| required: false |
+| |
+| nfvi\_constraints: |
+| |
+| type: list |
+| |
+| entry\_schema: |
+| |
+| type: string |
+| |
+| required: false |
+| |
+| configurable\_properties: |
+| |
+| type: map |
+| |
+| entry\_schema: |
+| |
+| type: tosca.datatypes.nfv.VnfcConfigurableProperties |
+| |
+| required: true |
+| |
+| attributes: |
+| |
+| private\_address: |
+| |
+| status: deprecated |
+| |
+| public\_address: |
+| |
+| status: deprecated |
+| |
+| networks: |
+| |
+| status: deprecated |
+| |
+| ports: |
+| |
+| status: deprecated |
+| |
+| capabilities: |
+| |
+| virtual\_compute: |
+| |
+| type: tosca.capabilities.nfv.VirtualCompute |
+| |
+| virtual\_binding: |
+| |
+| type: tosca.capabilities.nfv.VirtualBindable |
+| |
+| #monitoring\_parameter: |
+| |
+| # modeled as ad hoc (named) capabilities in VDU node template |
+| |
+| # for example: |
+| |
+| #capabilities: |
+| |
+| # cpu\_load: tosca.capabilities.nfv.Metric |
+| |
+| # memory\_usage: tosca.capabilities.nfv.Metric |
+| |
+| host: #Editor note: FFS. How this capabilities should be used in NFV Profile|
+| |
+| type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__|
+| |
+| valid\_source\_types: |
+| [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
+| |
+| occurrences: [0,UNBOUNDED] |
+| |
+| endpoint: |
+| |
+| occurrences: [0,0] |
+| |
+| os: |
+| |
+| occurrences: [0,0] |
+| |
+| scalable: |
+| #Editor note: FFS. How this capabilities should be used in NFV Profile |
+| |
+| type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
+| |
+| binding: |
+| |
+| occurrences: [0,UNBOUND] |
+| |
+| requirements: |
+| |
+| - virtual\_storage: |
+| |
+| capability: tosca.capabilities.nfv.VirtualStorage |
+| |
+| relationship: tosca.relationships.nfv.VDU.AttachedTo |
+| |
+| node: tosca.nodes.nfv.VDU.VirtualStorage |
+| |
+| occurences: [ 0, UNBOUNDED ] |
+| |
+| - local\_storage: #For NFV Profile, this requirement is deprecated. |
+| |
+| occurrences: [0,0] |
+| |
+| artifacts: |
+| |
+| - sw\_image: |
+| |
+| file: |
+| |
+| type: tosca.artifacts.nfv.SwImage |
++-----------------------------------------------------------------------------+
Artifact
-^^^^^^^^
-+-----------+------------+-------------------------------+---------------+------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
-+===========+============+===============================+===============+================================================+
-| SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
-| | | | | directly realizing this virtual storage |
-+-----------+------------+-------------------------------+---------------+------------------------------------------------+
-
-
-|image2|
-
-
-
-tosca.nodes.nfv.Cpd
-~~~~~~~~~~~~~~~~~~~
-
-The TOSCA Cpd node represents network connectivity to a compute resource
-or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
-used as parent for the various Cpd types.
-
-+-----------------------+-----------------------+
-| Shorthand Name | Cpd |
-+=======================+=======================+
-| Type Qualified Name | tosca:Cpd |
-+-----------------------+-----------------------+
-| Type URI | tosca.nodes.nfv.Cpd |
-+-----------------------+-----------------------+
-
-
-Attributes
-^^^^^^^^^^
-
-+--------+------------+--------+---------------+---------------+
-| Name | Required | Type | Constraints | Description |
-+========+============+========+===============+===============+
-+--------+------------+--------+---------------+---------------+
+++++++++++
-Requirements
-^^^^^^^^^^^^
+Note: currently not supported.
-None
-
-Capabilities
-^^^^^^^^^^^^
-
-None
-
-Definition
-^^^^^^^^^^
-
-+----------------------------------------------------------------------+
-| tosca.nodes.nfv.Cpd: |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| layer\_protocol: |
-| |
-| type:string |
-| |
-| constraints: |
-| |
-| - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
-| |
-| required:true |
-| |
-| role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
-| |
-| type:string |
-| |
-| constraints: |
-| |
-| - valid\_values: [ root, leaf ] |
-| |
-| required:flase |
-| |
-| description: |
-| |
-| type: string |
-| |
-| required: false |
-| |
-| address\_data: |
-| |
-| type: list |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatype.nfv.AddressData |
-| |
-| required:false |
-+----------------------------------------------------------------------+
-
-Additional Requirement
-^^^^^^^^^^^^^^^^^^^^^^
-
-None.
-
-tosca.nodes.nfv.VduCpd
-~~~~~~~~~~~~~~~~~~~~~~
-
-The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
-network connectivity between a VNFC instance (based on this VDU) and an
-internal VL as defined by [ETSI GS NFV-IFA 011].
-
-+-----------------------+--------------------------+
-| Shorthand Name | VduCpd |
-+=======================+==========================+
-| Type Qualified Name | tosca: VduCpd |
-+-----------------------+--------------------------+
-| Type URI | tosca.nodes.nfv.VduCpd |
-+-----------------------+--------------------------+
-
-Properties
-^^^^^^^^^^
-
-
-+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
-+===============================+============+==========================================+==========================================================================+
-| bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
-+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
-| requirements | | | | realising the CPs instantiated from this CPD |
-+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-
-Attributes
-^^^^^^^^^^
-
-None
++--------+---------+----------------+------------+------------------------+
+| Name | Required| Type | Constraints| Description |
++========+=========+================+============+========================+
+| SwImage| Yes | tosca.\ | | Describes the software |
+| | | artifacts.nfv.\| | image which is directly|
+| | | SwImage | | realizing this virtual |
+| | | | | storage |
++--------+---------+----------------+------------+------------------------+
-Requirements
-^^^^^^^^^^^^
-+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
-+====================+============+==========================================+===============+==========================================================+
-| virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
-+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
-+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
+|image2|
-Definition
-^^^^^^^^^^
-+----------------------------------------------------------------+
-| tosca.nodes.nfv.VduCpd: |
-| |
-| derived\_from: tosca.nodes.nfv.Cpd |
-| |
-| properties: |
-| |
-| bitrate\_requirement: |
-| |
-| type: integer |
-| |
-| required:false |
-| |
-| virtual\_network\_interface\_requirements |
-| |
-| type: list |
-| |
-| entry\_schema: |
-| |
-| type: VirtualNetworkInterfaceRequirements |
-| |
-| required:false |
-| |
-| requirements: |
-| |
-| - virtual\_link: |
-| |
-| capability: tosca.capabilities.nfv.VirtualLinkable |
-| |
-| relationship: tosca.relationships.nfv.VirtualLinksTo |
-| |
-| node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| relationship: tosca.relationships.nfv.VirtualBindsTo |
-| |
-| node: tosca.nodes.nfv.VDU |
-+----------------------------------------------------------------+
tosca.nodes.nfv.VDU.VirtualStorage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NFV VirtualStorage node type represents a virtual storage entity
which it describes the deployment and operational behavior of a virtual
+---------------------------+--------------------------------------+
tosca.artifacts.nfv.SwImage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------+------------------------------------+
| **Shorthand Name** | SwImage |
+---------------------------+------------------------------------+
Properties
-^^^^^^^^^^
-
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
-+==========================================+============+====================+===============+====================================================================================================+
-| name | yes | string | | Name of this software image |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| version | yes | string | | Version of this software image |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| checksum | yes | string | | Checksum of the software image file |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| Size | yes | scalar-unit.size | | The size of this software image |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| operating\_system | no | string | | Identifies the operating system used in the software image. |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
-| supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
-+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
+++++++++++++
+
++-----------------+---------+----------+------------+-------------------------+
+| Name | Required| Type | Constraints| Description |
++=================+=========+==========+============+=========================+
+| name | yes | string | | Name of this software |
+| | | | | image |
++-----------------+---------+----------+------------+-------------------------+
+| version | yes | string | | Version of this software|
+| | | | | image |
++-----------------+---------+----------+------------+-------------------------+
+| checksum | yes | string | | Checksum of the software|
+| | | | | image file |
++-----------------+---------+----------+------------+-------------------------+
+| container\ | yes | string | | The container format |
+| _format | | | | describes the container |
+| | | | | file format in which |
+| | | | | software image is |
+| | | | | provided. |
++-----------------+---------+----------+------------+-------------------------+
+| disk\_format | yes | string | | The disk format of a |
+| | | | | software image is the |
+| | | | | format of the underlying|
+| | | | | disk image |
++-----------------+---------+----------+------------+-------------------------+
+| min\_disk | yes | scalar-\ | | The minimal disk size |
+| | | unit.size| | requirement for this |
+| | | | | software image. |
++-----------------+---------+----------+------------+-------------------------+
+| min\_ram | no | scalar-\ | | The minimal RAM |
+| | | unit.size| | requirement for this |
+| | | | | software image. |
++-----------------+---------+----------+------------+-------------------------+
+| Size | yes | scalar-\ | | The size of this |
+| | | unit.size| | software image |
++-----------------+---------+----------+------------+-------------------------+
+| sw\_image | yes | string | | A reference to the |
+| | | | | actual software image |
+| | | | | within VNF Package, or |
+| | | | | url. |
++-----------------+---------+----------+------------+-------------------------+
+| operating\ | no | string | | Identifies the operating|
+| _system | | | | system used in the |
+| | | | | software image. |
++-----------------+---------+----------+------------+-------------------------+
+| supported\ | no | list | | Identifies the |
+| _virtualization\| | | | virtualization |
+| _enviroment | | | | environments (e.g. |
+| | | | | hypervisor) compatible |
+| | | | | with this software image|
++-----------------+---------+----------+------------+-------------------------+
Definition
-^^^^^^^^^^
++++++++++++
+-----------------------------------------------------+
| tosca.artifacts.nfv.SwImage: |
| required: false |
+-----------------------------------------------------+
-vNAT Example
-------------
-
-openovnf\_\_vOpenNAT.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+-------------------------------------------------------------+
-| imports: |
-| |
-| - openonfv\_\_tosca.capabilities.Scalable.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Attachment.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
-| |
-| - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Container.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
-| |
-| - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
-| |
-| metadata: |
-| |
-| vnfProductName: openNAT |
-| |
-| vnfdVersion: 1.0.0 |
-| |
-| vnfProvider: intel |
-| |
-| vnfmInfo: GVNFM |
-| |
-| csarVersion: 1.0.0 |
-| |
-| vnfdId: openNAT-1.0 |
-| |
-| csarProvider: intel |
-| |
-| vnfProductInfoDescription: openNAT |
-| |
-| version: 1.0.0 |
-| |
-| csarType: NFAR |
-| |
-| vendor: intel |
-| |
-| localizationLanguage: '[english, chinese]' |
-| |
-| id: openNAT-1.0 |
-| |
-| defaultLocalizationLanguage: english |
-| |
-| vnfProductInfoName: openNAT |
-| |
-| vnfSoftwareVersion: 1.0.0 |
-| |
-| topology\_template: |
-| |
-| node\_templates: |
-| |
-| vdu\_vNat: |
-| |
-| artifacts: |
-| |
-| vNatVNFImage: |
-| |
-| file: /swimages/xenial-snat.qcow2 |
-| |
-| type: tosca.artifacts.nfv.SwImage |
-| |
-| properties: |
-| |
-| name: vNatVNFImage |
-| |
-| version: "1.0" |
-| |
-| checksum: "5000" |
-| |
-| container\_format: bare |
-| |
-| disk\_format: qcow2 |
-| |
-| min\_disk: 10 GB |
-| |
-| min\_ram: 1 GB |
-| |
-| size: 10 GB |
-| |
-| sw\_image: /swimages/xenial-snat.qcow2 |
-| |
-| operating\_system: unbantu |
-| |
-| attributes: |
-| |
-| tosca\_name: vdu\_vNat |
-| |
-| capabilities: |
-| |
-| virtual\_compute: |
-| |
-| properties: |
-| |
-| virtual\_memory: |
-| |
-| numa\_enabled: true |
-| |
-| virtual\_mem\_size: 2 GB |
-| |
-| requested\_additional\_capabilities: |
-| |
-| numa: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: numa |
-| |
-| target\_performance\_parameters: |
-| |
-| hw:numa\_nodes: "2" |
-| |
-| hw:numa\_cpus.0: "0,1" |
-| |
-| hw:numa\_mem.0: "1024" |
-| |
-| hw:numa\_cpus.1: "2,3,4,5" |
-| |
-| hw:numa\_mem.1: "1024" |
-| |
-| hyper\_threading: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: hyper\_threading |
-| |
-| target\_performance\_parameters: |
-| |
-| hw:cpu\_sockets : "2" |
-| |
-| hw:cpu\_threads : "2" |
-| |
-| hw:cpu\_cores : "2" |
-| |
-| hw:cpu\_threads\_policy: "isolate" |
-| |
-| ovs\_dpdk: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: ovs\_dpdk |
-| |
-| target\_performance\_parameters: |
-| |
-| sw:ovs\_dpdk: "true" |
-| |
-| virtual\_cpu: |
-| |
-| cpu\_architecture: X86 |
-| |
-| num\_virtual\_cpu: 2 |
-| |
-| properties: |
-| |
-| configurable\_properties: |
-| |
-| test: |
-| |
-| additional\_vnfc\_configurable\_properties: |
-| |
-| aaa: 1 |
-| |
-| name: vNat |
-| |
-| descrption: the virtual machine of vNat |
-| |
-| boot\_order: |
-| |
-| - vNAT\_Storage |
-| |
-| requirements: |
-| |
-| - virtual\_storage: |
-| |
-| capability: virtual\_storage |
-| |
-| node: vNAT\_Storage |
-| |
-| relationship: |
-| |
-| properties: |
-| |
-| location: /mnt/volume\_0 |
-| |
-| type: tosca.relationships.nfv.VDU.AttachedTo |
-| |
-| - local\_storage: |
-| |
-| node: tosca.nodes.Root |
-| |
-| type: tosca.nodes.nfv.VDU.Compute |
-| |
-| SRIOV\_Port: |
-| |
-| attributes: |
-| |
-| tosca\_name: SRIOV\_Port |
-| |
-| properties: |
-| |
-| virtual\_network\_interface\_requirements: |
-| |
-| - name: sriov |
-| |
-| support\_mandatory: false |
-| |
-| description: sriov |
-| |
-| requirement: |
-| |
-| SRIOV: true |
-| |
-| role: root |
-| |
-| description: sriov port |
-| |
-| layer\_protocol: ipv4 |
-| |
-| requirements: |
-| |
-| - virtual\_binding: |
-| |
-| capability: virtual\_binding |
-| |
-| node: vdu\_vNat |
-| |
-| relationship: |
-| |
-| type: tosca.relationships.nfv.VirtualBindsTo |
-| |
-| - virtual\_link: |
-| |
-| node: tosca.nodes.Root |
-| |
-| type: tosca.nodes.nfv.VduCpd |
-| |
-| vNAT\_Storage: |
-| |
-| attributes: |
-| |
-| tosca\_name: vNAT\_Storage |
-| |
-| properties: |
-| |
-| id: vNAT\_Storage |
-| |
-| size\_of\_storage: 10 GB |
-| |
-| rdma\_enabled: false |
-| |
-| type\_of\_storage: volume |
-| |
-| type: tosca.nodes.nfv.VDU.VirtualStorage |
-| |
-| substitution\_mappings: |
-| |
-| requirements: |
-| |
-| sriov\_plane: |
-| |
-| - SRIOV\_Port |
-| |
-| - virtual\_link |
-| |
-| node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+-------------------------------------------------------------+
-
-openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+------------------------------------------------------------+
-| imports: |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
-| |
-| node\_types: |
-| |
-| tosca.nodes.nfv.VDU.VirtualStorage: |
-| |
-| capabilities: |
-| |
-| virtual\_storage: |
-| |
-| type: tosca.capabilities.nfv.VirtualStorage |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| id: |
-| |
-| type: string |
-| |
-| size\_of\_storage: |
-| |
-| type: string |
-| |
-| rdma\_enabled: |
-| |
-| required: false |
-| |
-| type: boolean |
-| |
-| type\_of\_storage: |
-| |
-| type: string |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+------------------------------------------------------------+
-
-openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+-----------------------------------------------------------------+
-| data\_types: |
-| |
-| tosca.datatypes.nfv.L3AddressData: |
-| |
-| properties: |
-| |
-| number\_of\_ip\_address: |
-| |
-| required: false |
-| |
-| type: integer |
-| |
-| ip\_address\_assignment: |
-| |
-| type: boolean |
-| |
-| ip\_address\_type: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - ipv4 |
-| |
-| - ipv6 |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| floating\_ip\_activated: |
-| |
-| type: string |
-| |
-| tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
-| |
-| properties: |
-| |
-| name: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| support\_mandatory: |
-| |
-| type: boolean |
-| |
-| description: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| requirement: |
-| |
-| entry\_schema: |
-| |
-| type: string |
-| |
-| type: map |
-| |
-| tosca.datatype.nfv.AddressData: |
-| |
-| properties: |
-| |
-| address\_type: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - mac\_address |
-| |
-| - ip\_address |
-| |
-| type: string |
-| |
-| l2\_address\_data: |
-| |
-| required: false |
-| |
-| type: tosca.datatypes.nfv.L2AddressData |
-| |
-| l3\_address\_data: |
-| |
-| required: false |
-| |
-| type: tosca.datatypes.nfv.L3AddressData |
-| |
-| tosca.datatypes.nfv.L2AddressData: {} |
-| |
-| imports: |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| node\_types: |
-| |
-| tosca.nodes.nfv.VduCpd: |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| virtual\_network\_interface\_requirements: |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
-| |
-| required: false |
-| |
-| type: list |
-| |
-| role: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - root |
-| |
-| - leaf |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| bitrate\_requirement: |
-| |
-| required: false |
-| |
-| type: integer |
-| |
-| description: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| layer\_protocol: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - ethernet |
-| |
-| - mpls |
-| |
-| - odu2 |
-| |
-| - ipv4 |
-| |
-| - ipv6 |
-| |
-| - pseudo\_wire |
-| |
-| type: string |
-| |
-| address\_data: |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatype.nfv.AddressData |
-| |
-| required: false |
-| |
-| type: list |
-| |
-| requirements: |
-| |
-| - virtual\_binding: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| occurrences: |
-| |
-| - 0 |
-| |
-| - UNBOUNDED |
-| |
-| - virtual\_link: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| occurrences: |
-| |
-| - 0 |
-| |
-| - UNBOUNDED |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+-----------------------------------------------------------------+
-
.. |image1| image:: Image1.png
:width: 5.76806in
:height: 4.67161in
:height: 2.46042in
-b. Heat
-=======
+Heat
+-------------
General Guidelines
-------------------
+^^^^^^^^^^^^^^^^^^
+This section contains general Heat Orchestration Template guidelines.
-The Heat templates supported by ONAP must follow the requirements
-enumerated in this section.
+YAML Format
+~~~~~~~~~~~
-Filenames
----------
+R-95303 A VNF's Heat Orchestration Template **MUST** be defined
+using valid YAML.
-In order to enable ONAP to understand the relationship between Heat
-files, the following Heat file naming convention must be followed.
+YAML (YAML Ain't
+Markup Language) is a human friendly data serialization standard for all
+programming languages. See http://www.yaml.org/.
-- The file name for the base module Heat template must include “base”
- in the filename.
+Heat Orchestration Template Format
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- - Examples: *base\_xyz.yml* or *base\_xyz.yaml*; *xyz\_base.yml* or
- *xyz\_base.yaml*
+As stated above, Heat Orchestration templates must be defined in YAML.
-- There is no explicit naming convention for the add-on modules.
+YAML rules include:
- - Examples: *module1.yml* or *module1.yaml*
+ - Tabs are not allowed, use spaces ONLY
-- All Cinder volume templates must be named the same as the
- corresponding Heat template with “\_volume” appended to the file
- name.
+ - You must indent your properties and lists with 1 or more spaces
- - 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)
+ - All Resource IDs and resource property parameters are
+ case-sensitive. (e.g., "ThIs", is not the same as "thiS")
-- The file name of the environment files must fully match the
- corresponding Heat template filename and have *.env* or *.ENV*
- extension.
+Heat Orchestration Template Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- - 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)
+Heat Orchestration template structure follows the following format,
+as defined by OpenStack at
+https://docs.openstack.org/developer/heat/template_guide/hot_spec.html
-- A YAML file must have a corresponding ENV file, even if the ENV file
- enumerates no parameters. It is an ONAP requirement.
+.. code-block:: python
-Valid YAML Format
-------------------
+ heat_template_version: <date>
-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.
+ description:
+ # a description of the template
-https://wiki.openstack.org/wiki/Heat/YAMLTemplates
+ parameter_groups:
+ # a declaration of input parameter groups and order
-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.
+ parameters:
+ # declaration of input parameters
-http://docs.openstack.org/developer/heat/template_guide/hot_spec.html
+ resources:
+ # declaration of template resources
-Parameter Categories & Specification
-------------------------------------
+ outputs:
+ # declaration of output parameters
-Parameter Categories
-~~~~~~~~~~~~~~~~~~~~
+ conditions:
+ # declaration of conditions
-ONAP requires the Heat template parameters to follow certain
-requirements in order for it to be orchestrated or deployed. ONAP
-classifies parameters into eight broad categories.
+heat_template_version
++++++++++++++++++++++
-- **ONAP Metadata**: ONAP mandatory and optional metadata
- parameters in the resource *OS::Nova::Server*.
+R-27078 A VNF's Heat Orchestration template **MUST** contain
+the section "heat_template_version:".
- - ONAP dictates the naming convention of these Metadata
- parameters and must be adhered to (See Section 5.b, Independent Volume Templates).
+The section "heat_template_version:" must be set to a date
+that is supported by the OpenStack environment.
- - Metadata parameters must not be enumerated in the environment
- file.
+description
++++++++++++
- - The ONAP Metadata are generated and/or assigned by ONAP
- and supplied to the Heat by ONAP at orchestration time.
+R-39402 A VNF's Heat Orchestration Template **MUST**
+contain the section "description:".
-- **ONAP Orchestration Parameters**: The data associated with
- these parameters are VNF instance specific.
+parameter_groups
+++++++++++++++++
- - ONAP enforces the naming convention of these parameters and
- must be adhered to (See Parameter Naming Convention).
+A VNF Heat Orchestration template may
+contain the section "parameter_groups:".
- - These parameters must not be enumerated in the environment file.
+parameters
+++++++++++
- - The ONAP Orchestration Parameters are generated and/or
- assigned by ONAP and supplied to the Heat by ONAP at
- orchestration time.
+R-35414 A VNF Heat Orchestration's template **MUST**
+contain the section "parameters:".
-- **VNF Orchestration Parameters**: The data associated with these
- parameters are VNF instance specific.
- - While ONAP does not enforce a naming convention, the
- parameter names should include {vm-type} and {network-role} when
- appropriate. (See Parameter Naming Convention)
+.. code-block:: python
- - These parameters must not be enumerated in the environment file.
+ parameters:
- - The VNF Orchestration Parameters Heat are generated and/or
- assigned by ONAP and supplied to the Heat by ONAP at
- orchestration time.
+ <param name>:
-- **ONAP Orchestration Constants**: The data associated with these
- parameters must be constant across all VNF instances.
+ type: <string | number | json | comma_delimited_list | boolean>
- - ONAP enforces the naming convention of these parameters and
- must be adhered to (See Parameter Naming Convention).
+ label: <human-readable name of the parameter>
- - These parameters must be enumerated in the environment file.
+ description: <description of the parameter>
-- **VNF Orchestration Constants**: The data associated with these
- parameters must be constant across all VNF instances.
+ default: <default value for parameter>
- - While ONAP does not enforce a naming convention, the
- parameter names should include {vm-type} and {network-role} when
- appropriate. (See Parameter Naming Convention)
-
- - These parameters must be enumerated in the environment file.
-
-- **ONAP 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.
+ hidden: <true | false>
-- **ONAP 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.
+ constraints:
-- **ONAP Predefined Output Parameters** (also referred to as
- Predefined Output Parameters): ONAP will look for a small set of
- pre-defined Heat output parameters to capture resource attributes for
- inventory in ONAP. These parameters are specified in Section
- 5.b Resource Property: name.
-
-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 ONAP supplies must be enumerated in the
-environment file. However, when the Heat is to be loaded into ONAP
-for orchestration, the parameters that ONAP 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 |
-+===============================================+=====================+=================================================================================+
-| ONAP Metadata | Explicit | ONAP |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| ONAP Orchestration Parameters | Explicit | ONAP |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| VNF Orchestration Parameters | Recommended | ONAP |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| ONAP Orchestration Constants | Explicit | Environment File |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| VNF Orchestration Constants | Recommended | Environment File |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| ONAP Base Template Output Parameters | Recommended | Heat Output Statement for base, ONAP supplied to add-on modules |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| ONAP Volume Template Output Parameters | Recommended | Heat Output Statement for volume, OpeneECOMP supplies to corresponding module |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| ONAP Predefined Output Parameters | Explicit | Heat Output Statement |
-+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-
-Table 1 Parameter Types
-
-Parameter Specifications
-~~~~~~~~~~~~~~~~~~~~~~~~
+ <parameter constraints>
-ONAP METADATA Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ immutable: <true | false>
-ONAP 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.
+This section allows for
+specifying input parameters that have to be provided when instantiating
+the template. Each parameter is specified in a separate nested block
+with the name of the parameters defined in the first line and additional
+attributes (e.g., type, label) defined as nested elements.
-ONAP Base Template & Volume Template Output Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+R-90279 A VNF Heat Orchestration's template's parameter **MUST**
+be used in a resource with the exception of the parameters
+for the OS::Nova::Server resource property availability_zone.
-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.
+R-91273 A VNF Heat Orchestration’s template’s parameter for
+the OS::Nova::Server resource property availability_zone
+**MAY NOT** be used in any OS::Nova::Resource.
-ONAP Predefined Output Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+<param name>
+____________
-These parameters must not define any constraints in the Heat template,
-including length restrictions, ranges, default value and/or allowed
-patterns.
+The name of the parameter.
-ONAP Orchestration Parameters, VNF Orchestration Parameters, ONAP Orchestration Constants, VNF Orchestration Constants
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+R-25877 A VNF's Heat Orchestration Template's parameter
+name (i.e., <param name>) **MUST** contain only
+alphanumeric characters and underscores ('_').
-ONAP Orchestration Parameters, VNF Orchestration Parameters,
-ONAP Orchestration Constants, VNF Orchestration Constants must
-adhere to the following:
+type
+____
-- All parameters should be clearly documented in the template,
- including expected values.
+R-36772 A VNF’s Heat Orchestration Template’s parameter
+**MUST** include the attribute “type:”.
-- All parameters should be clearly specified, including constraints and
- description.
+R-11441 A VNF’s Heat Orchestration Template’s parameter
+type **MUST** be one of the following values: "string",
+"number", "json", "comma_delimited_list" or "boolean".
-- Numeric parameter constraints should include range and/or allowed
- values.
+label
+_____
-- 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.
+R-32094 A VNF's Heat Orchestration Template parameter
+declaration **MAY** contain the attribute "label:"
-- When the parameter type is a Comma Delimited List (CDL), the
- reference index must start at zero.
+description
+___________
-- Default values must only be supplied in a Heat environment file to
- keep the template itself as clean as possible.
+R-44001 A VNF's Heat Orchestration Template parameter
+declaration **MUST** contain the attribute "description".
-- Special characters must not be used in parameter names, as currently
- only alphanumeric characters and “\_” underscores are allowed.
+Note that the parameter attribute “description:” is an
+OpenStack optional attribute that provides a description
+of the parameter. ONAP implementation requires this attribute.
-Use of Heat Environments
-------------------------
+default
+_______
-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 ONAP requirement.
+R-90526 A VNF Heat Orchestration Template parameter
+declaration **MUST** not contain the default attribute.
-The environment file must contain parameter values for the ONAP
-Orchestration Constants and VNF Orchestration Constants. These
-parameters are identical across all instances of a VNF type, and
-expected to change infrequently. The ONAP Orchestration Constants
-are associated with OS::Nova::Server image and flavor properties (See
-Section 5.b Resource: OS::Nova::Server – Parameters). Examples of VNF Orchestration Constants are the networking
-parameters associated with an internal network (e.g. private IP ranges)
-and Cinder volume sizes.
+R-26124 If a VNF Heat Orchestration Template parameter
+requires a default value, it **MUST** be enumerated in the environment file.
-The environment file must not contain parameter values for parameters
-that are instance specific (ONAP Orchestration Parameters, VNF
-Orchestration Parameters). These parameters are supplied to the Heat by
-ONAP at orchestration time. The parameters are generated and/or
-assigned by ONAP at orchestration time
+Note that the parameter attribute “default:” is an OpenStack
+optional attribute that declares the default value of the
+parameter. ONAP implementation prohibits the use of this attribute.
-Independent Volume Templates
-----------------------------
+hidden
+______
-ONAP 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).
+R-32557 A VNF's Heat Orchestration Template parameter
+declaration MAY contain the attribute "hidden:".
-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.
+The parameter attribute "hidden:" is an OpenStack optional
+attribute that defines whether the parameters should be
+hidden when a user requests information about a stack
+created from the template. This attribute can be used
+to hide passwords specified as parameters.
-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.
+constraints
+___________
-The following rules apply to independent volume Heat templates:
+The parameter attribute "constraints:" is an OpenStack optional
+attribute that defines a list of constraints to apply to the parameter.
-- Cinder volumes must be created in a separate Heat template from the
- Incremental and Base Modules.
+R-88863 A VNF's Heat Orchestration Template's parameter defined as
+type "number" **MUST** have a parameter constraint of "range" or
+"allowed_values" defined.
- - A single volume module must include all Cinder volumes needed by
- the Incremental/Base module.
+R-40518 A VNF's Heat Orchestration Template’s parameter defined as
+type "string" **MAY** have a parameter constraint defined.
- - The volume template must define “outputs” for each Cinder volume
- resource universally unique identifier (UUID) (i.e. ONAP
- Volume Template Output Parameters).
+R-96227 A VNF's Heat Orchestration Template’s parameter defined as
+type "json" **MAY** have a parameter constraint defined.
-- The VNF Incremental Module or Base Module must define input
- parameters that match each Volume output parameter (i.e., ONAP
- Volume Template Output Parameters).
+R-79817 A VNF's Heat Orchestration Template’s parameter defined as
+type "comma_delimited_list" **MAY** have a parameter constraint defined.
+
+R-06613 A VNF's Heat Orchestration Template’s parameter defined as
+type "boolean" **MAY** have a parameter constraint defined.
+
+R-00011 A VNF's Heat Orchestration Template's Nested YAML files
+parameter's **MUST NOT** have a parameter constraint defined.
+
+The constraints block of a parameter definition defines additional
+validation constraints that apply to the value of the parameter.
+The parameter values provided in the VNF Heat Orchestration Template
+are validated against the constraints at instantiation time.
+The stack creation fails if the parameter value doesn’t comply to
+the constraints.
+
+The constraints are defined as a list with the following syntax
+
+.. code-block:: python
+
+ constraints:
+
+ <constraint type>: <constraint definition>
+
+ description: <constraint description>
+
+..
+
+**<constraint type>** Provides the type of constraint to apply.
+The list of OpenStack supported constraints can be found at
+https://docs.openstack.org/heat/latest/template_guide/hot_spec.html .
+
+**<constraint definition>** provides the actual constraint.
+The syntax and constraint is dependent of the <constraint type> used.
+
+**description** is an optional attribute that provides a description of the
+constraint. The text is presented to the user when the value the user
+defines violates the constraint. If omitted, a default validation
+message is presented to the user.
+
+Below is a brief overview of the "range" and "allowed values" constraints.
+For complete details on constraints, see
+https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#parameter-constraints
+
+**range**
+
+range: The range constraint applies to parameters of type: number.
+It defines a lower and upper limit for the numeric value of the
+parameter. The syntax of the range constraint is
+
+.. code-block:: python
+
+ range: { min: <lower limit>, max: <upper limit> }
+
+..
+
+It is possible to define a range constraint with only a lower
+limit or an upper limit.
+
+**allowed_values**
+
+allowed_values: The allowed_values constraint applies to parameters of
+type \"string\" or type \"number\". It specifies a set of possible
+values for a parameter. At deployment time, the user-provided value
+for the respective parameter must match one of the elements of the
+list. The syntax of the allowed_values constraint is
+
+.. code-block:: python
+
+ allowed_values: [ <value>, <value>, ... ]
+
+ Alternatively, the following YAML list notation can be used
+
+ allowed_values:
+
+ - <value>
+
+ - <value>
+
+ - ...
+
+. .
+
+immutable
+_________
+
+R-22589 A VNF’s Heat Orchestration Template parameter declaration
+**MAY** contain the attribute "immutable:".
+
+The parameter attribute \"immutable:\" is an OpenStack optional
+attribute that defines whether the parameter is updatable. A Heat
+Orchestration Template stack update fails if immutable is set to
+true and the parameter value is changed. This attribute
+\"immutable:\" defaults to false.
+
+resources
++++++++++
+
+R-23664 A VNF's Heat Orchestration template **MUST** contain
+the section "resources:".
+
+R-90152 A VNF's Heat Orchestration Template's "resources:"
+section **MUST** contain the declaration of at least one resource.
+
+R-40551 A VNF's Heat Orchestration Template's Nested YAML files
+**MAY** contain the section "resources:".
+
+Each resource is defined as a
+separate block in the resources section with the following syntax.
+
+.. code-block:: python
+
+ resources:
+
+ <resource ID>:
+
+ type: <resource type>
+
+ properties:
+
+ <property name>: <property value>
+
+ metadata:
+
+ <resource specific metadata>
+
+ depends_on: <resource ID or list of ID>
+
+ update_policy: <update policy>
+
+ deletion_policy: <deletion policy>
+
+ external_id: <external resource ID>
+
+ condition: <condition name or expression or boolean>
+
+
+
+resource ID
+___________
+
+R-75141 A VNF's Heat Orchestration Template's resource name
+(i.e., <resource ID>) **MUST** only contain alphanumeric
+characters and underscores ('_').
+
+R-16447 A VNF's <resource ID> **MUST** be unique across all
+Heat Orchestration Templates and all HEAT Orchestration Template
+Nested YAML files that are used to create the VNF.
+
+Note that a VNF can be composed of one or more Heat Orchestration Templates.
+
+Note that OpenStack requires the <resource ID> to be unique to the
+Heat Orchestration Template and not unique across all Heat
+Orchestration Templates the compose the VNF.
+
+type
+____
+
+The resource attribute \"type:\" is an OpenStack required
+attribute that defines the resource type, such as
+OS::Nova::Server or OS::Neutron::Port.
+
+The resource attribute \"type:\" may specify a VNF HEAT
+Orchestration Template Nested YAML file.
+
+R-53952 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based resource definitions.
+
+R-71699 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based Nested YAML file.
+
+properties
+__________
+
+The resource attribute \"properties:\" is an OpenStack optional
+attribute that provides a list of resource-specific properties.
+The property value can be provided in place, or via a function
+(e.g., `Intrinsic functions <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-intrinsic-functions>`__).
+
+R-10834 If a VNF Heat Orchestration Template resource attribute
+"property:" uses a nested "get_param", one level of nesting is
+supported and the nested "get_param" **MUST** reference an index
+
+metadata
+________
+
+The resource attribute \"metadata:\" is an OpenStack optional attribute.
+
+R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
+resource **MUST** contain the attribute "metadata".
+
+Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
+
+
+depends_on
+__________
+
+The resource attribute \"depends_on:\" is an OpenStack optional
+attribute.
+See `OpenStack documentation <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-resources-dependencies>`__
+for additional details.
+
+R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “depends_on:”.
+
+update_policy
+_____________
+
+R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “update_policy:”.
+
+deletion_policy
+_______________
+
+R-43740 A VNF’s Heat Orchestration Template’s Resource
+**MAY** declare the attribute “deletion_policy:”.
+
+If specified, the \"deletion_policy:\" attribute for resources
+allows values 'Delete', 'Retain', and 'Snapshot'.
+Starting with heat_template_version 2016-10-14, lowercase
+equivalents are also allowed.
+
+The default policy is to delete the physical resource when
+deleting a resource from the stack.
+
+external_id
+___________
+
+R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
+declare the attribute “external_id:”.
+
+This attribute allows for specifying the resource_id for an
+existing external (to the stack) resource. External resources
+cannot depend on other resources, but we allow other resources to
+depend on external resource. This attribute is optional.
+Note: when this is specified, properties will not be used for
+building the resource and the resource is not managed by Heat.
+This is not possible to update that attribute. Also,
+resource won’t be deleted by heat when stack is deleted.
+
+
+condition
+_________
+
+The resource attribute \"condition:\" is an OpenStack optional attribute.
+
+Support for the resource condition attribute was added
+in the Newton release of OpenStack.
+
+outputs
++++++++
+
+R-36982 A VNF’s Heat Orchestration template **MAY**
+contain the “outputs:” section.
+
+This section allows for specifying output parameters
+available to users once the template has been instantiated. If the
+section is specified, it will need to adhere to specific requirements.
+See `ONAP Parameter Classifications Overview`_ and
+`ONAP Output Parameter Names`_ for additional details.
+
+Environment File Format
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The environment file is a yaml text file.
+(https://docs.openstack.org/developer/heat/template_guide/environment.html)
+
+R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file, even if no parameters are required to be enumerated.
+
+The use of an environment file in OpenStack is optional.
+In ONAP, it is mandatory.
+
+R-03324 The VNF Heat Orchestration Template **MUST** contain the
+"parameters" section in the
+environment file
+
+R-68198 A VNF’s Heat Orchestration template’s Environment File’s
+“parameters:” section **MAY** enumerate parameters.
+
+ONAP implementation requires the parameters section in the
+environmental file to be declared. The parameters section
+contains a list of key/value pairs.
+
+R-59930 A VNF’s Heat Orchestration template’s Environment
+File’s **MAY** contain the “parameter_defaults:” section.
+
+The “parameter_defaults:” section contains default parameters
+that are passed to all template resources.
+
+R-46096 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “encrypted_parameters:” section.
+
+The “encrypted_parameters:” section contains a list of encrypted parameters.
+
+R-24893 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “event_sinks:” section.
+
+The “event_sinks:” section contains the list of endpoints that would
+receive stack events.
+
+R-42685 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “parameter_merge_strategies:” section.
+
+The “parameter_merge_strategies:” section provides the merge strategies
+for merging parameters and parameter defaults from the environment file.
+
+R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
+contain the “resource_registry:” section.
+
+ONAP implementation does not support the Environment File
+resource_registry section. The resource_registry section
+allows for the definition of custom resources.
+
+
+SDC Treatment of Environment Files
+++++++++++++++++++++++++++++++++++
+
+Parameter values enumerated in the environment file are used by SDC as
+the default value. However, the SDC user may use the SDC GUI to
+overwrite the default values in the environment file.
+
+SDC generates a new environment file for distribution to MSO based on
+the uploaded environment file and the user provided GUI updates. The
+user uploaded environment file is discarded when the new file is
+created.
+
+ONAP has requirements for what parameters must be enumerated in the
+environment file and what parameter must not be enumerated in the
+environment file. See `ONAP Parameter Classifications Overview`_ and
+`ONAP Resource ID and Parameter Naming Convention`_ for more details.
+
+ONAP Heat Orchestration Templates: Overview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ONAP supports a modular Heat Orchestration Template design pattern,
+referred to as *VNF Modularity.*
+
+ONAP VNF Modularity Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
+Templates, each of which represents a subset of the overall VNF.
+
+The Heat Orchestration Templates can be thought of a components or
+modules of the VNF and are referred to as “\ *VNF Modules*\ ”.
+During orchestration, these modules are
+deployed incrementally to create the complete VNF.
+
+R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module
+Heat Orchestration Template (also referred to as a Base Module), 2.)
+Incremental Module Heat Orchestration Template (referred to as an Incremental
+Module), or 3.) a Cinder Volume Module Heat Orchestration Template
+(referred to as Cinder Volume Module).
+
+R-37028 The VNF **MUST** be composed of one “base” module.
+
+R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
+
+R-20974 The VNF **MUST** deploy the base module first, prior to
+the incremental modules.
+
+R-28980 A VNF’s incremental module **MAY** be used for initial VNF
+deployment only.
+
+R-86926 A VNF’s incremental module **MAY** be used for scale out only.
+
+A VNF’s Incremental Module that is used for scale out is deployed
+sometime after initial VNF deployment to add capacity.
+
+R-91497 A VNF’s incremental module **MAY** be used for both deployment
+and scale out.
+
+R-68122 A VNF’s incremental module **MAY** be deployed more than once,
+either during initial VNF deployment and/or scale out.
+
+R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
+**MAY** be defined in a Base Module.
+
+R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in an Incremental Module.
+
+R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in a Cinder Volume Module.
+
+ONAP also supports the concept of an optional, independently deployed Cinder
+volume via a separate Heat Orchestration Templates, referred to as a Cinder
+Volume Module. This allows the volume to persist after a Virtual Machine
+(VM) (i.e., OS::Nova::Server) is deleted, allowing the volume to be reused
+on another instance (e.g., during a failover activity).
+
+R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it
+exists, to be 1:1 with the VNF Base Module or Incremental Module
+
+It is strongly recommended that Cinder Volumes be created in a Cinder Volume
+Module.
+
+R-38474 The VNF **MUST** have a corresponding environment file for a
+Base Module.
+
+R-81725 The VNF **MUST** have a corresponding environment file for an
+Incremental Module.
+
+R-53433 The VNF **MUST** have a corresponding environment file for a
+Cinder Volume Module.
+
+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.
+
+Nested Heat Orchestration Templates Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP supports nested Heat Orchestration Templates per OpenStack
+specifications.
+
+R-36582 A VNF’s Base Module **MAY** utilize nested heat.
+
+R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
+
+R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
+
+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 Heat Orchestration Template may then reference these
+nested templates either statically (by repeated definition) or
+dynamically (via OS::Heat::ResourceGroup).
+
+See `Nested Heat Templates`_ for additional details.
+
+ONAP Heat Orchestration Template Filenames
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to enable ONAP to understand the relationship between Heat
+files, the following Heat file naming convention must be utilized.
+
+In the examples below, <text> represents any alphanumeric string that
+must not contain any special characters and must not contain the word
+“base”.
+
+R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
+be in the lower case format ‘.yaml’ or ‘.yml’.
+
+R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
+**MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
+
+R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
+**MUST** be in the lower case format ‘.env’.
+
+Base Modules
+++++++++++++
+
+R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST**
+include ‘base’ in the filename and **MUST** match one of the following four
+formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.)
+‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case
+insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters
+and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’.
+
+R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File
+**MUST** be named identical to the VNF Heat Orchestration Template’s Base
+Module with ‘.y[a]ml’ replaced with ‘.env’.
+
+Incremental Modules
++++++++++++++++++++
+
+R-87247 A VNF Heat Orchestration Template’s Incremental Module file name
+**MUST** contain only alphanumeric characters and underscores ‘_’ and
+**MUST NOT** contain the case insensitive word ‘base’.
+
+R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment
+File **MUST** be named identical to the VNF Heat Orchestration Template’s
+Incremental Module with ‘.y[a]ml’ replaced with ‘.env’.
+
+To clearly identify the incremental module, it is recommended to use the
+following naming options for modules:
+
+ - module_<text>.y[a]ml
+
+ - <text>_module.y[a]ml
+
+ - module.y[a]ml
+
+ - <text>_module_<text>.y[a]ml
+
+Cinder Volume Modules
++++++++++++++++++++++
+
+R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be
+named identical to the base or incremental module it is supporting with
+‘_volume appended’
+
+R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment
+File **MUST** be named identical to the VNF Heat Orchestration Template’s
+Cinder Volume Module with .y[a]ml replaced with ‘.env’.
+
+Nested Heat file
+++++++++++++++++
+
+R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST**
+contain only alphanumeric characters and underscores ‘_’ and **MUST NOT**
+contain the case insensitive word ‘base’.
+
+Examples include
+
+ - <text>.y[a]ml
+
+ - nest_<text>.y[a]ml
+
+ - <text>_nest.y[a]ml
+
+ - nest.y[a]ml
+
+ - <text>_nest_<text>.y[a]ml
+
+VNF Heat Orchestration Template's Nested YAML file does not have a
+corresponding environment files, per OpenStack specifications.
+
+R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties
+all parameter values
+associated with the nested heat file in the resource definition defined
+in the parent heat template.
+
+Output Parameters
+~~~~~~~~~~~~~~~~~
+
+The output parameters are parameters defined in the output section of a
+Heat Orchestration Template. The ONAP output parameters are subdivided
+into three categories:
+
+1. ONAP Base Module Output Parameters
+
+2. ONAP Volume Module Output Parameters
+
+3. ONAP Predefined Output Parameters.
+
+ONAP Base Module Output Parameters
+++++++++++++++++++++++++++++++++++++
+
+ONAP Base Module Output Parameters are declared in the 'outputs:'' section of
+the VNF's Heat Orchestration Template's Base Module. A Base Module Output
+Parameter is available as an input parameter (i.e., declared in the
+'parameters:'' section) to all Incremental Modules in the VNF.
+
+A Base Module Output Parameter may be used as an input parameter in any
+incremental module in the VNF. Note that the parameter is not
+available to other VNFs.
+
+R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s
+name and type **MUST** match the VNF’s Heat Orchestration Template’s
+incremental Module’s name and type unless the output parameter is of type
+‘comma_delimited_list’, then the corresponding input parameter **MUST**
+be declared as type ‘json’.
+
+If the Output parameter has a comma_delimited_list value (e.g., a collection
+of UUIDs from a Resource Group), then the corresponding input parameter
+must be declared as type json and not a comma_delimited_list, which is
+actually a string value with embedded commas.
+
+R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output
+parameter is declared as an input parameter in an Incremental Module,
+the parameter attribute ‘constraints:’ **MUST NOT** be declared.
+
+Additional details on ONAP Base Module Output Parameters are provided in
+`ONAP Output Parameter Names`_ and ONAP VNF Modularity.
+
+ONAP Volume Module Output Parameters
+++++++++++++++++++++++++++++++++++++
+
+R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
+Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
+template, while other Output Parameters **MAY** be included.
+
+A VNF’s Heat Orchestration Template’s Cinder Volume Module Output Parameter(s)
+are only available for the module (base or incremental) that the volume
+template is associated with.
+
+R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output
+Parameter’s name and type **MUST** match the input parameter name and type
+in the corresponding Base Module or Incremental Module unless the Output
+Parameter is of the type ‘comma_delimited_list’, then the corresponding input
+parameter **MUST** be declared as type ‘json’.
+
+If the Output parameter has a comma_delimited_list value (e.g., a collection
+of UUIDs from a Resource Group), then the corresponding input parameter must
+be declared as type json and not a comma_delimited_list, which is actually a
+string value with embedded commas.
+
+R-20547 When an ONAP Volume Module Output Parameter is declared as an input
+parameter in a base or an incremental module Heat Orchestration Template,
+parameter constraints **MUST NOT** be declared.
+
+Additional details on ONAP Base Module Output Parameters are provided in
+`ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
+
+ONAP Predefined Output Parameters
++++++++++++++++++++++++++++++++++++
+
+ONAP will look for a small set of pre-defined Heat output parameters to
+capture resource attributes for inventory in ONAP. These output parameters
+are optional and currently only two parameters are supported. These output
+parameters are optional and are specified in `OAM Management IP Addresses`_.
+
+Support of heat stack update
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP does not support the use of heat stack-update command for scaling
+(growth/de-growth).
+
+R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
+utilize the OpenStack ‘heat stack-update’ command for scaling
+(growth/de-growth).
+
+R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
+design to support scaling (growth/de-growth).
+
+Scope of a Heat Orchestration Template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance
+specific or Cloud site specific
+
+R-56750 A VNF’s Heat Orchestration Template’s parameter values that are
+constant across all deployments **MUST** be declared in a Heat Orchestration
+Template Environment File.
+
+ONAP provides the instance specific parameter values to the Heat
+Orchestration Template at orchestration time.
+
+R-01896 A VNF’s Heat Orchestration Template’s parameter values that are
+constant across all deployments **MUST** be declared in a Heat Orchestration
+Template Environment File.
+
+Networking
+^^^^^^^^^^
+
+ONAP defines two types of networks: External Networks and Internal Networks.
+
+External Networks
+~~~~~~~~~~~~~~~~~
+
+ONAP defines an external network in relation to the VNF and not with regard
+to the Network Cloud site. External networks may also be referred to as
+“inter-VNF” networks. An external network must connect VMs in a VNF to
+VMs in another VNF or an external gateway or external router.
+
+An External Network may be a Neutron Network or a Contrail Network.
+
+R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat
+resources to create external networks.
+
+External networks must be orchestrated separately, independent of the VNF.
+This allows the network to be shared by multiple VNFs and managed
+independently of VNFs.
+
+R-00606 A VNF **MAY** be connected to zero, one or more than one external
+networks.
+
+R-57424 A VNF’s port connected to an external network **MUST** connect the
+port to VMs in another VNF and/or an external gateway and/or external router.
+
+R-29865 A VNF’s port connected to an external network **MUST NOT** connect
+the port to VMs in the same VNF.
+
+R-69014 When a VNF connects to an external network, a network role, referred
+to as the ‘{network-role}’ **MUST** be assigned to the external network
+for use in the VNF’s Heat Orchestration Template.
+
+R-05201 When a VNF connects to two or more external networks, each external
+network **MUST** be assigned a unique ‘{network-role}’ in the context of
+the VNF for use in the VNF’s Heat Orchestration Template.
+
+R-83015 A VNF’s ‘{network-role}’ assigned to an external network **MUST**
+be different than the ‘{network-role}’ assigned to the VNF’s internal
+networks, if internal networks exist.
+
+ONAP enforces a naming convention for parameters associated with
+external networks. `ONAP Resource ID and Parameter Naming Convention`_
+provides additional details.
+
+Internal Networks
+~~~~~~~~~~~~~~~~~
+
+ONAP defines an internal network in relation to the VNF and not with
+regard to the Network Cloud site. Internal networks may also be referred
+to as “intra-VNF” networks or “private” networks. An internal network
+only connects VMs in a single VNF; it must not connect to other VNFs
+or an external gateway or router
+
+R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
+
+R-35666 If a VNF has an internal network, the VNF Heat Orchestration
+Template **MUST** include the heat resources to create the internal network.
+
+R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat
+Orchestration Template Base Module.
+
+An Internal Network may be created using Neutron Heat Resources and/or
+Contrail Heat Resources.
+
+R-52425 A VNF’s port connected to an internal network **MUST** connect
+the port to VMs in the same VNF.
+
+R-46461 A VNF’s port connected to an internal network **MUST NOT** connect
+the port to VMs in another VNF and/or an external gateway and/or
+external router.
+
+R-68936 When a VNF creates an internal network, a network role, referred to
+as the ‘{network-role}’ **MUST** be assigned to the internal network for
+use in the VNF’s Heat Orchestration Template.
+
+R-32025 When a VNF creates two or more internal networks, each internal
+network **MUST** be assigned a unique ‘{network-role}’ in the context of
+the VNF for use in the VNF’s Heat Orchestration Template.
+
+R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST**
+be different than the ‘{network-role}’ assigned to the VNF’s external
+networks.
+
+R-34726 If a VNF’s port is connected to an internal network and the port
+is created in the same Heat Orchestration Template as the internal network,
+then the port resource **MUST** use a ‘get_resource’ to obtain
+the network UUID.
+
+R-22688 If a VNF’s port is connected to an internal network and the
+port is created in an Incremental Module and the internal network is created
+in the Base Module then the UUID of the internal network **MUST** be exposed
+as a parameter in the ‘outputs:’ section of the Base Module and the port
+resource **MUST** use a ‘get_param’ to obtain the network UUID.
+
+ONAP does not programmatically enforce a naming convention for
+parameters for internal network. However, a naming convention is
+provided that must be followed.
+`ONAP Resource ID and Parameter Naming Convention`_
+provides additional details.
+
+ONAP Resource ID and Parameter Naming Convention
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section provides the ONAP naming requirements for
+
+1. Resource IDs
+
+2. Resource Property Parameters
+
+{vm-type}
+~~~~~~~~~
+
+R-01455 When a VNF's Heat Orchestration Template creates a
+Virtual Machine (i.e., 'OS::Nova::Server'), each 'class' of VMs
+**MUST** be assigned a VNF unique '{vm-type}'; where 'class'
+defines VMs that **MUST** have the following identical characteristics:
+
+ 1.) OS::Nova::Server property flavor value
+
+ 2.) OS::Nova::Server property image value
+
+ 3.) Cinder Volume attachments
+ - Each VM in the 'class' **MUST** have the identical Cinder Volume
+ configuration
+
+ 4.) Network attachments and IP address requirements
+ - Each VM in the 'class' **MUST** have the the identical number
+ of ports connecting to the identical networks and requiring the
+ identical IP address configuration.
+
+R-82481 A VNF's Heat Orchestration Template's Resource property
+parameter that is
+associated with a unique Virtual Machine type **MUST**
+include '{vm-type}' as part of the parameter name with two
+exceptions:
+
+ 1.) The Resource OS::Nova::Server property availability_zone parameter
+ **MUST NOT** be prefixed with a common '{vm-type} identifier,
+
+ 2.) The Resource OS::Nova::Server eight mandatory and optional metadata
+ parameters (vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role,
+ vf_module_index, environment_context, workload_context) **MUST NOT**
+ be prefixed with a common '{vm-type}' identifier.
+
+
+R-66729 A VNF’s Heat Orchestration Template’s Resource that is
+associated with a unique Virtual Machine type **MUST** include
+‘{vm-type}’ as part of the resource ID.
+
+R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
+only alphanumeric characters and/or underscores '_' and
+**MUST NOT** contain any of the following strings: '_int' or 'int\_'
+or '\_int\_'.
+
+R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
+substring of {network-role}.
+
+It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
+ICE Project) process to produce erroneous error messages.
+
+R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’
+in all Resource property parameter names **MUST** be the same case.
+
+R-46839 A VNF’s Heat Orchestration Template’s use of
+‘{vm-type}’ in all Resource IDs **MUST** be the same case.
+
+R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in
+Resource property parameter names **SHOULD** match the case of
+‘{vm-type}’ in Resource IDs and vice versa.
+
+{network-role}
+~~~~~~~~~~~~~~
+
+The assignment of a {network-role} is discussed in `Networking`_.
+
+R-21330 A VNF’s Heat Orchestration Template’s Resource property
+parameter that is associated with external network **MUST**
+include the ‘{network-role}’’ as part of the parameter name
+
+R-11168 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an external network **MUST** include the
+'{network-role}' as part of the resource ID.
+
+R-84322 A VNF's Heat Orchestration Template's Resource property
+parameter that is associated with an internal network
+**MUST** include 'int\_{network-role}' as part of the parameter
+name, where 'int\_' is a hard coded string.
+
+R-96983 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an internal network **MUST** include
+'int\_{network-role}' as part of the Resource ID, where
+'int\_' is a hard coded string.
+
+R-26506 A VNF's Heat Orchestration Template's '{network-role}'
+**MUST** contain only alphanumeric characters and/or
+underscores '_' and **MUST NOT** contain any of the following
+strings: '_int' or 'int\_' or '\_int\_'.
+
+R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’
+**MUST NOT** be a substring of ‘{vm-type}’.
+
+For example, if a VNF has a ‘{vm-type}’ of ‘oam’ and a
+‘{network-role}’ of ‘oam_protected’ would be a violation of the requirement.
+
+R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource property parameter names **MUST** be the same case
+
+R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource IDs **MUST** be the same case.
+
+R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case
+in Resource property parameter names **SHOULD** match the case
+of ‘{network-role}’ in Resource IDs and vice versa.
+
+Resource IDs
+~~~~~~~~~~~~
+
+Requirement R-75141 states a VNF’s Heat Orchestration Template’s
+resource name (i.e., <resource ID>) MUST only contain alphanumeric
+characters and underscores (‘_’).*
+
+Requirement R-16447 states a VNF’s <resource ID> MUST be unique
+across all Heat Orchestration Templates and all HEAT Orchestration
+Template Nested YAML files that are used to create the VNF.
+
+As stated previously, OpenStack requires the <resource ID> to be unique
+to the Heat Orchestration Template and not unique across all Heat
+Orchestration Templates the compose the VNF.
+
+Heat Orchestration Template resources are described in `resources`_
+
+R-54517 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’.
+
+R-96482 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single external network, the Resource ID MUST contain the text
+‘{network-role}’.
+
+R-98138 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single internal network, the Resource ID MUST contain the text
+‘int\_{network-role}’.
+
+R-82115 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single external network, the Resource
+ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
+
+- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
+ be separated by an underscore '_'
+
+ - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
+
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ '{network-role}' and when this occurs underscores **MUST** separate the
+ three values.
+
+R-82551 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single internal network, the Resource ID
+**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
+
+- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
+ **MUST** be separated by an underscore '_'
+
+ - (e.g., '{vm-type}\_int\_{network-role}',
+ '{vm-type}_{index}\_int\_{network-role}')
+
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ 'int\_{network-role}' and when this occurs underscores **MUST** separate
+ the three values.
+
+R-67793 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’
+and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the
+term ‘shared’ and/or contain text that identifies the VNF
+
+R-27970 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MAY** contain the term ‘shared’
+and/or **MAY** contain text that identifies the VNF.
+
+R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains
+an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’
+**MUST** start at zero and increment by one.
+
+The table below provides example OpenStack Heat resource ID for
+resources only associated with one {vm-type} and/or one network.
+
+The Requirements column states if the Resource ID Format MUST be followed
+or SHOULD be followed. Resource ID formats that are marked MUST must be
+followed, no deviations are permitted. Resource ID formats that are marked
+SHOULD should be followed. However, deviations are permissible to meet
+the needs of the VNF’s Heat Orchestration Template.
+
++-----------------+-------------------------+-------------+------------------+
+|Resource Type |Resource ID Format | Requirements| Notes |
+| | | | |
++=================+=========================+=============+==================+
+| OS::Cinder:: | {vm-type}\_volume\ | **SHOULD** | |
+| Volume | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Cinder:: | {vm-type}\ | **SHOULD** | |
+| VolumeAttachment| _volumeattachment\ | | |
+| | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RCC | **SHOULD** | |
+| CloudConfig | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RMM | **SHOULD** | |
+| MultipartMime | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RRG | **SHOULD** | |
+| ResourceGroup | | | |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_{index}\ | **MUST** for| Resource ID for |
+| | _subint\_{network-role}\| subinterface| the OS::Heat:: |
+| | _port\_{index}\ | creation | ResourceGroup |
+| | _subinterfaces | | that creates |
+| | | | subinterfaces |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RSC | **SHOULD** | |
+| SoftwareConfig | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | {vm-type}\ | **MUST** | Resource ID for |
+| Port | _{vm-type-index}\ | | port connecting |
+| | _{network-role}\_port\ | | to an external |
+| | _{port-index} | | network. The |
+| | | | {vm-type-index} |
+| | | | is the instance |
+| | | | of the {vm_type}.|
+| | | | The {port-index} |
+| | | | is the instance |
+| | | | of the “port” on |
+| | | | the {vm-type}. |
+| | | | There is no index|
+| | | | after |
+| | | | {network_role} |
+| | | | since |
+| | | | {network-role} is|
+| | | | unique to the |
+| | | | VNF, there should|
+| | | | only be one |
+| | | | instance. |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_{index}\_int\| **MUST** | Resource ID for |
+| | _{network-role}\_port\ | | port connecting |
+| | _{index} | | to an internal |
+| | | | network. The |
+| | | | {index} that |
+| | | | follows {vm-type}|
+| | | | is the instance |
+| | | | of the {vm_type}.|
+| | | | The {index} that |
+| | | | follows “port” is|
+| | | | the instance of |
+| | | | the “port” on the|
+| | | | {vm-type}. There |
+| | | | is no index after|
+| | | | {network_role} |
+| | | | since |
+| | | | {network-role} is|
+| | | | unque to the AIC |
+| | | | LCP; there should|
+| | | | only be one |
+| | | | instance. |
++-----------------+-------------------------+-------------+------------------+
+| | Reserve_Port\_{vm-type}\| | Resource ID for a|
+| | _{network-role}\ | **MUST** | reserve port that|
+| | _floating_ip\_{index} | | is used for an |
+| | | | allowed_address |
+| | Reserve_Port\_{vm-type}\| | \_pair. See |
+| | _{network-role}\ | | Section 5.6.5.5 |
+| | _floating_v6_ip\ | | for additional |
+| | _{index} | | details. |
+| | | | |
+| | | | There is no |
+| | | | {index} that |
+| | | | follows {vm-type}|
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | {vm-type}\_Sec\_Grp | **SHOULD** | Security Group |
+| SecurityGroup | | | applicable to one|
+| | | | {vm-type} and |
+| | | | more than one |
+| | | | network (internal|
+| | | | and/or external) |
++-----------------+-------------------------+-------------+------------------+
+| | {network-role}\_Sec\_Grp| **SHOULD** | Security Group |
+| | | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and one|
+| | | | external network |
++-----------------+-------------------------+-------------+------------------+
+| | int\_{network-role}\ | **SHOULD** | Security Group |
+| | _Sec\_Grp | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and one|
+| | | | internal network |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\ | **SHOULD** | Security Group |
+| | _{network-role}\_Sec\ | | applicable to one|
+| | _Grp | | {vm-type} and one|
+| | | | external network |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_int\ | **SHOULD** | Security Group |
+| | _{network-role}\_Sec\ | | applicable to one|
+| | _Grp | | {vm-type} and one|
+| | | | internal network |
++-----------------+-------------------------+-------------+------------------+
+| | Shared\_Sec\_Grp | **SHOULD** | Security Group |
+| | | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and |
+| | | | more than one |
+| | | | network (internal|
+| | | | and/or external) |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | int\_{network-role}\ | **MUST** | VNF Heat |
+| Subnet | _subnet\_{index} | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron::Net| int\_{network-role}\ | **MUST** | VNF Heat |
+| | _network | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. There |
+| | | | is no {index} |
+| | | | because |
+| | | | {nework-role} |
+| | | |should be unique. |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova:: | {vm-type}\_keypair\ | **SHOULD** | Key Pair |
+| Keypair | _{index} | | applicable to one|
+| | | | a{vm-type} |
++-----------------+-------------------------+-------------+------------------+
+| | {vnf-type}_keypair | **SHOULD** | Key Pair |
+| | | | applicable to all|
+| | | | {vm-type} in the |
+| | | | VNF |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova::Server| {vm-type}\_server\ | Mandatory | |
+| | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova:: | {vm-type}_RSG | **SHOULD** | Both formats are |
+| ServerGroup | | | valid. |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}_Server_Grp | **SHOULD** | |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}_ServerGroup | **SHOULD** | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Swift:: | {vm-type}\_RSwiftC | **SHOULD** | |
+| Container | | | |
++-----------------+-------------------------+-------------+------------------+
+
+
+ Table 2: Example OpenStack Heat Resource ID
+
+The table below provides Resource ID Formats for Contrail heat resources.
+ - The Resource ID formats that are marked mandatory must be followed.
+ No deviations are permitted.
+ - The Resource ID formats that are marked optional should be followed.
+ However, deviations in the Resource ID format that is shown is
+ permitted.
+
++-----------------+---------------------+-----------------+-----------------+
+| Resource | Resource ID | Mandatory / | Notes |
+| Type | Format | Optional | |
++=================+=====================+=================+=================+
+| OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** – | The {index} |
+| :InstanceIp | _{network-role}\ | IPv4 address on | that follows |
+| | _vmi\_{index}\ | vmi external | {vm-type} is |
+| | _IP\_{index} | network | the instance of |
+| | | | the {vm_type}. |
+| | | | The {index} |
+| | | | that follows |
+| | | | “vmi” is the |
+| | | | instance of the |
+| | | | “vmi” on the |
+| | | | {vm-type}. |
+| | | | There is no |
+| | | | index after |
+| | | | {network_role} |
+| | | | since since |
+| | | | {network-role} |
+| | | | is unque. The |
+| | | | {index} that |
+| | | | follows the |
+| | | | “IP” is the |
+| | | | instance of the |
+| | | | “IP” on the |
+| | | | “vmi” |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _{network-role}\ | IPv6 address on | |
+| | _vmi\_{index}\_v6\ | vmi external | |
+| | _IP\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _int\ | IPv4 address on | |
+| | _{network-role}\ | vmi internal | |
+| | _vmi\_{index}\_IP\ | network | |
+| | _{index} | | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _int\ | IPv6 address on | |
+| | _{network-role}\ | vmi internal | |
+| | _vmi\_{index}\_v6\ | network | |
+| | _IP\_{index} | | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _subint\ | IPv4 address on | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index}\_IP\ | vmi external | |
+| | _{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _subint\ | IPv6 address on | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index}\_v6\ | vmi external | |
+| | _IP\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {network-role}\_RIRT| **MAY** | |
+| :InterfaceRoute | | | |
+| Table | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {network-role}\_RNI | **MAY** | |
+| :NetworkIpam | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RPT | **MAY** | |
+| :PortTuple | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RSHC\ | **MAY** | |
+| :ServiceHealthC | _{LEFT/RIGHT} | | |
+| heck | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RST\ | **MAY** | |
+| :ServiceTemplat | _{index} | | |
+| e | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** - vmi | Resource ID for |
+| :VirtualMachine | _{network-role}\ | attached to an | virtual machine |
+| Interface | _vmi\_{index} | external | interface (vmi) |
+| | | network | connecting to |
+| | | | an external |
+| | | | network. The |
+| | | | {index} that |
+| | | | follows |
+| | | | {vm-type} is |
+| | | | the instance of |
+| | | | the {vm_type}. |
+| | | | The {index} |
+| | | | that follows |
+| | | | “vmi” is the |
+| | | | instance of the |
+| | | | “vmi” on the |
+| | | | {vm-type}. |
+| | | | There is no |
+| | | | index after |
+| | | | {network_role} |
+| | | | since since |
+| | | | {network-role} |
+| | | | is unque to the |
+| | | | AIC LCP; there |
+| | | | should only be |
+| | | | one instance. |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** - vmi | |
+| | _int\ | attached to an | |
+| | _{network-role}\ | internal | |
+| | _vmi\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** - vmi | |
+| | _subint\ | attached to a | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | int\_{network-role}\| **MAY** | VNF Heat |
+| :VirtualNetwork | _RVN | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. There |
+| | | | is no {index} |
+| | | | because |
+| | | | {nework-role} |
+| | | | should be |
+| | | | unique. Both |
+| | | | formats are |
+| | | | valid. |
++-----------------+---------------------+-----------------+-----------------+
+| | int\_{network-role}\| **MAY** | |
+| | _network | | |
++-----------------+---------------------+-----------------+-----------------+
+
+ Table 3: Example Contrail Heat resource ID
+
+There is a use case where the template filename is used as the type: as
+shown in the example below. There is no suggested Resource ID naming
+convention for this use case.
+
+Example: Template Filename used as the type:
+
+.. code-block:: python
+
+ heat_template_version: 2015-04-30
+
+ resources:
+ <Resource ID>:
+ type: file.yaml
+ properties:
+ ...
+
+Resource: OS::Nova::Server - Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The resource OS::Nova::Server manages the running virtual machine (VM)
+instance within an OpenStack cloud. (See
+https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
+
+Four properties of this resource must follow the ONAP parameter naming
+convention. The four properties are:
+
+1. image
+
+2. flavor
+
+3. name
+
+4. availability\_zone
+
+Requirement R-01455 defines how the ‘{vm-type]’ is defined.
+
+Requirement R-82481 defines how the ‘{vm-type} is used.’
+
+The table below provides a summary. The sections that follow provides
+the detailed requirements.
+
+.. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
+ :header: Property Name,Parameter Type,Parameter Name,Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
+
+ image, string, {vm-type}\_image\_name, Environment File
+ flavor, string, {vm-type}\_flavor\_name, Environment File
+ name, string, {vm-type}\_name\_{index}, ONAP
+ name, CDL, {vm-type}_names, ONAP
+ availability_zone, string, availability\_zone\_{index}, ONAP
+
+Property: image
++++++++++++++++
+
+R-71152 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
+type: ‘string’.
+
+R-58670 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_image_name’.
+
+R-91125 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in
+the Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
+
+R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’
+**MUST** have a unique parameter name for the ‘OS::Nova::Server’
+property ‘image’ even if more than one {vm-type} shares the same image.
+
+*Example Parameter Definition*
+
+.. code-block:: yaml
+
+ parameters:
+ {vm-type}_image_name:
+ type: string
+ description: {vm-type} server image
+
+Property: flavor
+++++++++++++++++
+
+R-50436 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
+type: ‘string’.
+
+R-45188 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_flavor_name’.
+
+R-69431 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the
+Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
+
+R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST**
+have a unique parameter name for the ‘OS::Nova::Server’ property
+‘flavor’ even if more than one {vm-type} shares the same flavor.
+
+*Example Parameter Definition*
+
+.. code-block:: yaml
+
+ parameters:
+ {vm-type}_flavor_name:
+ type: string
+ description: {vm-type} flavor
+
+Property: Name
+++++++++++++++
+
+R-51430 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as
+either type ‘string’ or type ‘comma_delimited_list”.
+
+R-54171 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+the parameter name **MUST** follow the naming convention
+‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts
+at zero and increments by one.
+
+R-40899 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource
+associated with the ‘{vm-type}’.
+
+R-87817 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a
+‘comma_delimited_list’, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_names’.
+
+R-85800 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a
+‘comma_delimited_list’, a parameter **MUST** be delcared once for all
+‘OS::Nova::Server’ resources associated with the ‘{vm-type}’.
+
+R-22838 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated
+in the Heat Orchestration Template’s Environment File.
+
+If a VNF’s Heat Orchestration Template’s contains more than three
+OS::Nova::Server resources of a given {vm-type}, the comma_delimited_list
+form of the parameter name (i.e., ‘{vm-type}_names’) should be used to
+minimize the number of unique parameters defined in the template.
+
+
+*Example: Parameter Definition*
+
+.. 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: comma_delimited_list*
+
+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_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [lb_names, 0] }
+ ...
+
+ lb_server_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_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_0 }
+ ...
+
+ lb_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_1 }
+ ...
+
+Contrail Issue with Values for OS::Nova::Server Property Name
+_____________________________________________________________
+
+R-44271 The VNF's Heat Orchestration Template's Resource
+'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
+contain special characters since the Contrail GUI has a limitation
+displaying special characters.
+
+However, if special characters must be used, the only special characters
+supported are:
+
+--- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _
+
+
+Property: availability\_zone
+++++++++++++++++++++++++++++
+
+R-98450 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter name
+**MUST** follow the naming convention ‘availability\_zone\_{index}’
+where the ‘{index}’ **MUST** start at zero and increment by one.
+
+R-23311 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST**
+be declared as type: ‘string’.
+
+The parameter must not be declared as type ‘comma_delimited_list’,
+ONAP does not support it.
+
+R-59568 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT**
+be enumerated in the Heat Orchestration Template’s Environment File.
+
+Example Parameter Definition
+
+.. code-block:: python
+
+ parameters:
+ availability_zone_{index}:
+ type: string
+ description: availability zone {index} name
+
+Requirement R-90279 states that a VNF Heat Orchestration’s template’s
+parameter MUST be used in a resource with the exception of the parameters
+for the OS::Nova::Server resource property availability_zone.
+
+R-01359 A VNF’s Heat Orchstration Template that contains an
+‘OS::Nova:Server’ Resource **MAY** define a parameter for the property
+‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’
+resources in the Heat Orchestration Template.
+
+Example
++++++++
+
+The example below depicts part of a Heat Orchestration Template that
+uses the four OS::Nova::Server properties discussed in this section.
+
+In the Heat Orchestration Template below, four Virtual
+Machines (OS::Nova::Server) are created: two dns servers with
+{vm-type} set to “dns” and two oam servers with {vm-type} set to “oam”.
+Note that the parameter associated with the property name is a
+comma_delimited_list for dns and a string for oam.
+
+.. code-block:: python
+
+ parameters:
+
+ dns_image_name:
+ type: string
+ description: dns server image
+
+ dns_flavor_name:
+ type: string
+ description: dns server flavor
+
+ dns_names:
+ type: comma_delimited_list
+ description: dns server names
+
+ oam_image_name:
+ type: string
+ description: oam server image
+
+ oam_flavor_name:
+ type: string
+ description: oam server flavor
+
+ oam_name_0:
+ type: string
+ description: oam server name 0
+
+ oam_name_1:
+ type: string
+ description: oam server name 1
+
+ availability_zone_0:
+ type: string
+ description: availability zone ID or Name
+
+ availability_zone_1:
+ type: string
+ description: availability zone ID or Name
+
+ resources:
+
+ dns_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, 0 ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+
+ . . .
+
+ dns_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, 1 ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
+
+ . . .
+
+ oam_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_name_0 }
+ image: { get_param: oam_image_name }
+ flavor: { get_param: oam_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+
+ . . .
+
+ oam_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_name_1 }
+ image: { get_param: oam_image_name }
+ flavor: { get_param: oam_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
+
+ . . .
+
+Boot Options
+++++++++++++
+
+R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
+boot from a Cinder Volume.
+
+R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the
+‘OS::Nova::Server’ resource property ‘image’ **MUST** be used.
+
+The requirements associated with
+the 'image' property are detailed in `Property: image`_
+
+R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the
+‘OS::Nova::Server’ resource property ‘block_device_mapping’ or
+‘block_device_mapping_v2’ **MUST** be used.
+
+There are currently no heat guidelines
+associated with these two properties:
+'block_device_mapping' and 'block_device_mapping_v2'.
+
+Resource: OS::Nova::Server – Metadata Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OS::Nova::Server Resource property metadata is an optional
+OpenStack property.
+The table below summarizes the mandatory and optional metadata
+supported by ONAP.
+
+The sections that follow provides the requirements associated with each
+metadata parameter.
+
+.. csv-table:: **Table 5 OS::Nova::Server Mandatory and Optional Metadata**
+ :header: Metadata Parameter Name, Parameter Type, Required, Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
+
+ vnf_id, string, **MUST**, ONAP
+ vf_module_id, string, **MUST**, ONAP
+ vnf_name, string, **MUST**, ONAP
+ vf_module_name, string, **SHOULD**, ONAP
+ vm_role, string, **MAY**, YAML or Environment File
+ vf_module_index, string, **MAY**, ONAP
+ workload_context, string, **SHOULD**, ONAP
+ environment_context, string, **SHOULD**, ONAP
+
+vnf\_id
++++++++
+
+The OS::Nova::Server Resource metadata map value parameter 'vnf_id'
+is an ONAP generated UUID that identifies the VNF. The value
+is provided by ONAP to the VNF's Heat Orchestration
+Template at orchestration time.
+
+R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
+
+R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST** be declared
+as type: ‘string’.
+
+R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have
+parameter contraints defined.
+
+R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
+
+R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ is passed into a
+Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change.
+
+
+*Example 'vnf_id' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_id:
+ type: string
+ description: Unique ID for this VNF instance
+
+vf\_module\_id
+++++++++++++++
+
+The OS::Nova::Server Resource metadata map value parameter 'vf\_module\_id'
+is an ONAP generated UUID that identifies the VF Module (e.g., Heat
+Orchestration Template). The value
+is provided by ONAP to the VNF's Heat Orchestration
+Template at orchestration time.
+
+R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vf\_module\_id’.
+
+R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST**
+be declared as type: ‘string’.
+
+R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+have parameter contraints defined.
+
+R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf_module_id’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_id’
+**MUST NOT** change.
+
+*Example 'vf\_module\_id' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_module_id:
+ type: string
+ description: Unique ID for this VNF module instance
+
+
+vnf\_name
++++++++++
+
+The OS::Nova::Server Resource metadata map value parameter 'vnf_name'
+is the ONAP generated alphanumeric name of the deployed VNF instance.
+The value
+is provided by ONAP to the VNF's Heat Orchestration
+Template at orchestration time.
+The parameter must be declared as type: string
+
+R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vnf_name’.
+
+R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+declared as type: ‘string’.
+
+R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have
+parameter contraints defined.
+
+R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
+
+R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ is passed into a
+Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change.
+
+*Example 'vnf_name' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_name:
+ type: string
+ description: Unique name for this VNF instance
+
+vf\_module\_name
+++++++++++++++++
+
+The OS::Nova::Server Resource metadata map value parameter 'vf_module_name'
+is the deployment name of the heat stack created (e.g., <STACK_NAME>) from the
+VNF's Heat Orchestration template
+in the command 'Heat stack-create'
+(e.g., 'Heat stack-create [-f <FILE>] [-e <FILE>] <STACK_NAME>').
+The 'vf_module_name' (e.g., <STACK_NAME> is specified as
+part of the orchestration process.
+
+R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘vf\_module\_name’.
+
+R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ **MUST**
+be declared as type: ‘string’.
+
+R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** have parameter contraints defined.
+
+R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+environment file.
+
+R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_name’
+**MUST NOT** change.
+
+*Example 'vf_module_name' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vf_module_name:
+ type: string
+ description: Unique name for this VNF Module instance
+
+vm\_role
+++++++++
+
+The OS::Nova::Server Resource metadata map value parameter 'vm-role'
+is a metadata tag that describes the role of the Virtual Machine.
+The 'vm_role' is stored in ONAP's A&AI module and is
+available for use by other ONAP components and/or north bound systems.
+
+R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter ‘vm_role’.
+
+R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST** be
+declared as type: ‘string’.
+
+R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST NOT** have
+parameter contraints defined.
+
+R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+either
+
+ - enumerated in the VNF’s Heat Orchestration
+ Template’s environment file.
+
+ - hard coded in the VNF’s Heat Orchestration
+ Template’s OS::Nova::Resource metadata property.
+
+Defining the 'vm_role' as the '{vm-type}' is a recommended convention
+
+R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ value **MUST only**
+contain alphanumeric characters and underscores ‘_’.
+
+R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ is passed into a
+Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change.
+
+
+*Example 'vm_role' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vm_role:
+ type: string
+ description: Unique role for this VM
+
+*Example: 'vm-role' Definition: Hard Coded in
+OS::Nova::Resource metadata property*
+
+.. code-block:: python
+
+ resources:
+
+ dns_server_0
+ type: OS::Nova::Server
+ properties:
+ . . . .
+ metadata:
+ vm_role: dns
+
+*Example 'vm-role' Definition: Defined in Environment file
+and retrieved via 'get_param'*
+
+.. code-block:: python
+
+ resources:
+
+ dns_server_0:
+ type: OS::Nova::Server
+ properties:
+ . . . .
+ metadata:
+ vm_role: { get_param: vm_role }
+
+Example vnf_id, vf_module_id, vnf_name, vf_module_name, vm_role
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+The example below depicts part of a Heat Orchestration Template
+that uses the five of the OS::Nova::Server metadata parameter
+discussed in this section. 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
+ 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
+ vm_role:
+ type: string
+ description: Unique role for this VM
+ resources:
+ lb_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_0 }
+ ...
+ 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 }
+ vm_role: lb
+
+vf\_module\_index
++++++++++++++++++
+
+R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter
+‘vf\_module\_index’.
+
+R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be
+declared as type: ‘number’.
+
+R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+have parameter contraints defined.
+
+R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_index’
+**MUST NOT** change.
+
+R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be
+used in a VNF’s Volume Template; it is not supported.
+
+The vf_module_index parameter indicates which instance of the module is being
+deployed into the VNF.
+This parameter may be used in cases where multiple instances of the same
+incremental module may be instantiated for scaling purposes. The index
+can be used in the Heat Orchestration Template for indexing into a
+pseudo-constant array parameter when unique values are required for each
+module instance, e.g., for fixed private IP addresses on VM types.
+
+The vf_module_index will start at 0 for the first instance of a module
+type. Subsequent instances of the same module type will receive the
+lowest unused index. This means that indexes will be reused if a module
+is deleted and re-added. As an example, if three copies of a module are
+deployed with vf_module_index values of 0, 1, and 2 then subsequently
+the second one is deleted (index 1), and then re-added, index 1 will be
+reused.
+
+*Example*
+
+In this example, the {vm-type} has been defined as oam_vm to represent
+an OAM VM. An incremental heat module is used to deploy the OAM VM. The
+OAM VM attaches to an internal control network which has a
+{network-role} of ctrl. A maximum of four OAM VMs can be deployed. The
+environment file contains the four IP addresses that each successive OAM
+VM will be assigned. The vf_module_index is used as the index to
+determine the IP assignment.
+
+Environment File
+
+.. code-block:: python
+
+ parameters:
+ oam_vm_int_ctrl_ips: 10.10.10.1,10.10.10.2,10.10.10.3,10.10.10.4
+
+YAML File
+
+.. code-block:: python
+
+ parameters:
+ vf_module_index:
+ type: number
+ description: Unique index for this VNF Module instance
+ oam_vm_name_0:
+ type: string
+ description: VM Name for lb VM 0
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for the internal control network
+ oam_vm_int_ctrl_ips:
+ type: comma_delimited_list
+ description: Fixed IP assignments for oam VMs on the internal control
+ network
+ resources:
+ oam_vm_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_vm_name_0 }
+ networks:
+ - port: { get_resource: oam_vm_0_int_ctrl_port_0 }
+ . . .
+ metadata:
+ vf_module_index: { get_param: vf_module_index }
+ oam_vm_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ oam_vm_int_ctrl_ips, { get_param, vf_module_index]}}}]
+
+workload_context
+++++++++++++++++
+
+R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘workload_context’.
+
+R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST** be
+declared as type: ‘string’.
+
+R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ is passed
+into a Nested YAML file, the parameter name ‘workload_context’
+**MUST NOT** change.
+
+The 'workload_context' parameter value will be chosen by the Service Model
+Distribution context client in VID and will be supplied to the
+Heat Orchestration Template by ONAP at orchestration time.
+
+*Example Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+ workload_context:
+ type: string
+ description: Workload Context for this VNF instance
+
+
+*Example OS::Nova::Server with metadata*
+
+.. code-block:: python
+
+ resources:
+ . . .
+
+ {vm-type}_server_{index}:
+ type: OS::Nova::Server
+ properties:
+ name:
+ flavor:
+ image:
+ ...
+ 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 }
+ workload_context: {get_param: workload_context}
+
+environment_context
++++++++++++++++++++
+
+R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘environment_context’.
+
+R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST**
+be declared as type: ‘string’.
+
+R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ is
+passed into a Nested YAML file, the parameter name
+‘environment_context’ **MUST NOT** change.
+
+The 'environment_context' parameter value will be defined by the
+service designer as part of the service model during the SDC
+on-boarding process and will be supplied to the Heat Orchestration
+Template by ONAP at orchestration time.
+
+
+*Example Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+ environment_context:
+ type: string
+ description: Environment Context for this VNF instance
+
+
+*Example OS::Nova::Server with metadata*
+
+.. code-block:: python
+
+ resources:
+ . . .
+
+ {vm-type}_server_{index}:
+ type: OS::Nova::Server
+ properties:
+ name:
+ flavor:
+ image:
+ ...
+ 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 }
+ workload_context: {get_param: workload_context}
+ environment_context: {get_param: environment_context }
+
+
+Resource: OS::Neutron::Port - Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The resource OS::Neutron::Port is for managing Neutron ports (See
+https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
+
+Introduction
+++++++++++++
+
+Four properties of the resource OS::Neutron::Port that must follow the
+ONAP parameter naming convention. The four properties are:
+
+1. network
+2. fixed_ips, ip_address
+3. fixed_ips, subnet_id or fixed_ips, subnet
+
+ * Note that in many examples in this document fixed_ips, subnet_id is used.
+
+4. allowed_address_pairs, ip_address
+
+Below is a generic example. Note that for some parameters
+comma_delimited_list are supported in addition to String.
+
+.. code-block:: python
+
+ resources:
+
+ ...
+
+ <resource ID>:
+ type: OS::Neutron::Port
+ properties:
+ allowed_address_pairs: [{"ip_address": String, "mac_address": String},
+ {"ip_address": String, "mac_address": String}, ...]
+ fixed_ips: [{"ip_address": String, "subnet_id": String, "subnet":
+ String}, {"ip_address": String, "subnet_id": String, "subnet": String},
+ ...]
+ network: String
+
+The parameters associated with these properties may reference an
+external network or internal network. External networks and internal
+networks are defined in `Networking`_.
+
+When the OS::Neutron::Port is attaching to an external network, all
+property values are parameters that are retrieved via the intrinsic
+function 'get_param'.
+
+When the OS::Neutron::Port is attaching to an internal network, a
+property value maybe retrieved via the intrinsic
+function 'get_param', 'get_resource', or 'get_attr'.
+
+This will be described in the forth coming sections.
+
+Items to Note
+_____________
+
+A network (internal or external) may contain one or or more subnets.
+
+A VNF can have one or more ports connected to the same network.
+
+A port can have one or more IP addresses assigned.
+
+The IP address assignments can be IPv4 addresses and/or IPv6 addresses.
+
+The IP addresses assignments for a unique external network **MUST**
+be all Cloud Assigned addresses OR **MUST** be all ONAP
+SDN-C assigned IP addresses.
+
+If the IP addresses are Cloud Assigned, all the IPv4 Addresses **MUST**
+be from
+the same subnet and all the IPv6 Addresses **MUST** be from the
+same subnet.
+
+If the IP addresses are ONAP SDN-C assigned,
+the IPv4 Addresses **MAY**
+be from
+different subnets and the IPv6 Addresses **MAY** be from different
+subnets.
+
+If a VNF's Port is attached to an external network the IP addresses **MAY**
+either be assigned by
+
+ 1. ONAP's SDN-Controller (SDN-C)
+ 2. Cloud Assigned by OpenStack’s DHCP Service
- - ONAP will supply the volume template outputs automatically to
- the bases/incremental template input parameters.
+If a VNF's Port is attached to an external network and the port's IP addresses
+are assigned by ONAP's SDN-Controller, the 'OS::Neutron::Port' Resource's
-- Volume modules may utilize nested Heat templates.
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used
-**Example (volume template):**
+If a VNF's Port is attached to an external network and the port's IP addresses
+are Cloud Assigned by OpenStack’s DHCP Service,
+the 'OS::Neutron::Port' Resource's
- In this example, the {vm-type} has been left as a variable.
- {vm-type} is described in section 5.b {vm-type}. If the VM was a load
- balancer, the {vm-type} could be defined as “lb”
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
-.. code-block:: python
+If a VNF's Port is attached to an internal network and the port's IP addresses
+are assigned by the VNF's Heat Orchestration Template
+(i.e., enumerated in the Heat Orchestration Template's environment file),
+the 'OS::Neutron::Port' Resource's
- parameters:
- vm-typevnf\_name:
- type: string
- {vm-type}\_volume\_size\_0:
- type: number
- ...
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id'
+ **MUST NOT** be used
- 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}
- ...
+If a VNF's Port is attached to an internal network and the port's IP addresses
+are Cloud Assigned by OpenStack’s DHCP Service,
+the 'OS::Neutron::Port' Resource's
-*(+ additional volume definitions)*
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
-.. code-block:: python
+If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
+'fixed_ips' map property 'ip_address' is specified, then the
+'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT**
+be specified.
- outputs:
- {vm-type}\_volume\_id\_0:
- value: {get\_resource: {vm-type}\_volume\_0}
- ...
+If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
+'fixed_ips' map property 'subnet'/'subnet_id' is specified, then the
+'fixed_ips' map property 'ip_address' **MUST NOT**
+be specified.
-*(+ additional volume outputs)*
+.. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
+ :header: Resource,Property,Parameter Type,Parameter Name,Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
-*Example (VNF module template):*
+ OS::Nova::Server, image, string, {vm-type}_image_name, Environment File
-.. code-block:: python
+Property: network
++++++++++++++++++
- parameters:
- {vm-type}\_name\_0:
- type: string
- {vm-type}\_volume\_id\_0:
- type: string
- ...
+The Resource 'OS::Neutron::Port' property 'network' determines what network
+the port is attached to.
- 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 }
+R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘network’ parameter **MUST** be declared as type: ‘string’.
-Nested Heat Templates
----------------------
+R-62983 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external network,
+the ‘network’ parameter name **MUST**
-ONAP 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*).
+- follow the naming convention ‘{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘{network-role}_net_name’ if the OpenStack
+ network name is used to reference the network.
-Nested template support in ONAP is subject to the following
-limitations:
+where ‘{network-role}’ is the network-role of the external network and
+a ‘get_param’ **MUST** be used as the intrinsic function.
-- Heat templates for ONAP must only have one level of nesting.
- ONAP only supports one level of nesting.
+R-86182 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an internal network,
+and the internal network is created in a different
+Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
+parameter name **MUST**
-- Nested templates must be referenced by file name in the master
- template
+- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘int\_{network-role}_net_name’ if the
+ OpenStack network name in is used to reference the network.
- - i.e. use of *resource\_registry* in the .env file is *not*
- currently supported
+where ‘{network-role}’ is the network-role of the internal network
+and a ‘get_param’ **MUST** be used as the intrinsic function.
-- Nested templates must have unique file names within the scope of the
- VNF
+In Requirement R-86182, the internal network is created in the VNF's
+Base Module (Heat Orchestration Template) and the parameter name is
+declared in the Base Module's outputs' section.
+The output parameter name will be declared as a parameter in the
+'parameters' section of the incremental module.
-- ONAP does not support a directory hierarchy for nested
- templates. All templates must be in a single, flat directory (per
- VNF)
+R-93177 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an internal
+network, and the internal network is created in the same Heat
+Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
+parameter name **MUST** obtain the UUID of the internal network
+by using the intrinsic function ‘get_resource’ or ‘get_attr’
+and referencing the Resource ID of the internal network.
-- A nested template may be shared by all Modules (i.e., Heat templates)
- within a given VNF
+R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’
+property ‘network’ parameter **MUST NOT** be enumerated in the Heat
+Orchestration Template’s Environment File.
-Networking
-----------
+The parameter values for external networks are provided by ONAP
+to the VNF's Heat Orchestration Template at orchestration time.
-External Networks
------------------
+The parameter values for internal networks created in the VNF's Base Module
+Heat Orchestration Template
+are provided to the VNF's Incremental Module Heat Orchestration Template
+at orchestration time.
-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.
+*Example Parameter Definition of External 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 5.b {network-role}).
+.. code-block:: python
-- 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.
+ parameters:
-- VNF templates must pass the appropriate external network IDs into
- nested VM templates when nested Heat is used.
+ {network-role}_net_id:
+ type: string
+ description: Neutron UUID for the external {network-role} network
-- VNFs may use DHCP assigned IP addresses or assign fixed IPs when
- attaching VMs to an external network.
+ {network-role}_net_name:
+ type: string
+ description: Neutron name for the external {network-role} network
-- ONAP enforces a naming convention for parameters associated with
- external networks.
-- Parameter values associated with an external network will be
- generated and/or assigned by ONAP at orchestration time.
+*Example Parameter Definition of Internal Networks in an Incremental Module*
-- Parameter values associated with an external network must not be
- enumerated in the environment file.
+.. code-block:: python
-Internal Networks
------------------
+ parameters:
-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.
+ int_{network-role}_net_id:
+ type: string
+ description: Neutron UUID for the internal int_{network-role} network
-- Internal networks must not attach to any external gateways and/or
- routers. Internal networks are for intra-VM communication only.
+ int_{network-role}_net_name:
+ type: string
+ description: Neutron name for the internal int_{network-role} network
-- In the modular approach, internal networks must be created in the
- Base Module template, with their resource IDs exposed as outputs
- (i.e., ONAP 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 5.b {network-role}).
+Property: fixed_ips, Map Property: ip_address
++++++++++++++++++++++++++++++++++++++++++++++
-- VNFs may use DHCP assigned IP addresses or assign fixed IPs when
- attaching VMs to an internal network.
+The resource 'OS::Neutron::Port' property 'fixed_ips'
+map property 'ip_address'
+is used to assign one IPv4 or IPv6
+addresses to port.
-- ONAP does not enforce a naming convention for parameters for
- internal network, however, a naming convention is provided that
- should be followed.
+One 'OS::Neutron::Port' resource may assign one or more
+IPv4 and/or IPv6 addresses.
-- Parameter values associated with an internal network must either be
- passed as output parameter from the base template (i.e., ONAP
- Base Template Output Parameters) into the add-on modules or be
- enumerated in the environment file.
+R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST**
+be declared as either type ‘string’ or type ‘comma_delimited_list’.
-IP Address Assignment
----------------------
+R-40971 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 address is
+assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined
+as a string, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_{network-role}\_ip\_{index}’, where
-- VMs connect to external networks using either fixed (e.g. statically
- assigned) IP addresses or DHCP assigned IP addresses.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
-- VMs connect to internal networks using either fixed (e.g. statically
- assigned) IP addresses or DHCP assigned IP addresses.
+R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
-- Neutron Floating IPs must not be used. ONAP does not support
- Neutron Floating IPs.
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-- ONAP supports the OS::Neutron::Port property
- “allowed\_address\_pairs.” See Section 5.b Property: allowed_address_pairs.
+*Example External Network IPv4 Address string Parameter Definition*
-Parameter Naming Convention
----------------------------
+.. code-block:: python
-{vm-type}
----------
+ parameters:
-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:
+ {vm-type}_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
-- The four ONAP Metadata parameters must not be prefixed with a
- common {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
- *vf\_module\_id*, *vf\_module\_name*.
+R-04697 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external
+network, and an IPv4 address is assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type
+is defined as a comma_delimited_list, the parameter name **MUST**
+follow the naming convention ‘{vm-type}_{network-role}_ips’,
+where
-- Parameters only referring to a network or subnetwork must not be
- prefixed with a common {vm-type} identifier.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
-- The parameter referring to the OS::Nova::Server property
- availability\_zone must not be prefixed with a common {vm-type}
- identifier.
+R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s
+Heat Orchestration Template’s Environment File.
-- {vm-type} must be unique to the VNF. It does not have to be globally
- unique across all VNFs that ONAP supports.
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-{network-role}
---------------
+*Example External Network IPv4 Address comma_delimited_list
+Parameter Definition*
-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.
+.. code-block:: python
-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}.
+ parameters:
-“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 5.b Property: network & subnet.
+ {vm-type}_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the {network-role} network
-Any parameter that is associated with an external network must include
-the {network-role} as part of the parameter name.
+R-71577 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where
-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.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
-Resource: OS::Nova::Server - Parameters
----------------------------------------
-
-The following OS::Nova::Server Resource Property Parameter Names must
-follow the ONAP parameter Naming Convention. All the parameters
-associated with OS::Nova::Server are classified as ONAP
-Orchestration Parameters.
-
-+----------------------+-----------------------------------------+------------------+
-| OS::Nova::Server |
-+======================+=========================================+==================+
-| Property | ONAP 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
-~~~~~~~~~~~~~~~
+R-87123 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration
+Template’s Environment File.
-Image is an ONAP 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.
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-The parameters must be named *“{vm-type}\_image\_name”* in the VNF.
+*Example External Network IPv6 Address string Parameter Definition*
-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.
+.. code-block:: python
-Property: flavor
-~~~~~~~~~~~~~~~~
+ parameters:
-Flavor is an ONAP 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.
+ {vm-type}_{network-role}_v6_ip_{index}:
+ type: string
+ description: Fixed IPv6 assignment for {vm-type} VM {index} on the {network-role} network
-The parameters must be named *“{vm-type}\_flavor\_name”* for each
-*{vm-type}* in the VNF.
+R-23503 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}_{network-role}_v6_ips’, where
-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.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
-Property: Name
-~~~~~~~~~~~~~~
+R-93030 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
-Name is an OpenEOMP Orchestration parameter; the value is provided to
-the Heat template by ONAP.
+ONAP's SDN-Controller assigns the IP Address and ECOMP provides
+the value at orchestration to the Heat Orchestration Template.
-VM names (hostnames) for assignment to VM instances must be passed to
-Heat templates either as
+*Example External Network IPv6 Address comma_delimited_list Parameter
+Definition*
-- an array (comma delimited list) for each VM type
+.. code-block:: python
-- a set of fixed-index parameters for each VM type instance.
+ parameters:
-Each element in the VM Name list should be assigned to successive
-instances of that VM type.
+ {vm-type}_{network-role}_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
-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:
+R-78380 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where
-- If the parameter type is a comma delimited list: {**vm-type**}\_names
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
-- If the parameter type is a string with a fixed index:
- {**vm-type**}\_name\_{**index**}
+R-28795 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated
+in the VNF’s Heat Orchestration Template’s Environment File.
-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.
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-*Examples:*
+*Example Internal Network IPv4 Address string Parameter Definition*
.. 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}
+ parameters:
-*Example (CDL):*
+ {vm-type}_int_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the int_{network-role} network
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+R-85235 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_ips’, where
-.. code-block:: python
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
- 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.
+R-90206 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
+
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
.. 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 }
- ...
+ parameters:
-Property: availability\_zone
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ {vm-type}_int_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
-Availability\_zone is an ONAP Orchestration parameter; the value is
-provided to the Heat template by ONAP.
+R-27818 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where
-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.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
-The availability zone parameter must be defined as
-“availability\_zone\_{index}”, with the {index} starting at zero.
+R-97201 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’
+**MUST** be enumerated in the VNF’s Heat Orchestration
+Template’s Environment File.
-*Example:*
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+*Example Internal Network IPv6 Address string Parameter Definition*
.. 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 }
- ...
+ parameters:
-Resource: OS::Nova::Server - Metadata
--------------------------------------
+ {vm-type}_int_{network-role}_v6_ip_{index}:
+ type: string
+ description: Fixed IPv6 assignment for {vm-type} VM {index} on the int_{network-role} network
-This section describes the ONAP Metadata parameters.
+R-29765 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_v6_ips’, where
-ONAP 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
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
-ONAP Heat templates may include the following parameter that is
-used as metadata under the resource OS::Nova:Server: vf\_module\_name.
+*Example Internal Network IPv6 Address comma_delimited_list Parameter
+Definition*
-These parameters are all classified as ONAP Metadata.
+.. code-block:: python
-+---------------------------+------------------+----------------------+
-| 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 |
-+---------------------------+------------------+----------------------+
+ parameters:
- Table 3 ONAP Metadata
+ {vm-type}_int_{network-role}_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
-Required Metadata Elements
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+R-98569 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
-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 ONAP to associate the servers with the
-VNF instance.
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-- vnf\_id
+R-62590 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an external network, i.e.,
- - *“vnf\_id”* parameter value will be supplied by ONAP.
- ONAP generates the UUID that is the vnf\_id and supplies it
- to the Heat at orchestration time.
+- {vm-type}_{network-role}\_ip\_{index}
+- {vm-type}_{network-role}\_ip\_v6\_{index}
+- {vm-type}_{network-role}_ips
+- {vm-type}_{network-role}_v6_ips
-- vf\_module\_id
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+Environment File. ONAP provides the IP address assignments at
+orchestration time.
- - “\ *vf\_module\_id”* parameter value will be supplied by
- ONAP. ONAP generates the UUID that is the vf\_module\_id
- and supplies it to the Heat at orchestration time.
+R-93496 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an internal network, i.e.,
-- vnf\_name
+- {vm-type}\_int\_{network-role}\_ip\_{index}
+- {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
+- {vm-type}\_int\_{network-role}_ips
+- {vm-type}\_int\_{network-role}_v6_ips
- - “\ *vnf\_name”* parameter value will be generated and/or assigned
- by ONAP and supplied to the Heat by ONAP at
- orchestration time.
+**MUST** be enumerated in the Heat Orchestration Template’s Environment
+File and IP addresses **MUST** be assigned.
-Optional Metadata Elements
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Summary Table
+_____________
-The following metadata element is optional for *OS::Nova::Server*
-resources:
+.. csv-table:: **Table # OS::Neutron::Port Property fixed_ips map property ip_address Parameter Naming Convention**
+ :header: Resource,Property,Map Property,Network Type,IP Address,Parameter Type,Parameter Name, Environment File
+ :align: center
+ :widths: auto
-- *vf\_module\_name*
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, string, {vm-type}\_{network-role}\_ip\_{index}, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, comma\_delimited\_list, {vm-type}\_{network-role}\_ips, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, string, {vm-type}\_{network-role}\_v6\_ip\_{index}, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, comma\_delimited\_list, {vm-type}\_{network-role}\_v6\_ips, NO
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, string, {vm-type}\_int\_{network-role}\_ip\_{index}, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_ips, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, string, {vm-type}\_int\_{network-role}\_v6\_ip\_{index}, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_v6\_ips, YES
- - 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 ONAP to the Heat at orchestration time. The parameter will
- be generated and/or assigned by ONAP and supplied to the Heat
- by ONAP at orchestration time.
+Examples
+________
-*Example*
+*Example: comma_delimited_list parameters for IPv4 and IPv6 Address
+Assignments to an external network*
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+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:
- 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 }
- ...
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for a oam network
+ db_oam_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for db VMs on the oam network
+ db_oam_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for db VMs on the oam network
+ resources:
+ db_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {
+ “ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
+ db_1_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
+ - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
+
+*Example: string parameters for IPv4 and IPv6 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.
-Resource: OS::Neutron::Port - Parameters
-----------------------------------------
-
-The following four OS::Neutron::Port Resource Property Parameters must
-adhere to the ONAP 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
-ONAP Orchestration Parameter. The parameter value must be supplied
-by ONAP. The parameters must adhere to the ONAP 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., ONAP
-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
+.. code-block:: python
-*Example:*
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for an OAM network
+ db_oam_ip_0:
+ type: string
+ description: Fixed IPv4 assignment for db VM 0 on the OAM network
+ db_oam_ip_1:
+ type: string
+ description: Fixed IPv4 assignment for db VM 1 on the OAM network
+ db_oam_v6_ip_0:
+ type: string
+ description: Fixed IPv6 assignment for db VM 0 on the OAM network
+ db_oam_v6_ip_1:
+ type: string
+ description: Fixed IPv6 assignment for db VM 1 on the OAM network
+ resources:
+ db_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, { “ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
+ db_1_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: db_oam_ip_1}}]
+ - “ip_address”: {get_param: db_oam_v6_ip_1}}]
+
+
+*Example: comma_delimited_list parameters for IPv4 and IPv6 Address
+Assignments to an internal network*
+
+In this example, the '{network-role}' has been defined as 'ctrl' to
+represent an ctrl network internal to the vnf.
+The '{vm-type}' has been defined as 'db' for
+database.
.. 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
+ parameters:
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for the ctrl internal network
+ db_int_ctrl_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for db VMs on the ctrl internal
+ network
+ db_int_ctrl_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for db VMs on the ctrl internal
+ network
+ resources:
+ db_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ db_int_ctrl_ips, 0 ]}}, {
+ “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 0 ]}}]
+ db_1_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: [ db_int_ctrl_ips, 1 ]}
+ - “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 1 ]}
+
+
+*Example: string parameters for IPv4 and IPv6 Address Assignments to an
+internal network*
+
+In this example, the int\_{network-role} has been defined as
+int_ctrl to represent a control network internal to the vnf.
+The {vm-type} has been defined as db for database.
-*Example:*
+.. code-block:: python
-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.
+ parameters:
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for an OAM internal network
+ db_int_ctrl_ip_0:
+ type: string
+ description: Fixed IPv4 assignment for db VM on the oam_int network
+ db_int_ctrl_ip_1:
+ type: string
+ description: Fixed IPv4 assignment for db VM 1 on the oam_int network
+ db_int_ctrl_v6_ip_0:
+ type: string
+ description: Fixed IPv6 assignment for db VM 0 on the oam_int network
+ db_int_ctrl_v6_ip_1:
+ type: string
+ description: Fixed IPv6 assignment for db VM 1 on the oam_int network
+ resources:
+ db_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_oam_int_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {
+ “ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
+ db_1_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_oam_int_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: db_oam_int_ip_1}}]
+ - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
+
+
+Property: fixed\_ips, Map Property: subnet\_id
+++++++++++++++++++++++++++++++++++++++++++++++
+
+The resource 'OS::Neutron::Port' property 'fixed_ips' map
+property 'subnet'/'subnet_id' is used when a
+port is requesting an IP assignment via
+OpenStack’s DHCP Service (i.e., Cloud Assigned).
+
+The IP address assignment will be made from the specified subnet.
+
+Specifying the subnet is not required; it is optional.
+
+If the network (external or internal) that the port is attaching
+to only contains one subnet, specifying the subnet is
+superfluous. The IP address will be assigned from the one existing
+subnet.
+
+If the network (external or internal) that the port is attaching
+to contains two or more subnets, specifying the subnet in the
+'fixed_ips' map property 'subnet'/'subnet_id' determines which
+subnet the IP address will be assigned from.
+
+If the network (external or internal) that the port is attaching
+to contains two or more subnets, and the subnet is not is not
+specified, OpenStack will randomly(?) determine which subnet
+the IP address will be assigned from.
+
+The property fixed_ips is used to assign IPs to a port. The Map Property
+subnet_id specifies the subnet the IP is assigned from.
+
+R-38236 The VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’.
+
+R-62802 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv4
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv4 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_id’, where
+‘{network-role}’ is the network role of the network.
+
+R-83677 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+ONAP's SDN-Controller provides the network's subnet's UUID
+value at orchestration to the Heat Orchestration Template.
+
+*Example Parameter Definition*
.. code-block:: python
- parameters:
- oam\_net\_id:
- type: string
- description: Neutron UUID for the oam network
+ parameters:
- resources:
- lb\_port\_1:
- type: OS::Neutron::Port
- network: { get\_param: oam\_net\_id }
+ {network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the {network-role} network
-Property: fixed\_ips
-~~~~~~~~~~~~~~~~~~~~
+R-15287 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv6 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_v6_id’, where
+‘{network-role}’ is the network role of the network.
-The property “fixed\_ips” in the resource OS::Neutron::Port must be used
-when statically assigning IP addresses.
+R-80829 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
-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.
+ONAP's SDN-Controller provides the network's subnet's UUID
+value at orchestration to the Heat Orchestration Template.
-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.
+*Example Parameter Definition*
-There must be a different parameter name for IPv4 IP addresses and IPv6
-addresses
+.. code-block:: python
-- **Comma-delimited list:** Each element in the IP list should be
- assigned to successive instances of that VM type on that network.
+ parameters:
- - *Format for IPv4 addresses:* {vm-type}\_{network-role}\_ips
+ {network-role}_v6_subnet_id:
+ type: string
+ description: Neutron IPv6 subnet UUID for the {network-role} network
- - *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.
+*Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
+that has two or more IPv4 subnets*
- - *Format for IPv4 addresses:*
- {vm-type}\_{network-role}\_ip\_{index}
+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. The Cloud Assigned IP Address uses the OpenStack DHCP service
+to assign IP addresses.
- - *Format for IPv6 addresses:*
- {vm-type}\_{network-role}\_v6\_ip\_{index}
+.. code-block:: python
-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.
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
+ oam_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the oam network
+ resources:
+ lb_0_oam_port_0:
+ type: OS::Neutron::Port
+ parameters:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - subnet_id: { get_param: oam_subnet_id }
+
+*Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
+address assigned to a network that has at least one IPv4 subnet and one
+IPv6 subnet*
+
+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.
-There must be a different parameter name for IPv4 IP addresses and IPv6
-addresses
+.. code-block:: python
-- **Comma-delimited list:** Each element in the IP list should be
- assigned to successive instances of that VM type on that network.
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
+ oam_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the oam network
+ oam_v6_subnet_id:
+ type: string
+ description: Neutron IPv6 subnet UUID for the oam network
+ resources:
+ lb_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - subnet_id: { get_param: oam_subnet_id }
+ - subnet_id: { get_param: oam_v6_subnet_id }
+
+R-84123 When
+
+- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+ in an Incremental Module is attaching to an internal network
+ that is created in the Base Module, AND
+- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv4 subnet is to be specified using the
+ property ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
+
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the
+network role of the internal network
+
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
+
+R-69634 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+The assumption is that internal networks are created in the base module.
+The Neutron subnet network ID will be passed as an output parameter
+(e.g., ECOMP Base Module Output Parameter) to the incremental modules.
+In the incremental modules, the output parameter name will be defined as
+input parameter.
+
+*Example Parameter Definition*
- - *Format for IPv4 addresses:* {vm-type}\_int\_{network-role}\_ips
+.. code-block:: python
- - *Format for IPv6 addresses:*
- {vm-type}\_int\_{network-role}\_v6\_ips
+ parameters:
-- **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.
+ int_{network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the int_{network-role} network
- - *Format for IPv4 addresses:*
- {vm-type}\_int\_{network-role}\_ip\_{index}
+R-76160 When
- - *Format for IPv6 addresses:*
- {vm-type}\_int\_{network-role}\_v6\_ip\_{index}
+- the VNF’s Heat Orchestration Template’s resource
+ ‘OS::Neutron::Port’ in an Incremental Module is attaching to an
+ internal network that is created in the Base Module, AND
+- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv6 subnet is to be specified using the property
+ ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
-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.
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
+is the network role of the internal network
-*Example (external network)*
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
-.. code-block:: python
+R-22288 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
- 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.
+*Example Parameter Definition*
.. 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.
+ parameters:
-.. code-block:: python
+ int_{network-role}_v6_subnet_id:
+ type: string
+ description: Neutron subnet UUID for the int_{network-role} network
- 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
+Property: allowed\_address\_pairs, Map Property: ip\_address
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+The property allowed\_address\_pairs in the resource OS::Neutron::Port
+allows the user to specify a mac\_address and/or ip\_address that will
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.
+to enable fast data plane failover. The map property ip\_address
+specifies the IP address.
+
+The allowed\_address\_pairs is an optional property. It is not required.
-Note that these parameters are *not* intended to represent Neutron
+An ONAP Heat Orchestration Template allows the assignment of one IPv4
+address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
+and {network-role}/int\_{network-role} combination.
+
+An ONAP Heat Orchestration Template allows the assignment of one IPv6
+address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
+and {network-role}/int\_{network-role} combination.
+
+Note that 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. ONAP does not
-support Neutron-style Floating IPs.
+of public IPs to VMs is via OpenStack commands. ONAP does not support
+Neutron-style Floating IPs.
+
+External Networks
+_________________
-Both IPv4 and IPv6 “allowed\_address\_pairs” addresses are supported.
+R-61282 The VNF Heat Orchestration Template **MUST**
+adhere to the following naming convention for the property
+allowed\_address\_pairs and Map Property ip\_address parameter,
+when the parameter is referencing an “external” network:
-If property “allowed\_address\_pairs” is used with an external network,
-the parameter name must adhere to the following convention:
+- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
-- *Format for IPv4 addresses: {vm-type}\_{network-role}\_floating\_ip*
+- {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
-- *Format for IPv6 addresses:
- {vm-type}\_{network-role}\_floating\_v6\_ip*
+The parameter must be declared as type: string
-*Example:*
+The parameter must not be enumerated in the Heat environment file.
-.. code-block:: python
+*Example Parameter Definition*
+
+.. code-block:: yaml
- parameters:
- {vm-type}\_{network-role}\_floating\_ip:
- type: string
- description: VIP for {vm-type} VMs on the {network-role} network
- {vm-type}\_{network-role}\_floating\_v6\_ip:
- type: string
- description: VIP for {vm-type} VMs on the {network-role} network
+ 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.
+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
+.. code-block:: yaml
- parameters:
- db\_oam\_ips:
- type: comma\_delimited\_list
- description: Fixed IPs for db VMs on the oam network
- db\_oam\_floating\_ip:
- type: string
- description: Floating IP for db VMs on the oam network
- resources:
- db\_0\_port\_0:
- type: OS::Neutron::Port
- network: { get\_param: oam\_net\_id }
- fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,0] }}]
- allowed\_address\_pairs: [
- { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}]
- db\_1\_port\_0:
- type: OS::Neutron::Port
- network: { get\_param: oam\_net\_id }
- fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,1] }}]
- allowed\_address\_pairs: [
- { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}]
-
-If property “allowed\_address\_pairs” is used with an internal network,
-the parameter name should adhere to the following convention:
-
-- *Format for IPv4 addresses:
- {vm-type}\_int\_{network-role}\_floating\_ip*
-
-- *Format for IPv6 addresses:
- {vm-type}\_int\_{network-role}\_floating\_v6\_ip*
-
-Using the parameter *{vm-type}\_{network-role}\_floating\_ip* or
-*{vm-type}\_{network-role}\_floating\_v6\_ip* provides only one floating
-IP per Vm-type{vm-type} and {network-role} pair. If there is a need for
-multiple floating IPs (e.g., Virtual IPs (VIPs)) for a given {vm-type}
-and {network-role} combination within a VNF, then the parameter names
-defined for the “fixed\_ips” should be used with the
-“allowed\_address\_pairs” property. The examples below illustrate this.
-
-Below example reflects two load balancer pairs in a single VNF. Each
-pair has one VIP.
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
-*Example: A VNF has four load balancers. Each pair has a unique VIP.*
+ db_oam_ips:
+ type: comma_delimited_list
+ description: Fixed IPs for db VMs on the oam network
-*Pair 1:* lb\_0 and lb\_1 share a unique VIP
+ db_oam_floating_ip:
+ type: string
+ description: VIP IP for db VMs on the oam network
-*Pair 2:* lb\_2 and lb\_3 share a unique VIP
+ resources:
+ db_0_port_0:
+ type: OS::Neutron::Port
+ properties:
+ 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}}]
-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.
+ db_1_port_0:
+ type: OS::Neutron::Port
+ properties:
+ 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}}]
-.. code-block:: python
+Internal Networks
+_________________
+
+R-16805 The VNF Heat Orchestration Template **MUST** adhere to the
+following naming convention for the property allowed\_address\_pairs
+and Map Property ip\_address parameter when the parameter is
+referencing an “internal” network.
+
+- {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
+
+- {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
+
+The parameter must be declared as type: string
+
+The parameter must be enumerated in the Heat environment file.
- 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 Parameter Definition*
+
+.. code-block:: yaml
+
+ parameters:
+
+ {vm-type}_int_{network-role}_floating_ip:
+ type: string
+ description: VIP for {vm-type} VMs on the int_{network-role} network
+
+ {vm-type}_int_{network-role}_floating_v6_ip:
+ type: string
+ description: VIP for {vm-type} VMs on the int_{network-role} network
+
+Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
+______________________________________________________________________________
+
+The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
+allowed address pair IPv4 address per {vm-type} and {network-role} pair.
+
+The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
+one allowed address pair IPv6 address per {vm-type} and {network-role}
+pair.
+
+If there is a need for multiple allowed address pair IPs for a given
+{vm-type} and {network-role} combination within a VNF, then the
+parameter names defined for the property fixed\_ips and Map Property
+ip\_address should be used with the allowed\_address\_pairs property.
+The examples below illustrate this.
+
+*Example: A VNF has four load balancers. Each pair has a unique VIP.*
+
+In this example, there are two administrative VM pairs. Each pair has
+one VIP. The {network-role} has been defined as oam to represent an oam
+network and the {vm-type} has been defined as admin for an
+administrative VM.
+
+Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
+VIP, [admin\_oam\_ips,2]
+
+Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
+VIP, [admin\_oam\_ips,5]
+
+.. code-block:: yaml
+
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
+ admin_oam_ips:
+ type: comma_delimited_list
+ description: Fixed IP assignments for admin VMs on the oam network
+
+ resources:
+
+ admin_0_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
+ allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
+
+ admin_1_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
+ allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
+
+ admin_2_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
+ allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
+
+ admin_3_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
+ allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
*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.
+In this example, there is one load balancer pairs. The pair has two
+VIPs. The {network-role} has been defined as oam to represent an oam
+network and the {vm-type} has been defined as lb for a load balancer VM.
-.. code-block:: python
+.. code-block:: yaml
- resources:
- lb\_0\_port\_0:
- type: OS::Neutron::Port
- network: { get\_param: oam\_net\_id }
- fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,0] }}]
- allowed\_address\_pairs: [{ "ip\_address": {get\_param: [lb\_oam\_ips,2] }, {get\_param: [lb\_oam\_ips,3] }}]
+ resources:
+ lb_0_port_0:
+ type: OS::Neutron::Port
+ properties:
+ 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] }}]
+ lb_1_port_0:
+ type: OS::Neutron::Port
+ properties:
+ 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
------------------------
+ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
+__________________________________________________________________
+
+The following items must be taken into consideration when designing Heat
+Orchestration Templates that expect ONAP’s SDN-C to assign
+allowed\_address\_pair IP addresses via automation.
+
+The VMs must be of the same {vm-type}.
+
+The VMs must be created in the same module (base or incremental).
+
+Resource Property “name”
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The parameter naming convention of the property name for the resource
+OS::Nova::Server has been defined in
+`Resource: OS::Nova::Server – Metadata Parameters`_.
-The parameter naming standard for the resource OS::Nova::Server has been
-defined in Section 5.b Resource: OS::Nova::Server – Parameters. This section describes how the name property
-of all other resources must be defined.
+This section provides the requirements how the property name for non
+OS::Nova::Server resources must be defined when the property is used.
+Not all resources require the property name (e.g., it is optional) and
+some resources do not support the property.
-Heat templates must use the Heat “str\_replace” function in conjunction
-with the ONAP 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.
+R-85734 The VNF Heat Orchestration Template **MUST** use the
+intrinsic function str\_replace in conjunction with the ONAP
+supplied metadata parameter vnf\_name to generate a unique
+value, when the property name for a non OS::Nova::Server
+resources is defined in a Heat Orchestration Template.
+
+This prevents the enumeration of a
+unique value for the property name 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
+- In most cases, only the use of the metadata value vnf\_name is
+ required to create a unique property 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
+- the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
+ may also be used in the str\_replace construct to generate a unique
+ name when the vnf\_name does not provide uniqueness
-.. code-block:: python
+*Example: Property* name *for resource* OS::Neutron::SecurityGroup
- 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' }
+.. code-block:: yaml
- 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 }
+ resources:
+ DNS_SECURITY_GROUP:
+ type: OS::Neutron::SecurityGroup
+ properties:
+ description: vDNS security group
+ name:
+ str_replace:
+ template: VNF_NAME_sec_grp_DNS
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ rules: [. . . . .
+ ]
-Output Parameters
------------------
+*Example: Property name for resource* OS::Cinder::Volume
-ONAP defines three type of Output Parameters.
+.. code-block:: yaml
-Base Template Output Parameters:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ resources:
+ DNS_Cinder_Volume:
+ type: OS::Cinder::Volume
+ properties:
+ description: Cinder Volume
+ name:
+ str_replace:
+ template: VNF_NAME_STACK_NAME_dns_volume
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ STACK_NAME: { get_param: 'OS::stack_name' }
+ . . . .
+
+Contrail Issue with Values for the Property Name
+++++++++++++++++++++++++++++++++++++++++++++++++
+
+The Contrail GUI has a limitation displaying special characters. The
+issue is documented in
+https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
+recommended that special characters be avoided. However, if special
+characters must be used, note that for the following resources:
+
+- Virtual Machine
+
+- Virtual Network
+
+- Port
+
+- Security Group
+
+- Policies
+
+- IPAM Creation
+
+the only special characters supported are:
-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:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ONAP Output Parameter Names
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP defines three types of Output Parameters as detailed in
+`Output Parameters`_.
+
+ONAP Base Module Output Parameters:
++++++++++++++++++++++++++++++++++++
+
+ONAP Base Module Output Parameters do not have an explicit naming
+convention. The parameter name must contain {vm-type} and {network-role}
+when appropriate.
-The volume template output parameters are only available only for the
-module (base or add on) that the volume is associated with.
+ONAP Volume Template Output Parameters:
++++++++++++++++++++++++++++++++++++++++
+
+ONAP Base Module Output Parameters do not have an explicit naming
+convention. The parameter name must contain {vm-type} when appropriate.
Predefined Output Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++
-ONAP currently defines one predefined output parameter.
+ONAP currently defines one predefined output parameter the OAM
+Management IP Addresses.
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
+A VNF may 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 ONAP. 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.
+of this interface must be captured and inventoried by ONAP. The IP
+address 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\_v4\_address
-- *oam\_management\_v6\_address*
+- oam\_management\_v6\_address
*Notes*:
+- The use of this output parameters are optional.
+
- The Management IP Address should be defined only once per VNF, so it
- would only appear in one Module template
+ must 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
+ may be echoed in the output parameters. In this case, a IPv4 and/or
+ IPv6 parameter must be defined in the parameter section of the YAML
+ Heat template. The parameter maybe named oam\_management\_v4\_address
+ and/or oam\_management\_v6\_address or may be named differently.
- If the IP for the admin VM is obtained via DHCP, it may be obtained
- from the resource attributes
+ from the resource attributes. In this case,
+ oam\_management\_v4\_address and/or oam\_management\_v6\_address must
+ not be defined in the parameter section of the YAML Heat template.
+
+*Example: SDN-C Assigned IP Address echoed as*
+oam\_management\_v4\_address
+
+.. code-block:: yaml
+
+ parameters:
+ admin_oam_ip_0:
+ type: string
+ description: Fixed IPv4 assignment for admin VM 0 on the OAM network
+ . . .
+
+ resources:
+ admin_oam_net_0_port:
+ type: OS::Neutron::Port
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_admin_oam_net_0_port
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ network: { get_param: oam_net_id }
+ fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
+ security_groups: [{ get_param: security_group }]
+
+ admin_server:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: admin_names }
+ image: { get_param: admin_image_name }
+ flavor: { get_param: admin_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+ networks:
+ - port: { get_resource: admin_oam_net_0_port }
+ metadata:
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: { get_param: vf_module_id }
+ vnf_name: {get_param: vnf_name }
+ Outputs:
+ oam_management_v4_address:
+ value: {get_param: admin_oam_ip_0 }
+
+*Example: Cloud Assigned IP Address output as*
+oam\_management\_v4\_address
+
+.. code-block:: yaml
+
+ parameters:
+ . . .
+ resources:
+ admin_oam_net_0_port:
+ type: OS::Neutron::Port
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_admin_oam_net_0_port
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ network: { get_param: oam_net_id }
+ security_groups: [{ get_param: security_group }]
+
+ admin_server:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: admin_names }
+ image: { get_param: admin_image_name }
+ flavor: { get_param: admin_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+ networks:
+ - port: { get_resource: admin_oam_net_0_port }
+ metadata:
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: { get_param: vf_module_id }
+ vnf_name: {get_param: vnf_name }
+
+ Outputs:
+ oam_management_v4_address:
+ value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
+
+Contrail Resource Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP requires the parameter names of certain Contrail Resources to
+follow specific naming conventions. This section provides these
+requirements.
+
+Contrail Network Parameters
++++++++++++++++++++++++++++
+
+Contrail based resources may require references to a Contrail network
+using the network FQDN.
+
+External Networks
+_________________
+
+When the parameter associated with the Contrail Network is referencing
+an “external” network, the parameter must adhere to the following naming
+convention in the Heat Orchestration Template
+
+- {network-role}\_net\_fqdn
+
+The parameter must be declared as type: string
+
+The parameter must not be enumerated in the Heat environment file.
+
+*Example: Parameter declaration*
+
+.. code-block:: yaml
+
+ parameters:
+ {network-role}_net_fqdn:
+ type: string
+ description: Contrail FQDN for the {network-role} network
+
+*Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
+Reference to a Network FQDN.*
+
+In this example, the {network-role} has been defined as oam to represent
+an oam network and the {vm-type} has been defined as fw for firewall.
+The Contrail resource OS::ContrailV2::VirtualMachineInterface property
+virtual\_network\_refs references a contrail network FQDN.
+
+.. code-block:: yaml
+
+ FW_OAM_VMI:
+ type: OS::ContrailV2::VirtualMachineInterface
+ properties:
+ name:
+ str_replace:
+ template: VM_NAME_virtual_machine_interface_1
+ params:
+ VM_NAME: { get_param: fw_name_0 }
+ virtual_machine_interface_properties:
+ virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
+ virtual_network_refs:
+ - get_param: oam_net_fqdn
+ security_group_refs:
+ - get_param: fw_sec_grp_id
+
+Interface Route Table Prefixes for Contrail InterfaceRoute Table
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+The parameter associated with the resource
+OS::ContrailV2::InterfaceRouteTable property
+interface\_route\_table\_routes, map property
+interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
+Parameter.
+
+The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
+in the Heat Orchestration Template.
+
+The parameter must be declared as type: json
+
+The parameter supports IP addresses in the format:
+
+1. Host IP Address (e.g., 10.10.10.10)
+
+2. CIDR Notation format (e.g., 10.0.0.0/28)
+
+The parameter must not be enumerated in the Heat environment file.
+
+*Example Parameter Definition*
+
+.. code-block:: yaml
+
+ parameters:
+ {vm-type}_{network-role}_route_prefixes:
+ type: json
+ description: JSON list of Contrail Interface Route Table route prefixes
*Example:*
-.. code-block:: python
+.. code-block:: yaml
+
+ parameters:
+ vnf_name:
+ type: string
+ description: Unique name for this VF instance
+ fw_int_fw_route_prefixes:
+ type: json
+ description: prefix for the ServiceInstance InterfaceRouteTable
+ int_fw_dns_trusted_interface_type:
+ type: string
+ description: service_interface_type for ServiceInstance
+
+ <resource name>:
+ type: OS::ContrailV2::InterfaceRouteTable
+ depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_interface_route_table
+ params:
+ VNF_NAME: { get_param: vnf_name }
+ interface_route_table_routes:
+ interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
+ service_instance_refs:
+ - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
+ service_instance_refs_data:
+ - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
+
+Parameter Names in Contrail Resources
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Contrail Heat resource properties will use, when appropriate, the same
+naming convention as OpenStack Heat resources. For example, the resource
+OS::ContrailV2::InstanceIp has two properties that the parameter naming
+convention is identical to properties in OS::Neutron::Port.
+
+*Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
+instance\_ip\_address*
+
+The property instance\_ip\_address uses the same parameter naming
+convention as the property fixed\_ips and Map Property ip\_address in
+OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
+Address. The {network-role} has been defined as oam\_protected to
+represent an oam protected network and the {vm-type} has been defined as
+fw for firewall.
+
+.. code-block:: yaml
+
+ CMD_FW_OAM_PROTECTED_RII:
+ type: OS::ContrailV2::InstanceIp
+ depends_on:
+ - FW_OAM_PROTECTED_RVMI
+ properties:
+ virtual_machine_interface_refs:
+ - get_resource: FW_OAM_PROTECTED_RVMI
+ virtual_network_refs:
+ - get_param: oam_protected_net_fqdn
+ instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
+
+*Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
+subnet\_uuid*
+
+The property instance\_ip\_address uses the same parameter naming
+convention as the property fixed\_ips and Map Property subnet\_id in
+OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
+Address. The {network-role} has been defined as “oam\_protected” to
+represent an oam protected network and the {vm-type} has been defined as
+“fw” for firewall.
+
+.. code-block:: yaml
+
+ CMD_FW_SGI_PROTECTED_RII:
+ type: OS::ContrailV2::InstanceIp
+ depends_on:
+ - FW_OAM_PROTECTED_RVMI
+ properties:
+ virtual_machine_interface_refs:
+ - get_resource: FW_OAM_PROTECTED_RVMI
+ virtual_network_refs:
+ - get_param: oam_protected_net_fqdn
+ subnet_uuid: { get_param: oam_protected_subnet_id }
+
+Cinder Volume Templates
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+ONAP supports the independent deployment of a Cinder volume via separate
+Heat Orchestration Templates, the Cinder Volume module. 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 Base Module or Incremental Module may have a corresponding volume
+module. Use of separate volume modules is optional. A Cinder volume may
+be embedded within the Base Module or Incremental Module if persistence
+is not required.
- resources:
- admin\_server:
- type: OS::Nova::Server
- properties:
- networks:
- - network: {get\_param: oam\_net\_id }
- ...
+R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
+scope of a cinder volume module, when it exists, with the
+Base Module or Incremental Module
- Outputs:
- oam\_management\_v4\_address:
- value: {get\_attr: [admin\_server, networks, {get\_param: oam\_net\_id}, 0] }
+A single volume module must create only the volumes
+required by a single Incremental module or Base module.
-Heat Template Constructs
-------------------------
+The following rules apply to independent volume Heat templates:
-External References
--------------------
+- Cinder volumes must be created in a separate Heat Orchestration
+ Template from the Base Module or Incremental Module.
-Heat templates *should not* reference any HTTP-based resource
-definitions, any HTTP-based nested configurations, or any HTTP-based
-environment files.
+- A single Cinder volume module must include all Cinder volumes
+ needed by the Base/Incremental module.
-- During orchestration, ONAP *should not* retrieve any such
- resources from external/untrusted/unknown sources.
+- R-79531 The VNF Heat Orchestration Template **MUST** define
+ “outputs” in the volume template for each Cinder volume
+ resource universally unique identifier (UUID) (i.e. ONAP
+ Volume Template Output Parameters).
-- 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.
+- The VNF Incremental Module or Base Module must define input
+ parameters that match each Volume output parameter (i.e., ONAP Volume
+ Template Output Parameters).
-*Note:* HTTP-based references are acceptable if the HTTP-based reference
-is accessing information with the VM private/internal network.
+ - ONAP will supply the volume template outputs automatically to the
+ bases/incremental template input parameters.
-Heat Files Support (get\_file)
-------------------------------
+- Volume modules may utilize nested Heat templates.
-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.
+*Examples: Volume Template*
-Support for Heat Files is subject to the following limitations:
+A VNF has a Cinder volume module, named incremental\_volume.yaml, that
+creates an independent Cinder volume for a VM in the module
+incremental.yaml. The incremental\_volume.yaml defines a parameter in
+the output section, lb\_volume\_id\_0 which is the UUID of the cinder
+volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
+ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
+output statement and provides the value to the incremental module.
-- The ‘get\_files’ targets must be referenced in Heat templates by file
- name, and the corresponding files should be delivered to ONAP
- along with the Heat templates.
+Note that the example below is not a complete Heat Orchestration
+Template. The {vm-type} has been defined as “lb” for load balancer
- - URL-based file retrieval must not be used; it is not supported.
+incremental\_volume.yaml
-- The included files must have unique file names within the scope of
- the VNF.
+.. code-block:: yaml
-- ONAP does not support a directory hierarchy for included files.
+ parameters:
+ vnf_name:
+ type: string
+ lb_volume_size_0:
+ type: number
+ ...
- - All files must be in a single, flat directory per VNF.
+ resources:
+ dns_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: dns_volume_size_0}
+ ...
-- Included files may be used by all Modules within a given VNF.
+ outputs:
+ lb_volume_id_0:
+ value: {get_resource: dns_volume_0}
+ ...
-- get\_file directives may be used in both non-nested and nested
- templates
+
+incremental.yaml
+
+.. code-block:: yaml
+
+ parameters:
+ lb_name_0:
+ type: string
+ lb_volume_id_0:
+ type: string
+ ...
+
+ resources:
+ lb_0:
+ type: OS::Nova::Server
+ properties:
+ name: {get_param: dns_name_0}
+ networks:
+ ...
+
+ lb_0_volume_attach:
+ type: OS::Cinder::VolumeAttachment
+ properties:
+ instance_uuid: { get_resource: lb_0 }
+ volume_id: { get_param: lb_volume_id_0 }
+
+ONAP Support of Environment Files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The use of an environment file in OpenStack is optional. In ONAP, it is
+mandatory.
+
+R-86285 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file, even if no parameters are required to be
+enumerated.
+
+(Note that ONAP, the open source version of ONAP, does not
+programmatically enforce the use of an environment file.)
+
+R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file for a Base Module.
+
+R-35727 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file for an Incremental module.
+
+R-22656 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file for a Cinder Volume Module.
+
+A nested heat template must not have an environment file; OpenStack does
+not support it.
+
+The environment file must contain parameter values for the ONAP
+Orchestration Constants and VNF Orchestration Constants. These
+parameters are identical across all instances of a VNF type, and
+expected to change infrequently. The ONAP Orchestration Constants are
+associated with OS::Nova::Server image and flavor properties (See
+`Property: image`_ and `Property: flavor`_). 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 (ONAP Orchestration Parameters, VNF
+Orchestration Parameters). These parameters are supplied to the Heat by
+ONAP at orchestration time.
+
+SDC Treatment of Environment Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Parameter values enumerated in the environment file are used by SDC as
+the default value. However, the SDC user may use the SDC GUI to
+overwrite the default values in the environment file.
+
+SDC generates a new environment file for distribution to MSO based on
+the uploaded environment file and the user provided GUI updates. The
+user uploaded environment file is discarded when the new file is
+created. Note that if the user did not change any values via GUI
+updates, the SDC generated environment file will contain the same values
+as the uploaded file.
+
+Use of Environment Files when using OpenStack “heat stack-create” CLI
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When ONAP is instantiating the Heat Orchestration Template, certain
+parameter must not be enumerated in the environment file. This document
+provides the details of what parameters should not be enumerated.
+
+If the Heat Orchestration Template is to be instantiated from the
+OpenStack Command Line Interface (CLI) using the command “heat
+stack-create”, all parameters must be enumerated in the environment
+file.
+
+Heat Template Constructs
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Nested Heat Templates
+~~~~~~~~~~~~~~~~~~~~~
+
+ONAP 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 VNF module may then reference these component templates
+either statically by repeated definition or dynamically by using the
+resource OS::Heat::ResourceGroup.
+
+Nested Heat Template Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP supports nested Heat Orchestration Templates. A Base Module,
+Incremental Module, and Cinder Volume Module may use nested heat.
+
+A Heat Orchestration Template may reference the nested heat statically
+by repeated definition.
+
+A Heat Orchestration Template may reference the nested heat dynamically
+using the resource OS::Heat::ResourceGroup.
+
+A Heat Orchestration template must have no more than three levels of
+nesting. ONAP supports a maximum of three levels.
+
+Nested heat templates must be referenced by file name. The use of
+resource\_registry in the environment file is not supported and must not
+be used.
+
+R-89868 The VNF Heat Orchestration Template **MUST** have unique
+file names within the scope of the VNF for a nested heat yaml file.
+
+R-52530 The VNF Heat Orchestration Template **MUST NOT** use a
+directory hierarchy for nested templates. All templates must
+be in a single, flat directory (per VNF).
+
+A nested heat template may be used by any module within a given VNF.
+
+Note that:
+
+- Constrains must not be defined for any parameter enumerated in a
+ nested heat template.
+
+- R-11041 The VNF Heat Orchestration Template **MUST** have the
+ resource calling the nested yaml file pass in as properties
+ all parameters defined in nested yaml file.
+
+- R-61183 The VNF Heat Orchestration Template **MUST NOT**
+ change the parameter names, when OS::Nova::Server metadata
+ parameters are past into a nested heat template.
+
+- With nested templates, outputs are required to expose any resource
+ properties of the child templates to the parent template. Those would
+ not explicitly be declared as parameters but simply referenced as
+ get\_attribute targets against the “parent” resource.
+
+Nested Heat Template Example: Static
+++++++++++++++++++++++++++++++++++++++
+
+incremental.yaml
+
+.. code-block:: yaml
+
+ Resources:
+ dns_server_0:
+ type: nested.yaml
+ properties:
+ dns_image_name: { get_param: dns_image_name }
+ dns_flavor_name: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+ security_group: { get_param: DNS_shared_sec_grp_id }
+ oam_net_id: { get_param: oam_protected_net_id }
+ dns_oam_ip: { get_param: dns_oam_ip_0 }
+ dns_name: { get_param: dns_name_0 }
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: {get_param: vf_module_id}
+
+ dns_server_1:
+ type: nested.yaml
+ properties:
+ dns_image_name: { get_param: dns_image_name }
+ dns_flavor_name: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
+ security_group: { get_param: DNS_shared_sec_grp_id }
+ oam_net_id: { get_param: oam_protected_net_id }
+ dns_oam_ip: { get_param: dns_oam_ip_1 }
+ dns_name: { get_param: dns_name_1 }
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: {get_param: vf_module_id}
+
+nested.yaml
+
+.. code-block:: yaml
+
+ dns_oam_0_port:
+ type: OS::Neutron::Port
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_dns_oam_port
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ network: { get_param: oam_net_id }
+ fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
+ security_groups: [{ get_param: security_group }]
+
+ dns_servers:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: dns_names }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone }
+ networks:
+ - port: { get_resource: dns_oam_0_port }
+ metadata:
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: { get_param: vf_module_id }
+ vnf_name {get_param: vnf_name }
Use of Heat ResourceGroup
--------------------------
++++++++++++++++++++++++++
-The *OS::Heat::ResourceGroup* is a useful Heat element for creating
+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
+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 ONAP 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 may be used in ONAP 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
+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*
+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*:
+For instance, the following is **not** valid Heat for ResourceGroup:
-.. code-block:: python
+.. code-block:: yaml
- type: OS::Heat::ResourceGroup
- resource:
- type: my\_nested\_vm\_template.yaml
- properties:
- name: {get\_param: [vm\_name\_list, %index%]}
+ type: OS::Heat::ResourceGroup
+ resource_def:
+ 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
+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.
+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*:
+ResourceGroup:
-.. code-block:: python
+.. code-block:: yaml
- type: OS::Heat::ResourceGroup
- resource:
- type: my\_nested\_vm\_template.yaml
- properties:
- names: {get\_param: vm\_name\_list}
- index: %index%
+ type: OS::Heat::ResourceGroup
+ resource_def:
+ 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.
+ResourceGroup Property count
+____________________________
+
+ONAP requires that the OS::Heat::ResourceGroup property count be defined
+(even if the value is one) and that the value must be enumerated in the
+environment file. This is required for ONAP to build the TOSCA model for
+the VNF.
+
+.. code-block:: yaml
+
+ type: OS::Heat::ResourceGroup
+ properties:
+ count: { get_param: count }
+ index_var: index
+ resource_def:
+ type: my_nested_vm_template.yaml
+ properties:
+ names: {get_param: vm_name_list}
+ index: index
+
+Availability Zone and ResourceGroups
+____________________________________
+
+The resource OS::Heat::ResourceGroup and the property availability\_zone
+has been an “issue” with a few VNFs since ONAP only supports
+availability\_zone as a string parameter and not a
+comma\_delimited\_list. This makes it difficult to use a ResourceGroup
+to create Virtual Machines in more than one availability zone.
+
+There are numerous solutions to this issue. Below are two suggested
+usage patterns.
+
+**Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
+resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
+availability\_zones by using the intrinsic function list\_join.
+
+.. code-block:: yaml
+
+ <resource name>:
+ type: OS::Heat::ResourceGroup
+ properties:
+ count: { get_param: node_count }
+ index_var: index
+ resource_def:
+ type: nested.yaml
+ properties:
+ index: index
+ avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
+
+In the nested heat
+
+.. code-block:: yaml
+
+ parameters:
+ avaialability_zones:
+ type: comma_delimited_list
+ description:
+
+ resources:
+ servers:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, get_param: index ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
+
+
+**Option 2:** Create a resource group per availability zone. A separate
+OS::Heat::ResourceGroup is created for each availability zone.
+
+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, ONAP *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:
+
+R-76718 The VNF Heat Orchestration Template **MUST** reference
+the get\_files targets in Heat templates by file name, and the
+corresponding files should be delivered to ONAP along with the
+Heat templates.
+
+R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
+
+R-62177 The VNF Heat Orchestration Template **MUST** have unique
+file names for the included files within the scope of the VNF.
+
+R-87848 The VNF Heat Orchestration Template **MUST** have all
+included files in a single, flat directory per VNF. ONAP does
+not support a directory hierarchy.
+
+- 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
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
- 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
+- Create a new keypair within The VNF Heat Orchestration Template (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
-ONAP). It also removes any access/ownership issues over the created
-keypair.
+generate a public/private pair to be saved and tracked outside of ONAP).
+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. ONAP will never
+at run-time as instance-specific parameters. ONAP 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
+.. code-block:: yaml
+
+ parameters:
+ vnf_name:
+ type: string
+ lb_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}).
+Orchestration 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
+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}
-
-
-d. VNFM Driver Develop Steps
-==============================
-
-Aid to help the VNF vendor to fasten the integration with the NFVO via
-Special VNFM, the OpenO provides the documents. In this charter, the
-develop steps for VNF vendors will be introduced.
-
-First, using the VNF SDK tools to design the VNF with TOSCA model and
-output the VNF TOSCA package. The VNF package can be validated, and
-tested.
-
-Second, the VNF vendor should provide SVNFM Driver in the OpenO, which
-is a micro service and in duty of translation interface from NFVO to
-SVNFM. The interface of NFVO is aligned to the ETSI IFA interfaces and
-can be gotten in the charter 5.5. The interface of SVNFM is provided by
-the VNF vendor self.
-
-e. Create SVNFM Adaptor Mircoservice
-=======================================
-
-Some vnfs are managed by special vnfm, before add svnfm to openo, a
-svnfm adaptor must be added to openo to adapter the interface of nfvo
-and svnfm.
-
-A svnfm adaptor is a micro service with unique name and an appointed
-port, when started up, it must be auto registered to MSB(Micro server
-bus),following describes an example rest of register to MSB:
-
-POST /openoapi/microservices/v1/services
+In this example, the {network-role} has been defined as oam to represent
+an oam network and the {vm-type} have been defined as lb for load
+balancer and db for database.
+
+.. code-block:: yaml
+
+ resources:
+ db_server_group:
+ type: OS::Nova::ServerGroup
+ properties:
+ name:
+ str_replace:
+ params:
+ $vnf_name: {get_param: vnf_name}
+ template: $vnf_name-server_group1
+ policies:
+ - anti-affinity
+
+ lb_server_group:
+ type: OS::Nova::ServerGroup
+ properties:
+ name:
+ str_replace:
+ params:
+ $vnf_name: {get_param: vnf_name}
+ template: $vnf_name-server_group2
+ policies:
+ - affinity
+
+ db_0:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: db_server_group}
+
+ db_1:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: db_server_group}
+
+ lb_0:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: lb_server_group}
+
+Resource Data Synchronization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For cases where synchronization is required in the orchestration of Heat
+resources, two approaches are recommended:
+
+- Standard Heat depends\_on property for resources
+
+ - Assures that one resource completes before the dependent resource
+ is orchestrated.
+
+ - Definition of completeness to OpenStack may not be sufficient
+ (e.g., a VM is considered complete by OpenStack when it is ready
+ to be booted, not when the application is up and running).
+
+- Use of Heat Notifications
+
+ - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
+ resources.
+
+ - Pre-requisite resources issue *wc\_notify* commands in user\_data.
+
+ - Dependent resource define depends\_on in the
+ OS::Heat::WaitCondition resource.
+
+*Example: “depends\_on” case*
+
+In this example, the {network-role} has been defined as oam to represent
+an oam network and the {vm-type} has been defined as oam to represent an
+oam server.
+
+.. code-block:: yaml
+
+ resources:
+ 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}
+
+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
+
+Post Orchestration & VNF Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- {
+Heat templates should contain a minimum amount of post-orchestration
+configuration data. For instance, *do not* embed complex user-data
+scripts in the template with large numbers of configuration parameters
+to the Heat template.
- "serviceName": "catalog",
+- VNFs may provide configuration APIs for use after VNF creation. Such
+ APIs will be invoked via application and/or SDN controllers.
- "version": "v1",
+*Note:* It is important to follow this convention to the extent possible
+even in the short-term as of the long-term direction.
- "url": "/openoapi/catalog/v1",
+VNFM Driver Development Steps
+-----------------------------------------------------------
- "protocol": "REST",
+Refer to the ONAP documentation for VNF Provider instructions on integrating
+vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
+highlighted below.
- "visualRange": "1",
+1. Use the VNF SDK tools to design the VNF with TOSCA models to output
+the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
+validated and tested.
- "nodes": [
+2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
+is a microservice providing a translation interface from VF-C to
+the vendor-specific VNFM. The interface definitions of vendor-specific
+VNFM adaptors are supplied by the VNF Providers themselves.
- {
+Creating Vendor-Specific VNFM Adaptor Microservices
+------------------------------------------------------------------------------------------------
- "ip": "10.74.56.36",
+VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific
+VNFM to ONAP, a vendor-specific VNFM adaptor is added to ONAP implementing
+the interface of the vendor-specific VNFM.
- "port": "8988",
+A vendor-specific VNFM adaptor is a microservice with a unique name and
+an appointed port. When started up, the vendor-specific VNFM adaptor
+microservice is automatically registered to the Microservices Bus (MSB).
+The following RESTful example describes the scenario of registering a
+vendor-specific VNFM adaptor to MSB:
- "ttl": 0
+.. code-block:: java
+ POST /api/microservices/v1/services
+ {
+ "serviceName": "catalog",
+ "version": "v1",
+ "url": "/api/catalog/v1",
+ "protocol": "REST",
+ "visualRange": "1",
+ "nodes": [
+ {
+ "ip": "10.74.56.36",
+ "port": "8988",
+ "ttl": 0
+ }
+ ]
}
-
- ]
-
- }
\ No newline at end of file
Code Review / vnfrqts / requirements.git / blobdiff