-:tocdepth: 2
+.. 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.
-**5. VNF Modeling Requirements**
-=====================================
-a. TOSCA YAML
-=============
+VNF Modeling Requirements
+=========================
+
+TOSCA YAML
+----------
Introduction
--------------
+^^^^^^^^^^^^^^
This reference document is the VNF TOSCA Template Requirements for
ONAP, which provides recommendations and standards for building VNF
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 ONAP.
Scope
------
+^^^^^^^^^^^^^^^^
ONAP implementations of Network Cloud supports TOSCA Templates, also
referred to as TOSCA in this document.
associated with this format.
Overview
----------
+^^^^^^^^^^^^^^^^
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
self-defined node or other extensions.
NFV TOSCA Template
-------------------
+^^^^^^^^^^^^^^^^^^^^
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
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
-^^^^^^^^^^^^
+++++++++++
-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
-^^^^^^^^^^
+Note: currently not supported.
-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.
YAML Format
------------
+~~~~~~~~~~~
-Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
+R-95303 A VNF's Heat Orchestration Template **MUST** be defined
+using valid YAML.
+
+YAML (YAML Ain't
Markup Language) is a human friendly data serialization standard for all
programming languages. See http://www.yaml.org/.
Heat Orchestration Template Format
-----------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Heat Orchestration templates must be defined in YAML.
+As stated above, Heat Orchestration templates must be defined in YAML.
YAML rules include:
-- Tabs are NOT allowed, use spaces ONLY.
+ - Tabs are not allowed, use spaces ONLY
-- You MUST indent your properties and lists with 1 or more spaces.
+ - You must indent your properties and lists with 1 or more spaces
-- All Resource IDs and resource property parameters are case-sensitive.
- (e.g., "ThIs", is not the same as "thiS")
+ - All Resource IDs and resource property parameters are
+ case-sensitive. (e.g., "ThIs", is not the same as "thiS")
Heat Orchestration Template Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Heat Orchestration template structure follows the following format, as
-defined by OpenStack at
-https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
+Heat Orchestration template structure follows the following format,
+as defined by OpenStack at
+https://docs.openstack.org/developer/heat/template_guide/hot_spec.html
-.. code-block:: yaml
+.. code-block:: python
- heat_template_version: <date>
+ heat_template_version: <date>
- description:
- # a description of the template
+ description:
+ # a description of the template
- parameter_groups:
- # a declaration of input parameter groups and order
+ parameter_groups:
+ # a declaration of input parameter groups and order
- parameters:
- # declaration of input parameters
+ parameters:
+ # declaration of input parameters
- resources:
- # declaration of template resources
+ resources:
+ # declaration of template resources
- outputs:
- # declaration of output parameters
+ outputs:
+ # declaration of output parameters
- conditions:
- # declaration of conditions
+ conditions:
+ # declaration of conditions
+heat_template_version
++++++++++++++++++++++
-Heat Orchestration templates for ONAP must contain the following
-sections:
+R-27078 A VNF's Heat Orchestration template **MUST** contain
+the section "heat_template_version:".
-- heat\_template\_version:
+The section "heat_template_version:" must be set to a date
+that is supported by the OpenStack environment.
-- description:
+description
++++++++++++
-- parameters:
+R-39402 A VNF's Heat Orchestration Template **MUST**
+contain the section "description:".
-- resources:
+parameter_groups
+++++++++++++++++
-Heat Orchestration templates for ONAP may contain the following
-sections:
+A VNF Heat Orchestration template may
+contain the section "parameter_groups:".
-- parameter\_groups:
+parameters
+++++++++++
-- outputs:
+R-35414 A VNF Heat Orchestration's template **MUST**
+contain the section "parameters:".
-heat\_template\_version
-^^^^^^^^^^^^^^^^^^^^^^^
-This section is ONAP mandatory. The heat\_template\_version must be set
-to a date that is supported by the OpenStack environment.
+.. code-block:: python
-description
-^^^^^^^^^^^
+ parameters:
-This ONAP mandatory section allows for a description of the template.
+ <param name>:
-parameter\_groups
-^^^^^^^^^^^^^^^^^
+ type: <string | number | json | comma_delimited_list | boolean>
-This ONAP optional section allows for specifying how the input
-parameters should be grouped and the order to provide the parameters in.
+ label: <human-readable name of the parameter>
-parameters
-^^^^^^^^^^
+ description: <description of the parameter>
-The parameter section is ONAP mandatory. This section allows for
-specifying input parameters that have to be provided when instantiating
-the template. Each parameter is specified in a separated nested block
-with the name of the parameters defined in the first line and additional
-attributes (e.g., type, label) defined as nested elements.
+ default: <default value for parameter>
-The Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process
-requires all parameters declared in a template to be used in a resource
-with the exception of the parameters for the OS::Nova::Server property
-availability\_zone. See `Property: availability\_zone`_. for more details on
-availability\_zone.
+ hidden: <true | false>
-.. code-block:: yaml
+ constraints:
- parameters:
- <param name>:
- type: <string | number | json | comma_delimited_list | boolean>
- label: <human-readable name of the parameter>
- description: <description of the parameter>
- default: <default value for parameter>
- hidden: <true | false>
- constraints:
- <parameter constraints>
- immutable: <true | false>
+ <parameter constraints>
+
+ immutable: <true | false>
+
+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.
+
+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.
-- param name:
+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.
- - The name of the parameter.
+<param name>
+____________
- - ONAP requires that the param name must contain only alphanumeric
- characters and “\_” underscores. Special characters must not be
- used.
+The name of the parameter.
-- type:
+R-25877 A VNF's Heat Orchestration Template's parameter
+name (i.e., <param name>) **MUST** contain only
+alphanumeric characters and underscores ('_').
+
+type
+____
+
+R-36772 A VNF’s Heat Orchestration Template’s parameter
+**MUST** include the attribute “type:”.
+
+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".
+
+label
+_____
+
+R-32094 A VNF's Heat Orchestration Template parameter
+declaration **MAY** contain the attribute "label:"
+
+description
+___________
- - The type of the parameter. Supported types are string, number,
- comma\_delimited\_list, json and boolean.
+R-44001 A VNF's Heat Orchestration Template parameter
+declaration **MUST** contain the attribute "description".
- - This attribute must be provided per the OpenStack Heat
- Orchestration Template standard.
+Note that the parameter attribute “description:” is an
+OpenStack optional attribute that provides a description
+of the parameter. ONAP implementation requires this attribute.
-- label:
+default
+_______
- - A human readable name for the parameter.
+R-90526 A VNF Heat Orchestration Template parameter
+declaration **MUST** not contain the default attribute.
- - This attribute is optional.
+R-26124 If a VNF Heat Orchestration Template parameter
+requires a default value, it **MUST** be enumerated in the environment file.
-- description:
+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.
- - A human readable description for the parameter.
+hidden
+______
- - This attribute is ONAP mandatory; it must be provided. (Note that
- this attribute is OpenStack optional.)
+R-32557 A VNF's Heat Orchestration Template parameter
+declaration MAY contain the attribute "hidden:".
-- default:
+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.
- - A default value for the parameter.
+constraints
+___________
- - ONAP does not support this attribute; it *must not* be provided in
- the Heat Orchestration Template. If a parameter has a default
- value, it must be provided in the environment file. (Note that
- this attribute is OpenStack optional.)
+The parameter attribute "constraints:" is an OpenStack optional
+attribute that defines a list of constraints to apply to the parameter.
-- hidden:
+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.
- - 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.
+R-40518 A VNF's Heat Orchestration Template’s parameter defined as
+type "string" **MAY** have a parameter constraint defined.
- - This attribute is optional and defaults to false.
+R-96227 A VNF's Heat Orchestration Template’s parameter defined as
+type "json" **MAY** have a parameter constraint defined.
-- constraints:
+R-79817 A VNF's Heat Orchestration Template’s parameter defined as
+type "comma_delimited_list" **MAY** have a parameter constraint defined.
- - A list of constraints to apply. 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 Heat Orchestration Template are validated against
- the constraints at instantiation time. The constraints are defined
- as a list with the following syntax
+R-06613 A VNF's Heat Orchestration Template’s parameter defined as
+type "boolean" **MAY** have a parameter constraint defined.
- constraints:
+R-00011 A VNF's Heat Orchestration Template's Nested YAML files
+parameter's **MUST NOT** have a parameter constraint defined.
- - <constraint type>: <constraint definition>
+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: Type of constraint to apply.
+..
+
+**<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.
-- constraint definition: The actual constraint, depending on the
- constraint type.
+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
-- description: 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.
- This attribute is optional.
+**range**
-- When the parameter type is set to number, the Heat Orchestration
- Template uploaded into ONAP must have constraints for range or
- allowed\_values.
+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
- - 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: The allowed\_values constraint applies to parameters
- of type string or 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
+It is possible to define a range constraint with only a lower
+limit or an upper limit.
- allowed\_values: [ <value>, <value>, ... ]
+**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:
+ allowed_values:
- <value>
- ...
-- Other <constraint type> are optional, they may be used (e.g., length,
- modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
- string types))
+. .
-- Note that constrains must not be defined for any parameter enumerated
- in a nested heat template.
+immutable
+_________
-- Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
+R-22589 A VNF’s Heat Orchestration Template parameter declaration
+**MAY** contain the attribute "immutable:".
-- 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.
- - Defines whether the parameter is updatable. Stack update fails, if
- this is set to true and the parameter value is changed.
+resources
++++++++++
- - This attribute is optional and defaults to false.
+R-23664 A VNF's Heat Orchestration template **MUST** contain
+the section "resources:".
-resources
-^^^^^^^^^
+R-90152 A VNF's Heat Orchestration Template's "resources:"
+section **MUST** contain the declaration of at least one resource.
-This section is ONAP mandatory; it must be provided. This section
-contains the declaration of the single resources of the template. This
-section with at least one resource must be defined in the Heat
-Orchestration Template, or the template would not create any resources
-when being instantiated.
+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.
+Each resource is defined as a
+separate block in the resources section with the following syntax.
-.. code-block:: yaml
+.. 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>
+ 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.
-- resource ID
+properties
+__________
- - A resource ID that must be unique within the resources section of
- the Heat Orchestration Template.
+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>`__).
- - ONAP requires that the resource ID must be unique across all Heat
- Orchestration Templates that compose the VNF. This requirement
- also applies when a VNF is composed of more than one Heat
- Orchestration Template (see ONAP VNF Modularity Overview).
+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
- - The naming convention for a resource ID is provided in `Resource IDs`_.
+metadata
+________
-- type
+The resource attribute \"metadata:\" is an OpenStack optional attribute.
- - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
- Note that the type may specify a nested heat file. This attribute
- is required.
+R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
+resource **MUST** contain the attribute "metadata".
-- properties
+Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
- - A list of resource-specific properties. The property value can be
- provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
- - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
+depends_on
+__________
-- metadata
+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.
- - Resource-specific metadata. This section is optional, except for
- the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
+R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “depends_on:”.
-- depends\_on
+update_policy
+_____________
- - Dependencies of the resource on one or more resources of the
- template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
+R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “update_policy:”.
-- update\_policy
+deletion_policy
+_______________
- - Update policy for the resource, in the form of a nested
- dictionary. Whether update policies are supported and what the
- exact semantics are depends on the type of the current resource.
- This attribute is optional.
+R-43740 A VNF’s Heat Orchestration Template’s Resource
+**MAY** declare the attribute “deletion_policy:”.
-- 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.
- - Deletion policy for the resource. The allowed deletion policies
- are Delete, Retain, and Snapshot. Beginning with
- heat\_template\_version 2016-10-14, the lowercase equivalents
- delete, retain, and snapshot are also allowed. This attribute is
- optional; the default policy is to delete the physical resource
- when deleting a resource from the stack.
+The default policy is to delete the physical resource when
+deleting a resource from the stack.
-- external\_id
+external_id
+___________
- - 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.
+R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
+declare the attribute “external_id:”.
-- condition
+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 for the resource. The condition decides whether to
- create the resource or not. This attribute is optional.
+
+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 ONAP optional section allows for specifying output parameters
+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.
+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)
-The environment file can contain the following sections:
+R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file, even if no parameters are required to be enumerated.
-- parameters: A list of key/value pairs.
+The use of an environment file in OpenStack is optional.
+In ONAP, it is mandatory.
-- resource\_registry: Definition of custom resources.
+R-03324 The VNF Heat Orchestration Template **MUST** contain the
+"parameters" section in the
+environment file
-- parameter\_defaults: Default parameters passed to all template
- resources.
+R-68198 A VNF’s Heat Orchestration template’s Environment File’s
+“parameters:” section **MAY** enumerate parameters.
-- encrypted\_parameters: List of encrypted parameters.
+ONAP implementation requires the parameters section in the
+environmental file to be declared. The parameters section
+contains a list of key/value pairs.
-- event\_sinks: List of endpoints that would receive stack events.
+R-59930 A VNF’s Heat Orchestration template’s Environment
+File’s **MAY** contain the “parameter_defaults:” section.
-- parameter\_merge\_strategies: Merge strategies for merging parameters
- and parameter defaults from the environment file.
+The “parameter_defaults:” section contains default parameters
+that are passed to all template resources.
-Environment files for ONAP must contain the following sections:
+R-46096 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “encrypted_parameters:” section.
-- parameters:
+The “encrypted_parameters:” section contains a list of encrypted parameters.
-Environment files for ONAP may contain the following sections:
+R-24893 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “event_sinks:” section.
-- resource\_registry:
+The “event_sinks:” section contains the list of endpoints that would
+receive stack events.
-- parameter\_defaults:
+R-42685 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “parameter_merge_strategies:” section.
-- encrypted\_parameters:
+The “parameter_merge_strategies:” section provides the merge strategies
+for merging parameters and parameter defaults from the environment file.
-- event\_sinks:
+R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
+contain the “resource_registry:” section.
-- parameter\_merge\_strategies:
+ONAP implementation does not support the Environment File
+resource_registry section. The resource_registry section
+allows for the definition of custom resources.
-The use of an environment file in OpenStack is optional. In ONAP, it is
-mandatory. A Heat Orchestration Template uploaded to ONAP must have a
-corresponding environment file, even if no parameters are enumerated in
-the mandatory parameter section.
-
-(Note that ONAP, the open source version of ONAP, does not
-programmatically enforce the use of an environment file.)
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
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.
-
-Nested Heat Orchestration Templates Overview
---------------------------------------------
-
-ONAP supports nested Heat Orchestration Templates per OpenStack
-specifications.
+environment file. See `ONAP Parameter Classifications Overview`_ and
+`ONAP Resource ID and Parameter Naming Convention`_ for more details.
-A Base Module may utilize nested templates.
+ONAP Heat Orchestration Templates: Overview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-An Incremental Module may utilize nested templates.
-
-A Cinder Volume Module may utilize nested templates.
-
-A nested template must not define parameter constraints in the parameter
-definition section.
-
-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
-------------------------------------------
+ONAP supports a modular Heat Orchestration Template design pattern,
+referred to as *VNF Modularity.*
-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”.
-
-Base Modules
-~~~~~~~~~~~~
-
-The file name for the base module must include “base” in the filename
-and must match one of the following options:
-
-- base\_<text>.y[a]ml
-
-- <text>\_base.y[a]ml
+ONAP VNF Modularity Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- base.y[a]ml
+R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
+Templates, each of which represents a subset of the overall VNF.
-- <text>\_base\_<text>.y[a]ml
+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.
-The base module’s corresponding environment file must be named identical
-to the base module with “.y[a]ml” replaced with “.env”.
+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).
-Incremental Modules
-~~~~~~~~~~~~~~~~~~~
+R-37028 The VNF **MUST** be composed of one “base” module.
-There is no explicit naming convention for the incremental modules. As
-noted above, <text> represents any alphanumeric string that must not
-contain any special characters and must not contain the word “base”.
+R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
-- <text>.y[a]ml
+R-20974 The VNF **MUST** deploy the base module first, prior to
+the incremental modules.
-The incremental module’s corresponding environment file must be named
-identical to the incremental module with “.y[a]ml” replaced with “.env”.
+R-28980 A VNF’s incremental module **MAY** be used for initial VNF
+deployment only.
-To clearly identify the incremental module, it is recommended to use the
-following naming options for modules:
+R-86926 A VNF’s incremental module **MAY** be used for scale out only.
-- module\_<text>.y[a]ml
+A VNF’s Incremental Module that is used for scale out is deployed
+sometime after initial VNF deployment to add capacity.
-- <text>\_module.y[a]ml
+R-91497 A VNF’s incremental module **MAY** be used for both deployment
+and scale out.
-- module.y[a]ml
+R-68122 A VNF’s incremental module **MAY** be deployed more than once,
+either during initial VNF deployment and/or scale out.
-Cinder Volume Modules
-~~~~~~~~~~~~~~~~~~~~~
+R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
+**MAY** be defined in a Base Module.
-The file name for the Cinder volume module must be named the same as the
-corresponding module it is supporting (base module or incremental
-module) with “\_volume” appended
+R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in an Incremental Module.
-- <base module name>\_volume.y[a]ml
+R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in a Cinder Volume Module.
-- <incremental module name>\_volume.y[a]ml
+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).
-The volume module’s corresponding environment file must be named
-identical to the volume module with “.y[a]ml” replaced with “.env”.
+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
-Nested Heat file
-~~~~~~~~~~~~~~~~
+It is strongly recommended that Cinder Volumes be created in a Cinder Volume
+Module.
-There is no explicit naming convention for nested Heat files with the
-following exceptions; the name should contain “nest”. As noted above,
-<text> represents any alphanumeric string that must not contain any
-special characters and must not contain the word “base”.
+R-38474 The VNF **MUST** have a corresponding environment file for a
+Base Module.
-- <text>.y[a]m
+R-81725 The VNF **MUST** have a corresponding environment file for an
+Incremental Module.
-Nested Heat files do not have corresponding environment files, per
-OpenStack specifications. All parameter values associated with the
-nested heat file must be passed in as properties in the resource
-definition defined in the parent heat template.
+R-53433 The VNF **MUST** have a corresponding environment file for a
+Cinder Volume Module.
-ONAP Parameter Classifications Overview
----------------------------------------
+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.
-In order for ONAP to support workflow automation, Heat Orchestration
-Template resource property parameters must adhere to specific naming
-conventions and requirements.
+Nested Heat Orchestration Templates Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Broadly, ONAP categorizes parameters into four categories:
+ONAP supports nested Heat Orchestration Templates per OpenStack
+specifications.
-1. ONAP metadata parameters
+R-36582 A VNF’s Base Module **MAY** utilize nested heat.
-2. Instance specific parameters
+R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
-3. Constant parameters
+R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
-4. Output parameters.
+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).
-ONAP Metadata Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~
+See `Nested Heat Templates`_ for additional details.
-There are both mandatory and optional ONAP metadata parameters
-associated with the resource OS::Nova::Server.
+ONAP Heat Orchestration Template Filenames
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ONAP metadata parameters must not have parameter constraints defined.
+In order to enable ONAP to understand the relationship between Heat
+files, the following Heat file naming convention must be utilized.
-- Both mandatory and optional (if specified) ONAP metadata parameter
- names must follow the ONAP metadata parameter naming convention.
+In the examples below, <text> represents any alphanumeric string that
+must not contain any special characters and must not contain the word
+“base”.
-`Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
+R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
+be in the lower case format ‘.yaml’ or ‘.yml’.
-Instance specific parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
+**MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
-The instance specific parameters are VNF instance specific. The value of
-the parameter will be different for every instance of a VNF (e.g., IP
-address). The instance specific parameters are subdivided into two
-categories: **ONAP Orchestration Parameters** and **VNF Orchestration
-Parameters**
+R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
+**MUST** be in the lower case format ‘.env’.
-ONAP Orchestration Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Base Modules
+++++++++++++
-ONAP Orchestration Parameters are per instance parameters where the
-value is assigned via ONAP automation. (Note that in some cases,
-automation is currently not available and the value is loaded into ONAP
-prior to instantiation.)
+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’.
-- ONAP orchestration parameters must not be enumerated in the
- environment file.
+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’.
-- When the ONAP orchestration parameter type is set to number, the
- parameter must have constraints for range and/or allowed\_values.
+Incremental Modules
++++++++++++++++++++
-- Parameter constraints for ONAP orchestration parameters are optional
- for all parameter types other than number. If constraints are
- specified, they must adhere to the OpenStack specifications.
+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’.
-- The ONAP orchestration parameter names must follow the ONAP
- orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
- additional details.
+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’.
-VNF Orchestration Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+To clearly identify the incremental module, it is recommended to use the
+following naming options for modules:
-VNF Orchestration Parameters are per instance parameters where the
-values are assigned manually. They are not supported by ONAP automation.
-The per instance values are loaded into ONAP prior to VNF instantiation.
+ - module_<text>.y[a]ml
-- VNF orchestration parameters must not be enumerated in the
- environment file.
+ - <text>_module.y[a]ml
-- When the VNF orchestration parameter type is set to number, the
- parameter must have constraints for range or allowed\_values.
+ - module.y[a]ml
-- Parameter constraints for VNF orchestration parameters are optional
- for all parameter types other than number. If constraints are
- specified, they must adhere to the OpenStack specifications.
+ - <text>_module_<text>.y[a]ml
-- The VNF orchestration parameter names should follow the VNF
- orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
- additional details.
+Cinder Volume Modules
++++++++++++++++++++++
-Constant Parameters
-~~~~~~~~~~~~~~~~~~~
+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’
-The constant parameters are parameters that remain constant across many
-VNF instances (e.g., image, flavor). The constant parameters are
-subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
+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’.
-ONAP Constant Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^
+Nested Heat file
+++++++++++++++++
-- ONAP Constant Parameters must be enumerated in the environment file.
- These parameter values are not assigned by ONAP.
+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’.
-- When the ONAP Constant Parameter type is set to number, the parameter
- must have constraints for range and/or allowed\_values.
+Examples include
-- Parameter constraints for ONAP constant parameters are optional for
- all parameter types other than number. If constraints are specified,
- they must adhere to the OpenStack specifications.
+ - <text>.y[a]ml
-- The ONAP Constant Parameter names must follow the ONAP orchestration
- parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
+ - nest_<text>.y[a]ml
-VNF Constant Parameters
-^^^^^^^^^^^^^^^^^^^^^^^
+ - <text>_nest.y[a]ml
-- VNF Constant Parameters must be enumerated in the environment file.
- These parameter values are not assigned by ONAP.
+ - nest.y[a]ml
-- When the VNF Constant Parameters type is set to number, the parameter
- must have constraints for range and/or allowed\_values.
+ - <text>_nest_<text>.y[a]ml
-- Parameter constraints for ONAP constant parameters are optional for
- all parameter types other than number. If constraints are specified,
- they must adhere to the OpenStack specifications.
+VNF Heat Orchestration Template's Nested YAML file does not have a
+corresponding environment files, per OpenStack specifications.
-- The VNF Constant Parameters names should follow the ONAP
- orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
- additional details.
+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
~~~~~~~~~~~~~~~~~
3. ONAP Predefined Output Parameters.
ONAP Base Module Output Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++
-ONAP Base Module Output Parameters are declared in the outputs: section
-of the base module Heat Orchestration Template. A Base Module Output
+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.
+'parameters:'' section) to all Incremental Modules in the VNF.
-- A Base Module Output Parameter may be used as an input parameter in
- an incremental module.
+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.
-- The Output parameter name and type must match the input parameter
- name and type unless the Output parameter is of the type
- comma\_delimited\_list.
+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.
+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.
-- When a Base Module Output Parameter is declared as an input parameter
- in an incremental module Heat Orchestration Template, parameter
- constraints must not be declared.
+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
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++
-The volume template output parameters are only available for the module
-(base or add on) that the volume is associated with.
+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.
-- ONAP Volume Module Output Parameters are declared in the “outputs:”
- section of the Cinder volume module Heat Orchestration Template
+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.
-- An ONAP Volume Module Output Parameter is available as an input
- parameter (i.e., declared in the parameters: section) only for the
- module (base or incremental) that the Cinder volume module is
- associated with. The Output parameter name and type must match the
- input parameter name and type unless the Output parameter is of the
- type comma\_delimited\_list.
+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.
+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.
-- When an ONAP Volume Module Output Parameter is declared as an input
- parameter in a base module or incremental module, parameter
- constraints must not be declared.
+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
+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
-----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-VNF Heat Orchestration Templates must not be designed to utilize the
-OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
-does not support the use of heat stack-update command for scaling.
+ONAP does not support the use of heat stack-update command for scaling
+(growth/de-growth).
-It is important to note that ONAP only supports heat stack-update for
-image upgrades.
+R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
+utilize the OpenStack ‘heat stack-update’ command for scaling
+(growth/de-growth).
-Networking
-----------
+R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
+design to support scaling (growth/de-growth).
-ONAP defines two types of networks: External Networks and Internal
-Networks.
+Scope of a Heat Orchestration Template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-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 connects VMs in a VNF to
+R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance
+specific or Cloud site specific
-- VMs in another VNF or
+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.
-- an external gateway or router
+ONAP provides the instance specific parameter values to the Heat
+Orchestration Template at orchestration time.
-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-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
------------------
+~~~~~~~~~~~~~~~~~
-VNF Heat Orchestration Templates must not include any resources for
-external networks connected to the VNF. External networks must be
-orchestrated separately, as independent, stand-alone VNF Heat
-Orchestration Templates, so they can be shared by multiple VNFs and
-managed independently.
+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.
-When the external network is created, it must be assigned a unique
-{network-role}. The {network-role} should describe the network (e.g.,
-oam). The {network-role} while unique to the LCP, can repeat across
-LCPs.
+An External Network may be a Neutron Network or a Contrail Network.
-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 passed into the VNF Heat Orchestration
-Templates as parameters.
+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.
-- Neutron Network-id (UUID)
+R-00606 A VNF **MAY** be connected to zero, one or more than one external
+networks.
-- Neutron Network subnet ID (UUID)
+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.
-- Contrail Network Fully Qualified Domain Name (FQDN)
+R-29865 A VNF’s port connected to an external network **MUST NOT** connect
+the port to VMs in the same VNF.
-ONAP enforces a naming convention for parameters associated with
-external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
+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.
-Parameter values associated with an external network will be generated
-and/or assigned by ONAP at orchestration time. Parameter values
-associated with an external network must not be enumerated in the
-environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
+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.
-VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
-when attaching VMs to an external network
+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.
-- A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
+ONAP enforces a naming convention for parameters associated with
+external networks. `ONAP Resource ID and Parameter Naming Convention`_
+provides additional details.
-- An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
- controller
+Internal Networks
+~~~~~~~~~~~~~~~~~
-- Note that Neutron Floating IPs must not be used. ONAP does not
- support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
+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
-- ONAP supports the property allowed\_address\_pairs in the resource
- OS::Neutron:Port and the property
- virtual\_machine\_interface\_allowed\_address\_pairs in
- OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
- of a virtual IP (VIP) address to a set of VMs.
+R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
-VNF Heat Orchestration Templates must pass the appropriate external
-network IDs into nested VM templates when nested Heat is used.
+R-35666 If a VNF has an internal network, the VNF Heat Orchestration
+Template **MUST** include the heat resources to create the internal network.
-Internal Networks
------------------
+R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat
+Orchestration Template Base Module.
-The VNF Heat Orchestration Templates must include the resource(s) to
-create the internal network. The internal network must be either a
-Neutron Network or a Contrail Network.
+An Internal Network may be created using Neutron Heat Resources and/or
+Contrail Heat Resources.
-In the modular approach, internal networks must be created in the Base
-Module, with their resource IDs exposed as outputs (i.e., ONAP Base
-Module Output Parameters) for use by all incremental modules. If the
-Network resource ID is required in the base template, then a
-get\_resource must be used.
+R-52425 A VNF’s port connected to an internal network **MUST** connect
+the port to VMs in the same VNF.
-When the internal network is created, it should be assigned a unique
-{network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
-details.
+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.
-VNFs may use **Cloud assigned IP addresses** or
-**predetermined static IPs** when attaching VMs to an internal network.
+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.
-- A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
+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.
-- A predetermined static IP address is enumerated in the Heat
- environment file. Since an internal network is local to the VNF, IP
- addresses can be re-used at every VNF instance.
+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.
-- Note that Neutron Floating IPs must not be used. ONAP does not
- support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
+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.
-- ONAP supports the property allowed\_address\_pairs in the resource
- OS::Neutron:Port and the property
- virtual\_machine\_interface\_allowed\_address\_pairs in
- OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
- of a virtual IP (VIP) address to a set of VMs.
+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.
+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
2. Resource Property Parameters
{vm-type}
----------
+~~~~~~~~~
-The Heat Orchestration Templates for a VNF must assign a VNF unique
-{vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
-instantiated in the VNF. While the {vm-type} must be unique to the VNF,
-it does not have to be globally unique across all VNFs that ONAP
-supports.
+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:
-Any parameter that is associated with a unique Virtual Machine type in
-the VNF must include {vm-type} as part of the parameter name.
+ 1.) OS::Nova::Server property flavor value
-Any resource ID that is associated with a unique Virtual Machine type in
-the VNF must include {vm-type} as part of the resource ID.
+ 2.) OS::Nova::Server property image value
-Note that {vm-type} must not be a substring of {network-role}. A
-substring of a string is another string that occurs "in". For example,
-"oam" is a substring of "oam\_protected". It will cause the
-Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
-produce erroneous error messages.
+ 3.) Cinder Volume attachments
+ - Each VM in the 'class' **MUST** have the identical Cinder Volume
+ configuration
-The {vm-type} should not contain the string “\_int” or “int\_” or
-“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
-ICE Project) process to produce erroneous error messages.
+ 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:
-The {vm-type} must be the same case in all parameter names in the VNF.
+ 1.) The Resource OS::Nova::Server property availability_zone parameter
+ **MUST NOT** be prefixed with a common '{vm-type} identifier,
-The {vm-type} must be the same case in all Resource IDs in the VNF.
+ 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.
-It is recommended that the {vm-type} case in the parameter names matches
-the {vm-type} case in the Resource IDs.
-There are two exceptions to the above rules:
+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.
-1. The six 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, vm\_role*. The ONAP Metadata
- parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
+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.
-2. The parameter referring to the OS::Nova::Server property
- availability\_zone must not be prefixed with a common {vm-type}
- identifier. availability\_zone is described in `Property: availability_zone`_.
+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`_.
-Any parameter that is associated with an external network must include
-the {network-role} as part of the parameter name.
+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
-Any resource ID that is associated with an external network must include
-the {network-role} as part of the resource ID.
+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.
-Any parameter that is associated with an internal network must include
-int\_{network-role} as part of the parameter name.
+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.
-Any resource ID that is associated with an internal network must include
-int\_{network-role} as part of the resource ID.
+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.
-Note that {network-role} must not be a substring of {vm-type}. A
-substring of a string is another string that occurs "in". For example,
-"oam" is a substring of "oam\_protected". It will cause the
-Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
-produce erroneous error messages.
+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\_'.
-The {network-role} should not contain the string “\_int” or “int\_” or
-“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
-ICE Project) process to produce erroneous error messages.
+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.
-The {network-role} must be the same case in all parameter names in the
-VNF.
+R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource property parameter names **MUST** be the same case
-The {network-role} must be the same case in all Resource IDs in the VNF.
+R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource IDs **MUST** be the same case.
-It is recommended that the {network-role} case in the parameter names
-matches the {network-role} case in the Resource IDs.
+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
-------------
+~~~~~~~~~~~~
-Heat Orchestration Template resources are described in `resources`_
+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.
-A resource ID that must be unique within the resources section of a Heat
-Orchestration Template. This is an OpenStack Requirement.
+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.
-When a VNF is composed of more than one Heat Orchestration Template
-(i.e., modules), ONAP requires that the resource ID must be unique
-across all modules that compose the VNF.
+Heat Orchestration Template resources are described in `resources`_
-When a resource is associated with a single {vm-type}, the resource ID
-must contain {vm-type}.
+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}’.
-When a resource is associated with a single external network, the
-resource ID must contain {network-role}.
+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}’.
-When a resource is associated with a single internal network, the
-resource ID must contain int\_{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}’.
-When a resource is associated with a single {vm-type} and a single
-external network, the resource ID must contain both the {vm-type} and
-{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 (i.e., {vm-type}\_{network-role}).
+- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
+ be separated by an underscore '_'
-- Note that an {index} value may separate the {vm-type} and the
- {network-role}. An underscore will separate the three values (i.e.,
- {vm-type}\_{index}\_{network-role}).
+ - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
-When a resource is associated with a single {vm-type} and a single
-internal network, the resource ID must contain both the {vm-type} and
-int\_{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.
-- The {vm-type} must appear before the int\_{network-role} and must be
- separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
+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
-- Note that an {index} value may separate the {vm-type} and the
- int\_{network-role}. An underscore will separate the three values
- (i.e., {vm-type}\_{index}\_int\_{network-role}).
+- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
+ **MUST** be separated by an underscore '_'
-When a resource is associated with more than one {vm-type} and/or more
-than one network, the resource ID
+ - (e.g., '{vm-type}\_int\_{network-role}',
+ '{vm-type}_{index}\_int\_{network-role}')
-- must not contain the {vm-type} and/or
- {network-role}/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.
-- should contain the term “shared” and/or contain text that identifies
- the VNF.
+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
-Only alphanumeric characters and “\_” underscores must be used in the
-resource ID. Special characters must not be used.
+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.
-All {index} values must be zero based. That is, the {index} must start
-at zero and increment by one.
+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.
-+--------------------------------+------------------------------------------------------------+
-| Resource Type | Resource ID Format |
-+================================+============================================================+
-| OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
-+--------------------------------+------------------------------------------------------------+
-| OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
-+--------------------------------+------------------------------------------------------------+
-| OS::Heat::CloudConfig | {vm\_type}\_RCC |
-+--------------------------------+------------------------------------------------------------+
-| OS::Heat::MultipartMime | {vm\_type}\_RMM |
-+--------------------------------+------------------------------------------------------------+
-| OS::Heat::ResourceGroup | {vm\_type}\_RRG |
-+--------------------------------+------------------------------------------------------------+
-| OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
-+--------------------------------+------------------------------------------------------------+
-| OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
-+--------------------------------+------------------------------------------------------------+
-| | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
-+--------------------------------+------------------------------------------------------------+
-| OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
-+--------------------------------+------------------------------------------------------------+
-| OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
-+--------------------------------+------------------------------------------------------------+
-| OS::Nova::Server | {vm\_type}\_{index} |
-+--------------------------------+------------------------------------------------------------+
-| OS::Nova::ServerGroup | {vm\_type}\_RSG |
-+--------------------------------+------------------------------------------------------------+
-| OS::Swift::Container | {vm\_type}\_RSwiftC |
-+--------------------------------+------------------------------------------------------------+
-
- Table 1: Example OpenStack Heat Resource ID
-
-The table below provides example Contrail Heat resource ID for resources
-only associated with one {vm-type} and/or one network.
-
-+-------------------------------------------+---------------------------------------------+
-| Resource Type | Resource ID Format |
-+===========================================+=============================================+
-| OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
-+-------------------------------------------+---------------------------------------------+
-| OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
-+-------------------------------------------+---------------------------------------------+
-
- Table 2: Example Contrail Heat resource ID
+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
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
-additional details.
-
-Note that the {vm\_type} must be identical across all four property
-parameter for a given OS::Nova::Server resource.
-
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| Resource OS::Nova::Server |
-+=============================+===============================+==================+==============================+=================================+
-| Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-| availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
-
-Table 3 Resource Property Parameter Names
+the detailed requirements.
-Property: image
-~~~~~~~~~~~~~~~
+.. 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
-The parameter associated with the property image is an ONAP Constant
-parameter.
+ 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
-The parameters must be named {vm-type}\_image\_name in the Heat
-Orchestration Template.
+Property: image
++++++++++++++++
-The parameter must be declared as type: string
+R-71152 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
+type: ‘string’.
-The parameter must be enumerated in the Heat Orchestration Template
-environment file.
+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.
-Each VM type (i.e., {vm-type}) must have a separate parameter for image,
-even if more than one {vm-type} shares the same image. This provides
-maximum clarity and flexibility.
+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*
description: {vm-type} server image
Property: flavor
-~~~~~~~~~~~~~~~~
-
-The parameter associated with the property flavor is an ONAP Constant
-parameter.
+++++++++++++++++
-The parameters must be named {vm-type}\_flavor\_name in the Heat
-Orchestration Template.
+R-50436 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
+type: ‘string’.
-The 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’.
-The parameter must be enumerated in the Heat Orchestration Template
-environment file.
+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.
-Each VM type (i.e., {vm-type}) must have a separate parameter for
-flavors, even if more than one {vm-type} shares the same flavor. This
-provides maximum clarity and flexibility.
+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*
description: {vm-type} flavor
Property: Name
-~~~~~~~~~~~~~~
+++++++++++++++
-The parameter associated with the property name is an ONAP Orchestration
-parameter.
+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”.
-The parameter value is provided to the Heat template by ONAP. The
-parameter must not be enumerated in the environment file.
+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.
-The parameter must be declared as type: string or type:
-comma\_delimited\_list
+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}’.
-If the parameter is declared as type:string, the parameter must be named
-{vm-type}\_name\_{index}, where {index} is a numeric value that starts
-at zero and increments by one.
+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}’.
-If the parameter is declared as type:comma\_delimited\_list, the
-parameter must be named as {vm-type}\_names
+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.
-Each element in the VM Name list should be assigned to successive
-instances of that VM type.
+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.
-If a VNF contains more than three instances 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 Heat.
*Example: Parameter Definition*
-.. code-block:: yaml
+.. 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: comma\_delimited\_list*
+ {vm-type}_names:
+ type: comma_delimited_list
+ description: VM Names for {vm-type} VMs
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+ {vm-type}_name_{index}:
+ type: string
+ description: VM Name for {vm-type} VM {index}
-.. code-block:: yaml
+*Example: comma_delimited_list*
- parameters:
- lb_names:
- type: comma_delimited_list
- description: VM Names for lb VMs
+In this example, the {vm-type} has been defined as “lb” for load balancer.
- resources:
- lb_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: [lb_names, 0] }
- ...
+.. code-block:: python
- lb_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: [lb_names, 1] }
- ...
+ 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.
+In this example, the {vm-type} has been defined as “lb” for load balancer.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- lb_name_0:
- type: string
- description: VM Name for lb VM 0
+ parameters:
- lb_name_1:
- type: string
- description: VM Name for lb VM 1
+ lb_name_0:
+ type: string
+ description: VM Name for lb VM 0
- resources:
- lb_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: lb_name_0 }
- ...
+ lb_name_1:
+ type: string
+ description: VM Name for lb VM 1
- lb_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: lb_name_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
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+_____________________________________________________________
-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, the only special characters supported are:
+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
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++
-The parameter associated with the property availability\_zone is an ONAP
-Orchestration parameter.
+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.
-The parameter value is provided to the Heat template by ONAP. The
-parameter must not be enumerated in the environment file.
+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 be named availability\_zone\_{index} in the Heat
-Orchestration Template. The {index} must start at zero. The {index} must
-increment by one. The parameter name must not include the {vm-type}.
+The parameter must not be declared as type ‘comma_delimited_list’,
+ONAP does not support it.
-The parameter must be declared as type: string
+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.
-The parameter must not be declared as type: comma\_delimited\_list
+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.
+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:: yaml
+.. 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
+ parameters:
- 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_image_name:
+ type: string
+ description: dns server image
- 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 }
- . . .
+ dns_flavor_name:
+ type: string
+ description: dns server flavor
- 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 }
- . . .
+ dns_names:
+ type: comma_delimited_list
+ description: dns server names
- 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 }
- . . .
+ oam_image_name:
+ type: string
+ description: oam server image
-Resource: OS::Nova::Server – Metadata Parameters
-------------------------------------------------
+ oam_flavor_name:
+ type: string
+ description: oam server flavor
-The resource OS::Nova::Server has an OpenStack optional property
-metadata. The metadata property is mandatory for ONAP Heat Orchestration
-Templates; it must be included.
+ oam_name_0:
+ type: string
+ description: oam server name 0
-ONAP requires the following three mandatory metadata parameters for an
-OS::Nova::Server resource:
+ oam_name_1:
+ type: string
+ description: oam server name 1
-- vnf\_id
+ availability_zone_0:
+ type: string
+ description: availability zone ID or Name
-- vf\_module\_id
+ availability_zone_1:
+ type: string
+ description: availability zone ID or Name
-- vnf\_name
+ resources:
-ONAP allows the following three optional metadata parameters for an
-OS::Nova::Server resource. They may be included
+ 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 }
-- vm\_role
+ . . .
-- vf\_module\_name
+ 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 }
-Note that the metadata parameters do not and must not contain {vm-type}
-in their name.
+ . . .
-When Metadata parameters are past into a nested heat template, the
-parameter names must not change.
+ 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 }
-The table below provides a summary. The sections that follow provides
-additional details.
-
-+---------------------------+------------------+----------------------+------------------------------+
-| Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
-+===========================+==================+======================+==============================+
-| vnf\_id | string | Mandatory | ONAP |
-+---------------------------+------------------+----------------------+------------------------------+
-| vf\_module\_id | string | Mandatory | ONAP |
-+---------------------------+------------------+----------------------+------------------------------+
-| vnf\_name | string | Mandatory | ONAP |
-+---------------------------+------------------+----------------------+------------------------------+
-| vf\_module\_name | string | Optional | ONAP |
-+---------------------------+------------------+----------------------+------------------------------+
-| vm\_role | string | Optional | YAML or Environment File |
-+---------------------------+------------------+----------------------+------------------------------+
-+---------------------------+------------------+----------------------+------------------------------+
-
- Table 4: ONAP Metadata
+ . . .
-vnf\_id
-~~~~~~~
+ 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`_
-The vnf\_id parameter is mandatory; it must be included in the Heat
-Orchestration Template.
+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.
-The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
-UUID that is the vnf\_id and supplies it to the Heat Orchestration
+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.
-The parameter must be declared as type: string
+R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
-Parameter constraints must not be defined.
+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’.
-The parameter must not be enumerated in the Heat environment file.
+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.
-*Example Parameter Definition*
+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.
-.. code-block:: yaml
+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.
- parameters:
- vnf_id:
- type: string
- description: Unique ID for this VNF instance
+
+*Example 'vnf_id' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_id:
+ type: string
+ description: Unique ID for this VNF instance
vf\_module\_id
-~~~~~~~~~~~~~~
+++++++++++++++
-The vf\_module\_id parameter is mandatory; it must be included in the
-Heat Orchestration Template.
+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.
-The 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 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’.
-The parameter must be declared as type: string
+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’.
-Parameter constraints must not be defined.
+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.
-The parameter must not be enumerated in the Heat environment file.
+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.
-*Example Parameter Definition*
+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.
-.. code-block:: yaml
+*Example 'vf\_module\_id' Parameter Definition*
- parameters:
- vnf_module_id:
- type: string
- description: Unique ID for this VNF module instance
+.. code-block:: python
-vnf\_name
-~~~~~~~~~
+ parameters:
-The vnf\_name parameter is mandatory; it must be included in the Heat
-Orchestration Template.
+ vnf_module_id:
+ type: string
+ description: Unique ID for this VNF module instance
-The vnf\_name parameter value will be generated and/or assigned by ONAP
-and supplied to the Heat Orchestration Template by ONAP at orchestration
-time.
+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
-Parameter constraints must not be defined.
+R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vnf_name’.
-The parameter must not be enumerated in the Heat environment file.
+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’.
-*Example Parameter Definition*
+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.
-.. code-block:: yaml
+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.
- parameters:
- vnf_name:
- type: string
- description: Unique name for this VNF instance
+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.
-vf\_module\_name
-~~~~~~~~~~~~~~~~
+*Example 'vnf_name' Parameter Definition*
-The vf\_module\_name parameter is optional; it may be included in the
-Heat Orchestration Template.
+.. code-block:: python
-The vf\_module\_name parameter 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.
+ parameters:
-The parameter must be declared as type: string
+ vnf_name:
+ type: string
+ description: Unique name for this VNF instance
-Parameter constraints must not be defined.
+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.
-The parameter must not be enumerated in the Heat 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 Parameter Definition*
+*Example 'vf_module_name' Parameter Definition*
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- vf_module_name:
- type: string
- description: Unique name for this VNF Module instance
+ parameters:
+
+ vf_module_name:
+ type: string
+ description: Unique name for this VNF Module instance
vm\_role
-~~~~~~~~
+++++++++
-The vm\_role parameter is optional; it may be included in the Heat
-Orchestration Template.
+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.
-Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
-system and 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’.
-The vm\_role values must be either
+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’.
-- hard-coded into the Heat Orchestration Template or
+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.
-- enumerated in the environment file.
+R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+either
-Defining the vm\_role as the {vm-type} is a recommended convention
+ - enumerated in the VNF’s Heat Orchestration
+ Template’s environment file.
-The parameter must be declared as type: string
+ - hard coded in the VNF’s Heat Orchestration
+ Template’s OS::Nova::Resource metadata property.
-Parameter constraints must not be defined.
+Defining the 'vm_role' as the '{vm-type}' is a recommended convention
-*Example Parameter Definition*
+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 ‘_’.
-.. code-block:: yaml
+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.
- parameters:
- vm_role:
- type: string
- description: Unique role for this VM
-*Example Resource Definition: Hard Coded*
+*Example 'vm_role' Parameter Definition*
-In this example, the {vm-role} is hard coded in the Heat Orchestration
-Template.
+.. code-block:: python
-.. code-block:: yaml
+ parameters:
- resources:
- dns_servers:
- type: OS::Nova::Server
- properties:
- . . . .
- metadata:
- vm_role: lb
+ vm_role:
+ type: string
+ description: Unique role for this VM
-*Example Resource Definition: get\_param*
+*Example: 'vm-role' Definition: Hard Coded in
+OS::Nova::Resource metadata property*
-In this example, the {vm-role} is enumerated in the environment file.
+.. code-block:: python
-.. code-block:: yaml
+ resources:
- resources:
- dns_servers:
- type: OS::Nova::Server
- properties:
- . . . .
- metadata:
- vm_role: { get_param: vm_role }
+ dns_server_0
+ type: OS::Nova::Server
+ properties:
+ . . . .
+ metadata:
+ vm_role: dns
-Example
-~~~~~~~
+*Example 'vm-role' Definition: Defined in Environment file
+and retrieved via 'get_param'*
-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
-.. code-block:: yaml
+ resources:
- parameters:
+ 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
+ type: string
+ description: VM Name for lb VM 0
vnf_name:
- type: string
- description: Unique name for this VNF instance
+ type: string
+ description: Unique name for this VNF instance
vnf_id:
- type: string
- description: Unique ID for this VNF instance
+ type: string
+ description: Unique ID for this VNF instance
vf_module_name:
- type: string
- description: Unique name for this VNF Module instance
+ type: string
+ description: Unique name for this VNF Module instance
vf_module_id:
- type: string
- description: Unique ID for this VNF Module instance
+ type: string
+ description: Unique ID for this VNF Module instance
vm_role:
- type: string
- description: Unique role for this VM
+ 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
- resources:
+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
- lb_vm_0:
+
+*Example OS::Nova::Server with metadata*
+
+.. code-block:: python
+
+ resources:
+ . . .
+
+ {vm-type}_server_{index}:
type: OS::Nova::Server
properties:
- name: { get_param: lb_name_0 }
- ...
+ 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 }
- vm_role: lb
+ 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
+
+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
+
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used
+
+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
+
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
+
+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
+
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id'
+ **MUST NOT** be used
+
+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
+
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
+
+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.
-Resource: OS::Neutron::Port - Parameters
-----------------------------------------
+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.
-The resource OS::Neutron::Port is for managing Neutron ports (See
-https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
+.. 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
-Introduction
-~~~~~~~~~~~~
+ OS::Nova::Server, image, string, {vm-type}_image_name, Environment File
-Four properties of the resource OS::Neutron::Port that must follow the
-ONAP parameter naming convention. The four properties are:
+Property: network
++++++++++++++++++
-1. network
+The Resource 'OS::Neutron::Port' property 'network' determines what network
+the port is attached to.
-2. fixed\_ips, ip\_address
-3. fixed\_ips, subnet\_id
+R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘network’ parameter **MUST** be declared as type: ‘string’.
-4. allowed\_address\_pairs, ip\_address
+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**
-The parameters associated with these properties may reference an
-external network or internal network. External networks and internal
-networks are defined in `Networking`_.
+- 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.
-External Networks
-^^^^^^^^^^^^^^^^^
+where ‘{network-role}’ is the network-role of the external network and
+a ‘get_param’ **MUST** be used as the intrinsic function.
-When the parameter references an external network
-
-- the parameter name must contain {network-role}
-
-- the parameter must not be enumerated in the Heat environment file
-
-- the parameter is classified as an ONAP Orchestration Parameter
-
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| Property Name | ONAP Parameter Name | Parameter Type |
-+========================================+===============================================+==========================+
-| network | {network-role}\_net\_id | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {network-role}\_net\_name | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| fixed\_ips, subnet | {network-role}\_subnet\_id | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {network-role}\_v6\_subnet\_id | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| allowed\_address\_pairs, ip\_address | {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 | comma\_delimited\_list |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-| | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
-+----------------------------------------+-----------------------------------------------+--------------------------+
-
-Table 5: OS::Neutron::Port Resource Property Parameters (External
-Networks)
+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**
-Internal Networks
-^^^^^^^^^^^^^^^^^
+- 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.
-When the parameter references an internal network
-
-- the parameter name must contain int\_{network-role}
-
-- the parameter may be enumerated in the environment file.
-
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| Property | Parameter Name for Internal Networks | Parameter Type |
-+========================================+====================================================+==========================+
-| network | int\_{network-role}\_net\_id | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | int\_{network-role}\_net\_name | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | int\_{network-role}\_v6\_subnet\_id | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| allowed\_address\_pairs, ip\_address | {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 | comma\_delimited\_list |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-| | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
-+----------------------------------------+----------------------------------------------------+--------------------------+
-
-Table 6: Port Resource Property Parameters (Internal Networks)
+where ‘{network-role}’ is the network-role of the internal network
+and a ‘get_param’ **MUST** be used as the intrinsic function.
-Property: network
-~~~~~~~~~~~~~~~~~
+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.
-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.
+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.
-External Networks
-^^^^^^^^^^^^^^^^^
+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.
-When the parameter associated with the property network is referencing
-an “external” network, the parameter must adhere to the following naming
-convention in the Heat Orchestration Template
+The parameter values for external networks are provided by ONAP
+to the VNF's Heat Orchestration Template at orchestration time.
-- {network-role}\_net\_id for the Neutron network ID
+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.
-- {network-role}\_net\_name for the network name in OpenStack
+*Example Parameter Definition of External Networks*
-The parameter must be declared as type: string
+.. code-block:: python
-The parameter must not be enumerated in the Heat environment file.
+ parameters:
-*Example Parameter Definition*
+ {network-role}_net_id:
+ type: string
+ description: Neutron UUID for the external {network-role} network
-.. code-block:: yaml
+ {network-role}_net_name:
+ type: string
+ description: Neutron name for the external {network-role} network
- 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
-*Example: One Cloud Assigned IP Address (DHCP) assigned to a network
-that has only one subnet*
+*Example Parameter Definition of Internal Networks in an Incremental Module*
-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.
+.. code-block:: python
-.. code-block:: yaml
+ parameters:
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+ int_{network-role}_net_id:
+ type: string
+ description: Neutron UUID for the internal int_{network-role} network
- resources:
- lb_port_1:
- type: OS::Neutron::Port
- network: { get_param: oam_net_id }
+ int_{network-role}_net_name:
+ type: string
+ description: Neutron name for the internal int_{network-role} network
-Internal Networks
-^^^^^^^^^^^^^^^^^
+Property: fixed_ips, Map Property: ip_address
++++++++++++++++++++++++++++++++++++++++++++++
-When the parameter associated with the property network is referencing
-an “internal” network, the parameter must adhere to the following naming
-convention.
+The resource 'OS::Neutron::Port' property 'fixed_ips'
+map property 'ip_address'
+is used to assign one IPv4 or IPv6
+addresses to port.
-- int\_{network-role}\_net\_id for the Neutron network ID
+One 'OS::Neutron::Port' resource may assign one or more
+IPv4 and/or IPv6 addresses.
-- int\_{network-role}\_net\_name for the network name in OpenStack
+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’.
-The parameter must be declared as type: string
+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
-The assumption is that internal networks are created in the base module.
-The Neutron Network ID will be passed as an output parameter (e.g., ONAP
-Base Module Output Parameter) to the incremental modules. In the
-incremental modules, it will be defined as input parameter.
+- ‘{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
-*Example Parameter Definition*
+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.
-.. code-block:: yaml
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
- parameters:
- int_{network-role}_net_id:
- type: string
- description: Neutron UUID for the {network-role} network
- int_{network-role}_net_name:
- type: string
- description: Neutron name for the {network-role} network
+*Example External Network IPv4 Address string Parameter Definition*
-Property: fixed\_ips, Map Property: subnet\_id
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. code-block:: python
-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.
+ parameters:
-The property fixed\_ips and Map Property subnet\_id must be used if a
-Cloud (i.e., DHCP) IP address assignment is being requested and the
-Cloud IP address assignment is targeted at a specific subnet when two or
-more subnets exist.
+ {vm-type}_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
-The property fixed\_ips and Map Property subnet\_id should not be used
-if all IP assignments are fixed, or if the Cloud IP address assignment
-does not target a specific subnet or there is only one subnet.
+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
-Note that DHCP assignment of IP addresses is also referred to as cloud
-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
-Subnet of an External Networks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+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.
-When the parameter is referencing a subnet of an “external” network, the
-property fixed\_ips and Map Property subnet\_id parameter must adhere to
-the following naming convention.
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-- {network-role}\_subnet\_id if the subnet is an IPv4 subnet
+*Example External Network IPv4 Address comma_delimited_list
+Parameter Definition*
-- {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+.. code-block:: python
-The parameter must be declared as type: string
+ parameters:
-The parameter must not be enumerated in the Heat environment file.
+ {vm-type}_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the {network-role} network
-*Example Parameter Definition*
+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
-.. code-block:: yaml
+- ‘{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
- parameters:
- {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
+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.
-*Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
-that has two or more subnets subnet:*
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-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.
+*Example External Network IPv6 Address string Parameter Definition*
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+ parameters:
- oam_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+ {vm-type}_{network-role}_v6_ip_{index}:
+ type: string
+ description: Fixed IPv6 assignment for {vm-type} VM {index} on the {network-role} network
- resources:
- lb_port_1:
- type: OS::Neutron::Port
- network: { get_param: oam_net_id }
- fixed_ips:
- - subnet_id: { get_param: oam_subnet_id }
+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
-*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*
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the 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 lb for load
-balancer.
+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.
-.. code-block:: yaml
+ONAP's SDN-Controller assigns the IP Address and ECOMP provides
+the value at orchestration to the Heat Orchestration Template.
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+*Example External Network IPv6 Address comma_delimited_list Parameter
+Definition*
- oam_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+.. code-block:: python
- oam_v6_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+ parameters:
- resources:
- lb_port_1:
- 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 }
+ {vm-type}_{network-role}_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
-Internal Networks
-^^^^^^^^^^^^^^^^^
+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
-When the parameter is referencing the subnet of an “internal” network,
-the property fixed\_ips and Map Property subnet\_id parameter must
-adhere to the following naming convention.
+- ‘{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
-- int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
+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.
-- int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+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.
-The parameter must be declared as type: string
+*Example Internal Network IPv4 Address string Parameter Definition*
-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., ONAP Base Module Output Parameter) to the incremental modules. In
-the incremental modules, it will be defined as input parameter.
+.. code-block:: python
-*Example Parameter Definition*
+ parameters:
-.. code-block:: yaml
+ {vm-type}_int_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the int_{network-role} network
- parameters:
- int_{network-role}_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+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
- int_{network-role}_v6_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
-Property: fixed\_ips, Map Property: ip\_address
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+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 property fixed\_ips is used to assign IPs to a port. The Map
-Property ip\_address specifies the IP address to be assigned to the
-port.
+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.
-The property fixed\_ips and Map Property ip\_address must be used when
-statically assigning one or more IP addresses to a port. This is also
-referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
-the IP address assignment.
+.. code-block:: python
-An IP address is assigned to a port on a VM (referenced by {vm-type})
-that is connected to an external network (referenced by {network-role})
-or internal network (referenced by int\_{network-role}).
+ parameters:
-When a SDN-C IP assignment is made to a port connected to an external
-network, the parameter name must contain {vm-type} and {network-role}.
+ {vm-type}_int_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
-When a SDN-C IP assignment is made to a port connected to an internal
-network, the parameter name must contain {vm-type} and
-int\_{network-role}.
+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
-IP Address Assignments on External Networks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+- ‘{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
-When the property fixed\_ips and Map Property ip\_address is used to
-assign IP addresses to an external network, the parameter name is
-dependent on the parameter type (comma\_delimited\_list or string) and
-IP address type (IPv4 or IPv6).
+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.
-When the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: comma\_delimited\_list, the parameter must adhere to
-the following naming convention
+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.
-- {vm-type}\_{network-role}\_ips for IPv4 address
+*Example Internal Network IPv6 Address string Parameter Definition*
-- {vm-type}\_{network-role}\_v6\_ips for IPv6 address
+.. code-block:: python
-Each element in the IP list should be assigned to successive instances
-of {vm-type} on {network-role}.
+ parameters:
-The parameter must not be enumerated in the Heat environment file.
+ {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
-*Example Parameter Definition*
+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
-.. code-block:: yaml
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
- parameters:
+*Example Internal Network IPv6 Address comma_delimited_list Parameter
+Definition*
- {vm-type}_{network-role}_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
+.. code-block:: python
- {vm-type}_{network-role}_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
+ parameters:
-*Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
-Assignments to an external network*
+ {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
-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.
+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.
-.. code-block:: yaml
+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.
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for a oam network
+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.,
- db_oam_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for db VMs on the oam network
+- {vm-type}_{network-role}\_ip\_{index}
+- {vm-type}_{network-role}\_ip\_v6\_{index}
+- {vm-type}_{network-role}_ips
+- {vm-type}_{network-role}_v6_ips
- db_oam_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for db VMs on the oam network
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+Environment File. ONAP provides the IP address assignments at
+orchestration time.
- 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 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
+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.,
- db_1_port_1:
- 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 ]}
+- {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
-When the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: string, the parameter must adhere to the following
-naming convention.
+**MUST** be enumerated in the Heat Orchestration Template’s Environment
+File and IP addresses **MUST** be assigned.
-- {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
+Summary Table
+_____________
-- {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+.. 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
-The value for {index} must start at zero (0) and increment by one.
+ 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 parameter must not be enumerated in the Heat environment file.
-*Example Parameter Definition*
+Examples
+________
-.. code-block:: yaml
+*Example: comma_delimited_list parameters for IPv4 and IPv6 Address
+Assignments to an external network*
- parameters:
- {vm-type}_{network-role}_ip_{index}:
- type: string
- description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} 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.
- {vm-type}_{network-role}_v6_ip_{index}:
- type: string
- description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
+.. 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 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*
+*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
+In this example, the '{network-role}' has been defined as 'oam' to
+represent an oam network and the '{vm-type}' has been defined as 'db' for
database.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
+ parameters:
oam_net_id:
- type: string
- description: Neutron UUID for an OAM network
+ 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*
- db_oam_ip_0:
- type: string
- description: Fixed IPv4 assignment for db VM 0 on the OAM 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.
- db_oam_ip_1:
- type: string
- description: Fixed IPv4 assignment for db VM 1 on the OAM network
+.. code-block:: python
+
+ 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.
+
+.. code-block:: python
+
+ 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}}]
- 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
+Property: fixed\_ips, Map Property: subnet\_id
+++++++++++++++++++++++++++++++++++++++++++++++
- resources:
- db_0_port_1:
- 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 ]}}]
+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).
- db_1_port_1:
- 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}}]
+The IP address assignment will be made from the specified subnet.
+
+Specifying the subnet is not required; it is optional.
-IP Address Assignment on Internal Networks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+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.
-When the property fixed\_ips and Map Property ip\_address is used to
-assign IP addresses to an internal network, the parameter name is
-dependent on the parameter type (comma\_delimited\_list or string) and
-IP address type (IPv4 or IPv6).
+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.
-When the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: comma\_delimited\_list, the parameter must adhere to
-the following naming convention
+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.
-- {vm-type}\_int\_{network-role}\_ips for IPv4 address
+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.
-- {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
+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’.
-Each element in the IP list should be assigned to successive instances
-of {vm-type} on {network-role}.
+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.
-The parameter must be enumerated in the Heat environment file. Since an
-internal network is local to the VNF, IP addresses can be re-used at
-every VNF instance.
+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:: yaml
+.. code-block:: python
- parameters:
+ parameters:
- {vm-type}_int_{network-role}_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
+ {network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the {network-role} network
- {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
+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.
-*Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
-Assignments to an internal network*
+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.
-In this example, the {network-role} has been defined as oam\_int to
-represent an oam network internal to the vnf. The role oam\_int was
-picked to differentiate from an external oam network with a
-{network-role} of oam. The {vm-type} has been defined as db for
-database.
+ONAP's SDN-Controller provides the network's subnet's UUID
+value at orchestration to the Heat Orchestration Template.
-.. code-block:: yaml
+*Example Parameter Definition*
- parameters:
- int_oam_int_net_id:
- type: string
- description: Neutron UUID for the oam internal network
+.. code-block:: python
- db_int_oam_int_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for db VMs on the oam internal network
+ parameters:
- db_int_oam_int_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for db VMs on the oam internal network
+ {network-role}_v6_subnet_id:
+ type: string
+ description: Neutron IPv6 subnet UUID for the {network-role} network
- resources:
- db_0_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
- db_1_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips:
- - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
- - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
+*Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
+that has two or more IPv4 subnets*
+
+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.
-When the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: string, the parameter must adhere to the following
-naming convention.
+.. code-block:: python
-- {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
+ 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 }
-- {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+*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*
-The value for {index} must start at zero (0) and increment by one.
+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 parameter must be enumerated in the Heat environment file. Since an
-internal network is local to the VNF, IP addresses can be re-used at
-every VNF instance.
+.. code-block:: python
-*Example Parameter Definition*
+ 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.
-.. code-block:: yaml
+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.
- parameters:
+*Example Parameter Definition*
- {vm-type}_int_{network-role}_ip_{index}:
- type: string
- description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
+.. code-block:: python
- {vm-type}_int_{network-role}_v6_ip_{index}:
- type: string
- description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
+ parameters:
-*Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
+ int_{network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the int_{network-role} network
-In this example, the {network-role} has been defined as oam\_int to
-represent an oam network internal to the vnf. The role oam\_int was
-picked to differentiate from an external oam network with a
-{network-role} of oam. The {vm-type} has been defined as db for
-database.
+R-76160 When
-.. code-block:: yaml
+- 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’,
- parameters:
- int_oam_int_net_id:
- type: string
- description: Neutron UUID for an OAM internal network
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
+is the network role of the internal network
- db_oam_int_ip_0:
- type: string
- description: Fixed IPv4 assignment for db VM on the oam_int network
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
- db_oam_int_ip_1:
- type: string
- description: Fixed IPv4 assignment for db VM 1 on the oam_int network
+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.
- db_oam_int_v6_ip_0:
- type: string
- description: Fixed IPv6 assignment for db VM 0 on the oam_int network
+*Example Parameter Definition*
- db_oam_int_v6_ip_1:
- type: string
- description: Fixed IPv6 assignment for db VM 1 on the oam_int network
+.. code-block:: python
- resources:
- db_0_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 ]}}]
+ parameters:
+
+ int_{network-role}_v6_subnet_id:
+ type: string
+ description: Neutron subnet UUID for the int_{network-role} network
- db_1_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: 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
Neutron-style Floating IPs.
External Networks
-^^^^^^^^^^^^^^^^^
+_________________
-When the parameter is referencing an “external” network, the property
-allowed\_address\_pairs and Map Property ip\_address parameter must
-adhere to the following naming convention.
+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:
- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
Internal Networks
-^^^^^^^^^^^^^^^^^
+_________________
-When the parameter is referencing an “internal” network, the property
-allowed\_address\_pairs and Map Property ip\_address parameter must
-adhere to the following naming convention.
+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
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 CDL and then the VIPs as shown in the examples above.
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
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`_.
+OS::Nova::Server has been defined in
+`Resource: OS::Nova::Server – Metadata Parameters`_.
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.
-When the property name for a non OS::Nova::Server resources is defined
-in a Heat Orchestration Template, the intrinsic function str\_replace
-must be used in conjunction with the ONAP supplied metadata parameter
-vnf\_name to generate a unique value. This prevents the enumeration of a
+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
. . . .
Contrail Issue with Values for the Property Name
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++++++++++++++++++++++
The Contrail GUI has a limitation displaying special characters. The
issue is documented in
- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
ONAP Output Parameter Names
----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
-ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
+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.
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 the OAM
Management IP Addresses.
OAM Management IP Addresses
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+___________________________
A VNF may have a management interface for application controllers to
interact with and configure the VNF. Typically, this will be via a
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
- get_param: fw_sec_grp_id
Interface Route Table Prefixes for Contrail InterfaceRoute Table
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The parameter associated with the resource
OS::ContrailV2::InterfaceRouteTable property
- 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
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
be embedded within the Base Module or Incremental Module if persistence
is not required.
-If a VNF Base Module or Incremental Module has an independent volume
-module, the scope of volume templates must be 1:1 with Base module or
-Incremental module. A single volume module must create only the volumes
+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
+
+A single volume module must create only the volumes
required by a single Incremental module or Base module.
The following rules apply to independent volume Heat templates:
- Cinder volumes must be created in a separate Heat Orchestration
Template from the Base Module or Incremental Module.
- - A single Cinder volume module must include all Cinder volumes
- needed by the Base/Incremental module.
+- A single Cinder volume module must include all Cinder volumes
+ needed by the Base/Incremental module.
- - The volume template must define “outputs” for each Cinder volume
- resource universally unique identifier (UUID) (i.e. ONAP Volume
- Template Output Parameters).
+- 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).
- The VNF Incremental Module or Base Module must define input
parameters that match each Volume output parameter (i.e., ONAP Volume
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. A Heat Orchestration Template uploaded to ONAP must have a
+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.)
-A Base Module Heat Orchestration Template must have a corresponding
-environment file.
+R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file for a Base Module.
-An Incremental Module Heat Orchestration Template must have a
-corresponding environment file.
+R-35727 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file for an Incremental module.
-A Cinder Volume Module Heat Orchestration Template must have a
-corresponding environment file.
+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.
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.
+`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
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
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
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
resource\_registry in the environment file is not supported and must not
be used.
-A nested heat yaml file must have a unique file names within the scope
-of the VNF
+R-89868 The VNF Heat Orchestration Template **MUST** have unique
+file names within the scope of the VNF for a nested heat yaml file.
-ONAP does not support a directory hierarchy for nested templates. All
-templates must be in a single, flat directory (per VNF)
+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.
- Constrains must not be defined for any parameter enumerated in a
nested heat template.
-- All parameters defined in nested heat must be passed in as properties
- of the resource calling the nested yaml file.
+- 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.
-- When OS::Nova::Server metadata parameters are past into a nested heat
- template, the parameter names must not change
+- 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
get\_attribute targets against the “parent” resource.
Nested Heat Template Example: Static
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++++
incremental.yaml
vnf_name {get_param: vnf_name }
Use of Heat ResourceGroup
-~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++
The OS::Heat::ResourceGroup is a useful Heat element for creating
multiple instances of a given resource or collection of resources.
-Typically it is used with a nested Heat template, to create, for
+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.
{ get\_param: [names, {get\_param: index} ] }
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
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
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
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
Support for Heat Files is subject to the following limitations:
-- The get\_files targets must be referenced in Heat templates by file
- name, and the corresponding files should be delivered to ONAP along
- with the Heat templates.
+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.
- - URL-based file retrieval must not be used; it is not supported.
+R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
-- The included files must have unique file names within the scope of
- the VNF.
+R-62177 The VNF Heat Orchestration Template **MUST** have unique
+file names for the included files within the scope of the VNF.
-- ONAP does not support a directory hierarchy for included files.
-
- - All files must be in a single, flat directory per 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.
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
save_private_key: false
Security Groups
----------------
+~~~~~~~~~~~~~~~
OpenStack allows a tenant to create Security groups and define rules
within the security groups.
{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
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:
instance_uuid: {get_resource: oam_server_01}
High Availability
------------------
+^^^^^^^^^^^^^^^^^
VNF/VM parameters may include availability zone IDs for VNFs that
require high availability.
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
*Note:* It is important to follow this convention to the extent possible
even in the short-term as of the long-term direction.
-c. VNFM Driver Development Steps
-================================
+VNFM Driver Development Steps
+-----------------------------------------------------------
-Refer to the ONAP documentation for VNF provider instructions on integrating
-special VNFM adaptors with VF-C. The VNF driver development steps are
-highlighted below.
+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.
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
+the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
validated and tested.
-2. The VNF provider can provide a special VNFM driver in ONAP, which
+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 special VNFM. The interface definitions of special VNFM adaptors are provided by
-the VNF providers themselves.
+the vendor-specific VNFM. The interface definitions of vendor-specific
+VNFM adaptors are supplied by the VNF Providers themselves.
-d. Creating Special VNFM Adaptor Microservices
-==============================================
+Creating Vendor-Specific VNFM Adaptor Microservices
+------------------------------------------------------------------------------------------------
-VNFs can be managed by special VNFMs. To add a special VNFM to ONAP, a
-special VNFM adaptor is added to ONAP implementing the interface of the special VNFM.
+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.
-A special VNFM adaptor is a microservice with a unique name and an appointed
-port. When started up, the special VNFM adaptor microservice is automatically registered to the
-Microservices Bus (MSB). The following RESTful example describes the scenario of
-registering a special VNFM adaptor to MSB:
+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:
.. code-block:: java
Code Review / vnfrqts / requirements.git / blobdiff