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
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 | | |
-+-----------------------------------------+---------------------------------------+-----------------------+
++---------------------+------------------------------------+-----------------+
+| **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 | tosca.nodes.nfv.Cpd | tosca.nodes.Root|
+| Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root|
++---------------------+------------------------------------+-----------------+
+| VduCpd (internal | tosca.nodes.nfv.VduCpd | tosca.nodes.\ |
+| connection point) | | nfv.Cpd |
++---------------------+------------------------------------+-----------------+
+| VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root|
+| (Virtual Link) | | |
++---------------------+------------------------------------+-----------------+
+| VnfExtCpd (External | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root|
+| Connection Point) | | |
++---------------------+------------------------------------+-----------------+
+| Virtual Storage | | |
++---------------------+------------------------------------+-----------------+
+| Virtual Compute | | |
++---------------------+------------------------------------+-----------------+
+| Software Image | | |
++---------------------+------------------------------------+-----------------+
+| Deployment Flavour | | |
++---------------------+------------------------------------+-----------------+
+| Scaling Aspect | | |
++---------------------+------------------------------------+-----------------+
+| Element Group | | |
++---------------------+------------------------------------+-----------------+
+| Instantiation | | |
+| Level | | |
++---------------------+------------------------------------+-----------------+
+
+--------------------------------------------------------------------+
| +--------------------------------------------------------------+ |
+====================================================================+
+--------------------------------------------------------------------+
-EPA Requirements
+HPA Requirements
^^^^^^^^^^^^^^^^^^
1. SR-IOV Passthrought
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 | | | |
-+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
++---------------+---------+---------------+------------+----------------------+
+| Name | Required| Type | Constraints| Description |
++===============+=========+===============+============+======================+
+| request\ | No | tosca.\ | | Describes additional |
+| _additional\ | | datatypes.\ | | capability for a |
+| _capabilities | | nfv.Requested\| | particular VDU. |
+| | | Additional\ | | |
+| | | Capability | | |
++---------------+---------+---------------+------------+----------------------+
+| virtual\ | yes | tosca.\ | | Describes virtual |
+| _memory | | datatypes.\ | | memory of the |
+| | | nfv.Virtual\ | | virtualized compute. |
+| | | Memory | | |
++---------------+---------+---------------+------------+----------------------+
+| virtual\ | yes | tosca.\ | | Describes virtual |
+| _cpu | | datatypes.\ | | CPU(s) of the |
+| | | nfv.Virtual\ | | virtualized compute. |
+| | | Cpu | | |
++---------------+---------+---------------+------------+----------------------+
+| name | yes | | | |
++---------------+---------+---------------+------------+----------------------+
Definition
+++++++++++
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 |
-+-----------+------------+-------------------------------+---------------+------------------------------------------------+
+++++++++++
+
++--------+---------+----------------+------------+------------------------+
+| Name | Required| Type | Constraints| Description |
++========+=========+================+============+========================+
+| SwImage| Yes | tosca.\ | | Describes the software |
+| | | artifacts.nfv.\| | image which is directly|
+| | | SwImage | | realizing this virtual |
+| | | | | storage |
++--------+---------+----------------+------------+------------------------+
|image2|
+++++++++++
-+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| 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 |
-+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
++-----------------+---------+---------------+------------+--------------------+
+| Name | Required| Type | Constraints| Description |
++=================+=========+===============+============+====================+
+| bitrate\ | no | integer | | Bitrate requirement|
+| _requirement | | | | on this connection |
+| | | | | point. |
++-----------------+---------+---------------+------------+--------------------+
+| virtual\ | | Virtual\ | | Specifies |
+| _network\ | no | Network\ | | requirements on a |
+| _interface_\ | | Interface\ | | virtual network |
+| requirements | | Requirements\ | | realising the CPs |
+| | | | | instantiated from |
+| | | | | this CPD |
++-----------------+---------+---------------+------------+--------------------+
Attributes
+++++++++++
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 |
-+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
++----------+---------+--------------------+------------+----------------------+
+| Name | Required| Type | Constraints| Description |
++==========+=========+====================+============+======================+
+| virtual\ | yes | tosca.\ | | Describe the |
+| _binding | | capabilities.nfv.\ | | requirement for |
+| | | VirtualBindable\ | | binding with VDU |
++----------+---------+--------------------+------------+----------------------+
+| virtual\ | no | tosca.\ | | Describes the |
+| _link | | capabilities.nfv.\ | | requirements for |
+| | | VirtualLinkable | | linking to virtual |
+| | | | | link |
++----------+---------+--------------------+------------+----------------------+
Definition
+++++++++++
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
+++++++++++
-------------
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
-- R-43125 The VNF Heat **MUST** indent 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
++++++++++++++++++++++
-R-67888 The VNF Heat **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:
-R-39402 The VNF Heat **MUST** contain the description section.
+ <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>
+
+ default: <default value for parameter>
+
+ hidden: <true | false>
+
+ constraints:
+
+ <parameter constraints>
-R-35414 The VNF Heat **MUST** contain the parameter section.
+ immutable: <true | false>
This section allows for
-specifying input parameters that must be provided when instantiating
-the template. Each parameter is specified in a separated nested block
+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 The VNF Heat **MUST** use in a resource all parameters declared in a template
-except for the parameters for the OS::Nova::Server property
-availability\_zone. See `Property: availability\_zone`_. for more details on
-availability\_zone.
+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.
-.. code-block:: yaml
+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.
- 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>
+<param name>
+____________
+
+The name of the parameter.
+
+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".
-- param name:
+label
+_____
- - The name of the parameter.
+R-32094 A VNF's Heat Orchestration Template parameter
+declaration **MAY** contain the attribute "label:"
- - ONAP requires that the param name must contain only alphanumeric
- characters and “\_” underscores. Special characters must not be
- used.
+description
+___________
+
+R-44001 A VNF's Heat Orchestration Template parameter
+declaration **MUST** contain the attribute "description".
+
+Note that the parameter attribute “description:” is an
+OpenStack optional attribute that provides a description
+of the parameter. ONAP implementation requires this attribute.
+
+default
+_______
-- type:
+R-90526 A VNF Heat Orchestration Template parameter
+declaration **MUST** not contain the default attribute.
- - The type of the parameter. Supported types are string, number,
- comma\_delimited\_list, json and boolean.
+R-26124 If a VNF Heat Orchestration Template parameter
+requires a default value, it **MUST** be enumerated in the environment file.
- - R-28657 The VNF Heat **MUST** provide the attribute 'type' on parameters per the OpenStack Heat
- Orchestration Template standard.
+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.
-- label:
+hidden
+______
- - A human readable name for the parameter.
+R-32557 A VNF's Heat Orchestration Template parameter
+declaration MAY contain the attribute "hidden:".
- - This attribute is optional.
+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.
-- description:
+constraints
+___________
- - A human readable description for the parameter.
+The parameter attribute "constraints:" is an OpenStack optional
+attribute that defines a list of constraints to apply to the parameter.
- - R-44001 The VNF Heat **MUST** provide the attribute 'description' on parameters. (Note that
- this attribute is OpenStack optional.)
+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.
-- default:
+R-40518 A VNF's Heat Orchestration Template’s parameter defined as
+type "string" **MAY** have a parameter constraint defined.
- - A default value for the parameter.
+R-96227 A VNF's Heat Orchestration Template’s parameter defined as
+type "json" **MAY** have a parameter constraint defined.
- - R-90526 The VNF Heat **MUST NOT** use the attribute 'default'.
- If a parameter has a default
- value, it must be provided in the environment file. (Note that
- this attribute is OpenStack optional.)
+R-79817 A VNF's Heat Orchestration Template’s parameter defined as
+type "comma_delimited_list" **MAY** have a parameter constraint defined.
-- hidden:
+R-06613 A VNF's Heat Orchestration Template’s parameter defined as
+type "boolean" **MAY** have a parameter constraint 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-00011 A VNF's Heat Orchestration Template's Nested YAML files
+parameter's **MUST NOT** have a parameter constraint defined.
- - This attribute is optional and defaults to false.
+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.
-- constraints:
+The constraints are defined as a list with the following syntax
- - 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
+.. code-block:: python
- constraints:
+ constraints:
- - <constraint type>: <constraint definition>
+ <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**
-- R-88863 The VNF Heat **MUST** have a constraint of range or allowed\_values for a parameter type 'number'.
+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.
-R-23664 The VNF Heat **MUST** have a resources: section with the declaration of at least one resource.
+R-40551 A VNF's Heat Orchestration Template's Nested YAML files
+**MAY** contain the section "resources:".
-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.
+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:: python
-.. code-block:: yaml
+ resources:
- 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>:
-- resource ID
+ type: <resource type>
- - A resource ID that must be unique within the resources section of
- the Heat Orchestration Template.
+ properties:
- - R-16447 The VNF Heat **MUST** have unique resource IDs 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).
+ <property name>: <property value>
- - The naming convention for a resource ID is provided in `Resource IDs`_.
+ metadata:
-- type
+ <resource specific metadata>
- - 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.
+ depends_on: <resource ID or list of ID>
-- properties
+ update_policy: <update policy>
- - 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.
+ deletion_policy: <deletion policy>
- - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
+ external_id: <external resource ID>
-- metadata
+ condition: <condition name or expression or boolean>
- - Resource-specific metadata. This section is optional, except for
- the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
- - R-97199 The VNF Heat **MUST** use the metadata property for OS::Nova::Server resource type.
-- depends\_on
+resource ID
+___________
- - Dependencies of the resource on one or more resources of the
- template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
+R-75141 A VNF's Heat Orchestration Template's resource name
+(i.e., <resource ID>) **MUST** only contain alphanumeric
+characters and underscores ('_').
-- update\_policy
+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.
- - 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.
+Note that a VNF can be composed of one or more Heat Orchestration Templates.
-- deletion\_policy
+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.
- - 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.
+type
+____
-- external\_id
+The resource attribute \"type:\" is an OpenStack required
+attribute that defines the resource type, such as
+OS::Nova::Server or OS::Neutron::Port.
- - 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.
+The resource attribute \"type:\" may specify a VNF HEAT
+Orchestration Template Nested YAML file.
-- condition
+R-53952 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based resource definitions.
- - Condition for the resource. The condition decides whether to
- create the resource or not. This attribute is optional.
+R-71699 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based Nested YAML file.
-outputs
-++++++++
+properties
+__________
-This ONAP optional 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.
+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>`__).
-Environment File Format
-^^^^^^^^^^^^^^^^^^^^^^^^
+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 environment file is a yaml text file.
-(https://docs.openstack.org/developer/heat/template_guide/environment.html)
+metadata
+________
-The environment file can contain the following sections:
+The resource attribute \"metadata:\" is an OpenStack optional attribute.
-- parameters: A list of key/value pairs.
+R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
+resource **MUST** contain the attribute "metadata".
-- resource\_registry: Definition of custom resources.
+Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
-- parameter\_defaults: Default parameters passed to all template
- resources.
-- encrypted\_parameters: List of encrypted parameters.
+depends_on
+__________
-- event\_sinks: List of endpoints that would receive stack events.
+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.
-- parameter\_merge\_strategies: Merge strategies for merging parameters
- and parameter defaults from the environment file.
+R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “depends_on:”.
-R-03324 The VNF Heat **MUST** contain the following sections in the environment file:
+update_policy
+_____________
-- parameters:
+R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “update_policy:”.
-Environment files for ONAP may contain the following sections:
+deletion_policy
+_______________
-- resource\_registry:
+R-43740 A VNF’s Heat Orchestration Template’s Resource
+**MAY** declare the attribute “deletion_policy:”.
-- parameter\_defaults:
+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.
-- encrypted\_parameters:
+The default policy is to delete the physical resource when
+deleting a resource from the stack.
-- event\_sinks:
+external_id
+___________
-- parameter\_merge\_strategies:
+R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
+declare the attribute “external_id:”.
-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.
+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.
-(Note that ONAP, the open source version of ONAP, does not
-programmatically enforce the use of an environment file.)
-SDC Treatment of Environment Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+condition
+_________
-Parameter values enumerated in the environment file are used by SDC as
-the default value. However, the SDC user may use the SDC GUI to
-overwrite the default values in the environment file.
+The resource attribute \"condition:\" is an OpenStack optional attribute.
-SDC generates a new environment file for distribution to MSO based on
-the uploaded environment file and the user provided GUI updates. The
-user uploaded environment file is discarded when the new file is
-created.
+Support for the resource condition attribute was added
+in the Newton release of OpenStack.
-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.
+outputs
++++++++
-Nested Heat Orchestration Templates Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+R-36982 A VNF’s Heat Orchestration template **MAY** contain the “outputs:” section.
-ONAP supports nested Heat Orchestration Templates per OpenStack
-specifications.
+This section allows for specifying output parameters
+available to users once the template has been instantiated. If the
+section is specified, it will need to adhere to specific requirements.
+See `ONAP Parameter Classifications Overview`_ and
+`ONAP Output Parameter Names`_ for additional details.
+
+Environment File Format
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The environment file is a yaml text file.
+(https://docs.openstack.org/developer/heat/template_guide/environment.html)
-A Base Module may utilize nested templates.
+R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file, even if no parameters are required to be enumerated.
-An Incremental Module may utilize nested templates.
+The use of an environment file in OpenStack is optional.
+In ONAP, it is mandatory.
-A Cinder Volume Module may utilize nested templates.
+R-03324 The VNF Heat Orchestration Template **MUST** contain the
+"parameters" section in the
+environment file
-A nested template must not define parameter constraints in the parameter
-definition section.
+R-68198 A VNF’s Heat Orchestration template’s Environment File’s
+“parameters:” section **MAY** enumerate 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 implementation requires the parameters section in the
+environmental file to be declared. The parameters section
+contains a list of key/value pairs.
-See `Nested Heat Templates`_ for additional details.
+R-59930 A VNF’s Heat Orchestration template’s Environment
+File’s **MAY** contain the “parameter_defaults:” section.
-ONAP Heat Orchestration Template Filenames
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The “parameter_defaults:” section contains default parameters
+that are passed to all template resources.
-In order to enable ONAP to understand the relationship between Heat
-files, the following Heat file naming convention must be utilized.
+R-46096 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “encrypted_parameters:” section.
-In the examples below, <text> represents any alphanumeric string that
-must not contain any special characters and must not contain the word
-“base”.
+The “encrypted_parameters:” section contains a list of encrypted parameters.
-Base Modules
-~~~~~~~~~~~~~~
+R-24893 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “event_sinks:” section.
-R-19473 The VNF Heat **MUST** include “base” in the filename for the base module
+The “event_sinks:” section contains the list of endpoints that would
+receive stack events.
-R-81339 The VNF Heat **MUST** match one of the following options for the base module file name:
+R-42685 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “parameter_merge_strategies:” section.
-- base\_<text>.y[a]ml
+The “parameter_merge_strategies:” section provides the merge strategies
+for merging parameters and parameter defaults from the environment file.
-- <text>\_base.y[a]ml
+R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
+contain the “resource_registry:” section.
-- base.y[a]ml
+ONAP implementation does not support the Environment File resource_registry
+section. The resource_registry section allows for the definition of custom resources.
-- <text>\_base\_<text>.y[a]ml
-R-91342 The VNF Heat **MUST** name the base module’s corresponding environment file to be identical
-to the base module with “.y[a]ml” replaced with “.env”.
+SDC Treatment of Environment Files
+++++++++++++++++++++++++++++++++++
-Incremental Modules
-~~~~~~~~~~~~~~~~~~~~~
+Parameter values enumerated in the environment file are used by SDC as
+the default value. However, the SDC user may use the SDC GUI to
+overwrite the default values in the environment file.
+
+SDC generates a new environment file for distribution to MSO based on
+the uploaded environment file and the user provided GUI updates. The
+user uploaded environment file is discarded when the new file is
+created.
-There is no explicit naming convention for the incremental modules.
-As noted above, <text> represents any alphanumeric string.
+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.
-R-87247 The VNF Heat **MUST NOT** use any special characters or the word “base” in the name of the incremental module.
+ONAP Heat Orchestration Templates: Overview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- <text>.y[a]ml
+ONAP supports a modular Heat Orchestration Template design pattern,
+referred to as *VNF Modularity.*
-R-94509 The VNF Heat **MUST** name the incremental module’s corresponding environment file to be
-identical to the incremental module with “.y[a]ml” replaced with “.env”.
+ONAP VNF Modularity Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To clearly identify the incremental module, it is recommended to use the
-following naming options for modules:
+R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
+Templates, each of which represents a subset of the overall VNF.
-- module\_<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.
-- <text>\_module.y[a]ml
+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).
-- module.y[a]ml
+R-37028 The VNF **MUST** be composed of one “base” module.
-Cinder Volume Modules
-~~~~~~~~~~~~~~~~~~~~~~~
+R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
-R-82732 The VNF Heat **MUST** name the Cinder volume module file name to be the same as the
-corresponding module it is supporting (base module or incremental
-module) with “\_volume” appended.
+R-20974 The VNF **MUST** deploy the base module first, prior to
+the incremental modules.
-- <base module name>\_volume.y[a]ml
+R-28980 A VNF’s incremental module **MAY** be used for initial VNF
+deployment only.
-- <incremental module name>\_volume.y[a]ml
+R-86926 A VNF’s incremental module **MAY** be used for scale out only.
-R-31141 The VNF Heat **MUST** name the volume module’s corresponding environment file
-to be identical to the volume module with “.y[a]ml” replaced with “.env”.
+A VNF’s Incremental Module that is used for scale out is deployed
+sometime after initial VNF deployment to add capacity.
-Nested Heat file
-~~~~~~~~~~~~~~~~~~
+R-91497 A VNF’s incremental module **MAY** be used for both deployment
+and scale out.
-There is no explicit naming convention for nested Heat files with the
-following exceptions; the name should contain “nest”.
+R-68122 A VNF’s incremental module **MAY** be deployed more than once,
+either during initial VNF deployment and/or scale out.
-R-76057 The VNF Heat **MUST NOT** use special characters
-or the word “base” in the file name for the nested template.
+R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
+**MAY** be defined in a Base Module.
-As noted above, <text> represents any alphanumeric string.
+R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in an Incremental Module.
-- <text>.y[a]m
+R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in a Cinder Volume Module.
-Nested Heat files do not have corresponding environment files, per
-OpenStack specifications.
+ONAP also supports the concept of an optional, independently deployed Cinder
+volume via a separate Heat Orchestration Templates, referred to as a Cinder
+Volume Module. This allows the volume to persist after a Virtual Machine
+(VM) (i.e., OS::Nova::Server) is deleted, allowing the volume to be reused
+on another instance (e.g., during a failover activity).
-R-18224 The VNF Heat **MUST** pass in as properties all parameter values associated with the
-nested heat file in the resource
-definition defined in the parent heat template.
+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
-ONAP Parameter Classifications Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+It is strongly recommended that Cinder Volumes be created in a Cinder Volume
+Module.
-In order for ONAP to support workflow automation, Heat Orchestration
-Template resource property parameters must adhere to specific naming
-conventions and requirements.
+R-38474 The VNF **MUST** have a corresponding environment file for a
+Base Module.
-Broadly, ONAP categorizes parameters into four categories:
+R-81725 The VNF **MUST** have a corresponding environment file for an
+Incremental Module.
-1. ONAP metadata parameters
+R-53433 The VNF **MUST** have a corresponding environment file for a
+Cinder Volume Module.
-2. Instance specific parameters
+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.
-3. Constant parameters
+Nested Heat Orchestration Templates Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-4. Output parameters.
+ONAP supports nested Heat Orchestration Templates per OpenStack
+specifications.
-ONAP Metadata Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+R-36582 A VNF’s Base Module **MAY** utilize nested heat.
-There are both mandatory and optional ONAP metadata parameters
-associated with the resource OS::Nova::Server.
+R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
-- ONAP metadata parameters must not have parameter constraints defined.
+R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
-- Both mandatory and optional (if specified) ONAP metadata parameter
- names must follow the ONAP metadata parameter naming convention.
+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).
-`Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
+See `Nested Heat Templates`_ for additional details.
-Instance specific parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ONAP Heat Orchestration Template Filenames
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-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**
+In order to enable ONAP to understand the relationship between Heat
+files, the following Heat file naming convention must be utilized.
-ONAP Orchestration Parameters
-+++++++++++++++++++++++++++++++
+In the examples below, <text> represents any alphanumeric string that
+must not contain any special characters and must not contain the word
+“base”.
-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-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
+be in the lower case format ‘.yaml’ or ‘.yml’.
-- ONAP orchestration parameters must not be enumerated in the
- environment file.
+R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
+**MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
-- When the ONAP orchestration parameter type is set to number, the
- parameter must have constraints for range and/or allowed\_values.
+R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
+**MUST** be in the lower case format ‘.env’.
-- 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.
+Base Modules
+++++++++++++
-- The ONAP orchestration parameter names must follow the ONAP
- orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
- additional details.
+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’.
-VNF Orchestration Parameters
-+++++++++++++++++++++++++++++
+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’.
-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.
+Incremental Modules
++++++++++++++++++++
-- VNF orchestration parameters must not be enumerated in the
- environment file.
+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’.
-- When the VNF orchestration parameter type is set to number, the
- parameter must have constraints for range or allowed\_values.
+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’.
-- 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.
+To clearly identify the incremental module, it is recommended to use the
+following naming options for modules:
-- The VNF orchestration parameter names should follow the VNF
- orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
- additional details.
+ - module_<text>.y[a]ml
-Constant Parameters
-~~~~~~~~~~~~~~~~~~~~~
+ - <text>_module.y[a]ml
+
+ - module.y[a]ml
+
+ - <text>_module_<text>.y[a]ml
-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.**
+Cinder Volume Modules
++++++++++++++++++++++
+
+R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be
+named identical to the base or incremental module it is supporting with
+‘_volume appended’
-ONAP 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’.
+
+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
-~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
The output parameters are parameters defined in the output section of a
Heat Orchestration Template. The ONAP output parameters are subdivided
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.
+++++++++++++++++++++++++++++++++++++
-- ONAP Volume Module Output Parameters are declared in the “outputs:”
- section of the Cinder volume module Heat Orchestration Template
+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.
-- 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.
+A VNF’s Heat Orchestration Template’s Cinder Volume Module Output Parameter(s)
+are only available for the module (base or incremental) that the volume
+template is associated with.
-- R-07443 The VNF Heat **MUST** match the Output parameter name and type with 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 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.
-R-23983 The VNF **MUST** pass the external networks 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.
-R-63345 The VNF Heat **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.
-R-35666 The VNF Heat **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.
-R-86972 The VNF Heat **MUST** create internal networks in the Base
-Module, in the modular approach, 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.
-R-68936 The VNF Heat **SHOULD** assign a unique
-{network-role} in the context of the VNF, when the internal network is
-created. `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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2. Resource Property Parameters
{vm-type}
-^^^^^^^^^^^
+~~~~~~~~~
-R-01455 The VNF Heat **MUST** assign a VNF unique
+R-01455 The VNF Heat Orchestration Template **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-82481 The VNF Heat **MUST** include {vm-type} as part of the parameter name
+R-82481 The VNF Heat Orchestration Template **MUST** include {vm-type} as part of the parameter name
for any parameter that is associated with a unique Virtual Machine type.
-R-66729 The VNF Heat **MUST** include {vm-type} as part of the resource ID
+R-66729 The VNF Heat Orchestration Template **MUST** include {vm-type} as part of the resource ID
for any resource ID that is associated with a unique Virtual Machine type in
the VNF.
“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
ICE Project) process to produce erroneous error messages.
-R-32394 The VNF Heat **MUST** use the same case for {vm-type} for all parameter names in the VNF.
+R-32394 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
+parameter names in the VNF.
-R-46839 The VNF Heat **MUST** use the same case for {vm-type} for all Resource IDs in the VNF.
+R-46839 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
+Resource IDs in the VNF.
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:
-1. R-05008 The VNF Heat **MUST NOT** be prefixed with a common
- {vm-type} identifier for the six ONAP Metadata parameters. 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`_.
+1. R-05008 The VNF Heat Orchestration Template **MUST NOT** be prefixed with a common
+ {vm-type} identifier for the six ONAP Metadata parameters.
+ 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`_.
-2. R-15422 The VNF Heat **MUST NOT** be prefixed with a common {vm-type}
+2. R-15422 The VNF Heat Orchestration Template **MUST NOT** be prefixed with a common {vm-type}
identifier the parameter referring to the OS::Nova::Server property
availability\_zone . availability\_zone is described in `Property: availability_zone`_.
{network-role}
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~
The assignment of a {network-role} is discussed in `Networking`_.
-R-21330 The VNF Heat **MUST** include
-the {network-role} as part of the parameter name for any parameter that is associated with an external network.
+R-21330 The VNF Heat Orchestration Template **MUST** include the {network-role} as part of the
+parameter name for any parameter that is associated with an external network.
-R-11168 The VNF Heat **MUST** include
-the {network-role} as part of the resource ID for any resource ID that is associated with an external network must.
+R-11168 The VNF Heat Orchestration Template **MUST** include the {network-role} as part of the
+resource ID for any resource ID that is associated with an external network
+must.
-R-84322 The VNF Heat **MUST** include
-int\_{network-role} as part of the parameter name for any parameter that is associated with an internal network.
+R-84322 The VNF Heat Orchestration Template **MUST** include int\_{network-role} as part of the
+parameter name for any parameter that is associated with an internal network.
-R-96983 The VNF Heat **MUST** include
-int\_{network-role} as part of the resource ID for any resource ID that is associated with an internal network.
+R-96983 The VNF Heat Orchestration Template **MUST** include int\_{network-role} as part of the
+resource ID for any resource ID that is associated with an internal network.
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,
“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
ICE Project) process to produce erroneous error messages.
-R-58424 The VNF Heat **MUST** use the same case for {network-role} for all parameter names in the
-VNF.
+R-58424 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
+all parameter names in the VNF.
-R-21511 The VNF Heat **MUST** use the same case for {network-role} for all Resource IDs in the VNF.
+R-21511 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
+all Resource IDs in the VNF.
It is recommended that the {network-role} case in the parameter names
matches the {network-role} case in the Resource IDs.
Resource IDs
-^^^^^^^^^^^^^
+~~~~~~~~~~~~
Heat Orchestration Template resources are described in `resources`_
-R-59629 The VNF Heat **MUST** have unique resource IDs within the resources section of a Heat
-Orchestration Template. This is an OpenStack Requirement.
+R-59629 The VNF Heat Orchestration Template **MUST** have unique resource IDs within the
+resources section of a Heat Orchestration Template. This is an
+OpenStack Requirement.
-R-43319 The VNF Heat **MUST** have unique resource IDs
+R-43319 The VNF Heat Orchestration Template **MUST** have unique resource IDs
across all modules that compose the VNF,
when a VNF is composed of more than one Heat Orchestration Template
(i.e., modules).
-R-54517 The VNF Heat **MUST** include {vm-type} in the resource ID
+R-54517 The VNF Heat Orchestration Template **MUST** include {vm-type} in the resource ID
when a resource is associated with a single {vm-type}.
-R-96482 The VNF Heat **MUST** include {network-role} in the resource ID
+R-96482 The VNF Heat Orchestration Template **MUST** include {network-role} in the resource ID
when a resource is associated with a single external network.
-R-98138 The VNF Heat **MUST** include int\_{network-role} in the resource ID
+R-98138 The VNF Heat Orchestration Template **MUST** include int\_{network-role} in the resource ID
when a resource is associated with a single internal network.
-R-82115 The VNF Heat **MUST** include both the {vm-type} and
+R-82115 The VNF Heat Orchestration Template **MUST** include both the {vm-type} and
{network-role} in the resource ID,
when a resource is associated with a single {vm-type} and a single
external network.
{network-role}. An underscore will separate the three values (i.e.,
{vm-type}\_{index}\_{network-role}).
-R-82551 The VNF Heat **MUST** include both the {vm-type} and
+R-82551 The VNF Heat Orchestration Template **MUST** include both the {vm-type} and
int\_{network-role} in the resource ID,
when a resource is associated with a single {vm-type} and a single
internal network.
- should contain the term “shared” and/or contain text that identifies
the VNF.
-R-69287 The VNF Heat **MUST** use only alphanumeric characters and “\_” underscores in the
-resource ID. Special characters must not be used.
+R-69287 The VNF Heat Orchestration Template **MUST** use only alphanumeric characters and “\_”
+underscores in the resource ID. Special characters must not be used.
All {index} values must be zero based. That is, 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 |
-+--------------------------------+------------------------------------------------------------+
++-----------------------------+--------------------------------------+
+| 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 |
-+-------------------------------------------+---------------------------------------------+
++-------------------------------------------+---------------------------------+
+| 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
Resource: OS::Nova::Server - Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The resource OS::Nova::Server manages the running virtual machine (VM)
instance within an OpenStack cloud. (See
Note that the {vm\_type} must be identical across all four property
parameters 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 |
-+-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
++----------------------------------------------------------------------------+
+| Resource OS::Nova::Server |
++--------------+----------------+----------+----------------+----------------+
+| Property Name| ONAP Parameter | Parameter| Parameter Value| ONAP Parameter |
+| | Name | Type | Generation | Classification |
++==============+================+==========+================+================+
+| image | {vm-type}\ | string | Environment | ONAP |
+| | _image\_name | string | File | Constant |
++--------------+----------------+----------+----------------+----------------+
+| flavor | {vm-type}\ | string | Environment | ONAP |
+| | _flavor\_name | | File | Constant |
++--------------+----------------+----------+----------------+----------------+
+| name | {vm-type}\ | string | ONAP | ONAP |
+| | _name\_{index} | | | Orchestration |
++--------------+----------------+----------+----------------+----------------+
+| | {vm-type}\ | CDL | ONAP | ONAP |
+| | _names | | | Orchestration |
++--------------+----------------+----------+----------------+----------------+
+| availability\| availability\ | string | ONAP | ONAP |
+| _zone | _zone\_{index} | | | Orchestration |
++--------------+----------------+----------+----------------+----------------+
Table 3 Resource Property Parameter Names
Property: image
-~~~~~~~~~~~~~~~~~
++++++++++++++++
The parameter associated with the property image is an ONAP Constant
parameter.
The parameters must be named {vm-type}\_image\_name in the Heat
Orchestration Template.
-R-71152 The VNF Heat **MUST** declare as type: string the parameter for property image.
+R-71152 The VNF Heat Orchestration Template **MUST** declare as type: string the parameter
+for property image.
-R-91125 The VNF Heat **MUST** enumerate the parameter for property image in the Heat Orchestration Template
-environment file.
+R-91125 The VNF Heat Orchestration Template **MUST** enumerate the parameter for property
+image in the Heat Orchestration Template environment file.
-R-57282 The VNF Heat **MUST** have a separate parameter for image for
-Each VM type (i.e., {vm-type})
-even if more than one {vm-type} shares the same image. This provides
-maximum clarity and flexibility.
+R-57282 The VNF Heat Orchestration Template **MUST** have a separate parameter for image for
+Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares
+the same image. This provides maximum clarity and flexibility.
*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 Heat **MUST** declare the parameter property for flavor as type: string.
+R-50436 The VNF Heat Orchestration Template **MUST** declare the parameter property for
+flavor as type: string.
-R-69431 The VNF Heat **MUST** enumerate the parameter for property flavor in the Heat Orchestration Template
-environment file.
+R-69431 The VNF Heat Orchestration Template **MUST** enumerate the parameter for property
+flavor in the Heat Orchestration Template environment file.
-R-40499 The VNF Heat **MUST** have a separate parameter for flavor for each VM type
-(i.e., {vm-type}) even if more than one {vm-type} shares the same flavor. This
-provides maximum clarity and flexibility.
+R-40499 The VNF Heat Orchestration Template **MUST** have a separate parameter for flavor for each
+VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same
+flavor. This provides maximum clarity and flexibility.
*Example Parameter Definition*
description: {vm-type} flavor
Property: Name
-~~~~~~~~~~~~~~~~
+++++++++++++++
The parameter associated with the property name is an ONAP Orchestration
parameter.
The parameter value is provided to the Heat template by ONAP.
-R-22838 The VNF Heat **MUST NOT** enumerate the parameter for property name
+R-22838 The VNF Heat Orchestration Template **MUST NOT** enumerate the parameter for property name
in the environment file.
-R-51430 The VNF Heat **MUST** declare the parameter for property name as type: string or type:
-comma\_delimited\_list
+R-51430 The VNF Heat Orchestration Template **MUST** declare the parameter for property name as
+type: string or type: comma\_delimited\_list
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
...
Contrail Issue with Values for OS::Nova::Server Property Name
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+_____________________________________________________________
The Contrail GUI has a limitation displaying special characters. The
issue is documented in
- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
Property: availability\_zone
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++
The parameter associated with the property availability\_zone is an ONAP
Orchestration parameter.
The parameter value is provided to the Heat template by ONAP. The
parameter must not be enumerated in the environment file.
-R-98450 The VNF Heat **MUST** name the parameter availability\_zone\_{index} in the Heat
-Orchestration Template.
+R-98450 The VNF Heat Orchestration Template **MUST** name the parameter availability\_zone\_{index}
+in the Heat Orchestration Template.
-R-13561 The VNF Heat **MUST** start the {index} at zero.
+R-13561 The VNF Heat Orchestration Template **MUST** start the {index} at zero.
-R-60204 The VNF Heat **MUST** increment the {index} by one.
+R-60204 The VNF Heat Orchestration Template **MUST** increment the {index} by one.
-R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name.
+R-36887 The VNF Heat Orchestration Template **MUST NOT** include the {vm-type} in the parameter name.
The parameter must be declared as type: string
The parameter must not be declared as type: comma\_delimited\_list
Example
-~~~~~~~~~
+_______
The example below depicts part of a Heat Orchestration Template that
uses the four OS::Nova::Server properties discussed in this section.
. . .
Resource: OS::Nova::Server – Metadata Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
-R-17020 The VNF Heat **MUST** include the following three mandatory metadata parameters for an
-OS::Nova::Server resource:
+R-17020 The VNF Heat Orchestration Template **MUST** include the following three mandatory
+metadata parameters for an OS::Nova::Server resource:
- vnf\_id
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
++-------------------+----------+-------------------+----------------+
+| Metadata Parameter| Parameter| Mandatory/Optional| Parameter Value|
+| Name | Type | | 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
-~~~~~~~~~
++++++++
The vnf\_id parameter is mandatory; it must be included in the Heat
Orchestration Template.
The parameter must be declared as type: string
-R-55218 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_id.
+R-55218 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
+for the OS::Nova::Server metadata parameter vnf\_id.
-R-20856 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_id in environment file.
+R-20856 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
+metadata parameter vnf\_id in environment file.
*Example Parameter Definition*
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 parameter must be declared as type: string
-R-98374 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vf\_module\_id.
+R-98374 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints
+defined for the OS::Nova::Server metadata parameter vf\_module\_id.
-R-72871 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vf\_module\_id in environment file.
+R-72871 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
+metadata parameter vf\_module\_id in environment file.
*Example Parameter Definition*
description: Unique ID for this VNF module instance
vnf\_name
-~~~~~~~~~~~
++++++++++
The vnf\_name parameter is mandatory; it must be included in the Heat
Orchestration Template.
The parameter must be declared as type: string
-R-44318 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_name.
+R-44318 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
+for the OS::Nova::Server metadata parameter vnf\_name.
-R-36542 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_name in the environment file.
+R-36542 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
+metadata parameter vnf\_name in the environment file.
*Example Parameter Definition*
description: Unique name for this VNF instance
vf\_module\_name
-~~~~~~~~~~~~~~~~~~
+++++++++++++++++
The vf\_module\_name parameter is optional; it may be included in the
Heat Orchestration Template.
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.
vm_role: { get_param: vm_role }
Example
-~~~~~~~~~
++++++++
The example below depicts part of a Heat Orchestration Template that
uses the five of the OS::Nova::Server metadata parameter discussed in
vm_role: lb
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:
networks are defined in `Networking`_.
External Networks
-++++++++++++++++++
+_________________
When the parameter references an external network
-- R-72050 The VNF Heat **MUST** contain {network-role} in the parameter name
+- R-72050 The VNF Heat Orchestration Template **MUST** contain {network-role} in the parameter name
- 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 |
-+----------------------------------------+-----------------------------------------------+--------------------------+
++----------------------+---------------------------+--------------------------+
+| Property Name | ONAP Parameter Name | Parameter Type |
++======================+===========================+==========================+
+| network | {network-role}\_net\_id | string |
+| +---------------------------+--------------------------+
+| | {network-role}\_net\_name | string |
++----------------------+---------------------------+--------------------------+
+| fixed\_ips, | {vm-type}\_{network-role}\| string |
+| ip\_address | _ip\_{index} | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| comma\_delimited\_list |
+| | _ips | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| string |
+| | _v6\_ip\_{index} | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| comma\_delimited\_list |
+| | _v6\_ips | |
++----------------------+---------------------------+--------------------------+
+| fixed\_ips, subnet | {network-role}\ | string |
+| | _subnet\_id | |
+| +---------------------------+--------------------------+
+| | {network-role}\ | string |
+| | _v6\_subnet\_id | |
++----------------------+---------------------------+--------------------------+
+| allowed\_address | {vm-type}\_{network-role}\| string |
+| \_pairs, ip\_address | _floating\_ip | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| string |
+| | _floating\_v6\_ip | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| string |
+| | _ip\_{index} | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| comma\_delimited\_list |
+| | _ips | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| string |
+| | _v6\_ip\_{index} | |
+| +---------------------------+--------------------------+
+| | {vm-type}\_{network-role}\| comma\_delimited\_list |
+| | _v6\_ips | |
++----------------------+---------------------------+--------------------------+
Table 5: OS::Neutron::Port Resource Property Parameters (External
Networks)
Internal Networks
-+++++++++++++++++++
+_________________
When the parameter references an internal network
-- R-57576 The VNF Heat **MUST** contain int\_{network-role} in the parameter name.
+- R-57576 The VNF Heat Orchestration Template **MUST** contain int\_{network-role}
+ in the parameter name.
- 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 |
-+----------------------------------------+----------------------------------------------------+--------------------------+
++-------------------------+--------------------------------+-----------------+
+| Property | Parameter Name for | Parameter Type |
+| | Internal Networks | |
++=========================+================================+=================+
+| network | int\_{network-role}\ | string |
+| | _net\_id | |
+| +--------------------------------+-----------------+
+| | int\_{network-role}\ | string |
+| | _net\_name | |
++-------------------------+--------------------------------+-----------------+
+| fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\| string |
+| | _ip\_{index} | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| comma\ |
+| | _ips | _delimited\_list|
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| string |
+| | _v6\_ip\_{index} | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| comma\ |
+| | _v6\_ips | _delimited\_list|
++-------------------------+--------------------------------+-----------------+
+| fixed\_ips, subnet | int\_{network-role}\ | string |
+| | _subnet\_id | |
+| +--------------------------------+-----------------+
+| | int\_{network-role}\ | string |
+| | _v6\_subnet\_id | |
++-------------------------+--------------------------------+-----------------+
+| allowed\_address\_pairs,| {vm-type}\_int\_{network-role}\| string |
+| ip\_address | _floating\_ip | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| string |
+| | _floating\_v6\_ip | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| string |
+| | _ip\_{index} | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| comma\ |
+| | _ips | _delimited\_list|
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| string |
+| | _v6\_ip\_{index} | |
+| +--------------------------------+-----------------+
+| | {vm-type}\_int\_{network-role}\| comma\ |
+| | _v6\_ips | _delimited\_list|
++-------------------------+--------------------------------+-----------------+
Table 6: Port Resource Property Parameters (Internal Networks)
Property: network
-~~~~~~~~~~~~~~~~~~~
++++++++++++++++++
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.
External Networks
-++++++++++++++++++
+_________________
-R-93272 The VNF Heat **MUST** adhere to the following parameter naming
-convention in the Heat Orchestration Template, when the parameter associated with the property network is referencing
-an “external” network:
+R-93272 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
+convention in the Heat Orchestration Template, when the parameter
+associated with the property network is referencing an “external” network:
- {network-role}\_net\_id for the Neutron network ID
network: { get_param: oam_net_id }
Internal Networks
-++++++++++++++++++
+_________________
-R-65373 The VNF Heat **MUST** adhere to the following parameter naming
-convention, when the parameter associated with the property network is referencing
-an “internal” network:
+R-65373 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
+convention, when the parameter associated with the property network is
+referencing an “internal” network:
- int\_{network-role}\_net\_id for the Neutron network ID
description: Neutron name for the {network-role} network
Property: fixed\_ips, Map Property: subnet\_id
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++++++++++++++++++++
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.
assigned IP addresses.
Subnet of an External Networks
-+++++++++++++++++++++++++++++++
+______________________________
-R-47716 The VNF Heat **MUST** adhere to the following parameter naming convention
-for the property fixed\_ips and Map Property subnet\_id parameter,
-when the parameter is referencing a subnet of an “external” network.
+R-47716 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
+convention for the property fixed\_ips and Map Property subnet\_id
+parameter, when the parameter is referencing a subnet of an
+“external” network.
- {network-role}\_subnet\_id if the subnet is an IPv4 subnet
- subnet_id: { get_param: oam_v6_subnet_id }
Internal Networks
-++++++++++++++++++
+_________________
-R-20106 The VNF Heat **MUST** adhere to the following naming convention for
+R-20106 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention for
the property fixed\_ips and Map Property subnet\_id parameter,
when the parameter is referencing the subnet of an “internal” network:
description: Neutron subnet UUID for the {network-role} network
Property: fixed\_ips, Map Property: ip\_address
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++++++++++++++++++++++++
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
that is connected to an external network (referenced by {network-role})
or internal network (referenced by int\_{network-role}).
-R-41177 The VNF Heat **MUST** include {vm-type} and {network-role} in the parameter name,
-when a SDN-C IP assignment is made to a port connected to an external network.
+R-41177 The VNF Heat Orchestration Template **MUST** include {vm-type} and {network-role}
+in the parameter name, when a SDN-C IP assignment is made to a
+port connected to an external 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}.
IP Address Assignments on External Networks
-++++++++++++++++++++++++++++++++++++++++++++
+___________________________________________
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-84898 The VNF Heat **MUST** adhere to the following naming convention,
+R-84898 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention,
when the parameter for property fixed\_ips and Map Property ip\_address
is declared type: comma\_delimited\_list:
- “ip_address”: {get_param: [ db_oam_ips, 1 ]}
- “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
-R-34960 The VNF Heat **MUST** adhere to the following
+R-34960 The VNF Heat Orchestration Template **MUST** adhere to the following
naming convention,
when the parameter for property fixed\_ips and Map Property ip\_address
is declared type: string:
type: string
description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
-*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
- “ip_address”: {get_param: db_oam_v6_ip_1}}]
IP Address Assignment on Internal Networks
-++++++++++++++++++++++++++++++++++++++++++++
+__________________________________________
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).
-R-62584 The VNF Heat **MUST** adhere to
+R-62584 The VNF Heat Orchestration Template **MUST** adhere to
the following naming convention,
when the parameter for property fixed\_ips and Map Property ip\_address
is declared type: comma\_delimited\_list:
- “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
- “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
-R-29256 The VNF Heat **MUST** must adhere to the following
+R-29256 The VNF Heat Orchestration Template **MUST** must adhere to the following
naming convention,
when the parameter for property fixed\_ips and Map Property ip\_address
is declared type: string:
type: string
description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
-*Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
+*Example: string parameters for IPv4 and IPv6 Address Assignments
+to an internal 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
- “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
-++++++++++++++++++
+_________________
-R-61282 The VNF Heat **MUST**
+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:
allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
Internal Networks
-+++++++++++++++++++
+_________________
-R-16805 The VNF Heat **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.
+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.
-R-85734 The VNF Heat **MUST** use the intrinsic function str\_replace
+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
. . . .
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
be embedded within the Base Module or Incremental Module if persistence
is not required.
-R-47788 The VNF Heat **MUST** have a 1:1 scope of a cinder volume module,
+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
- A single Cinder volume module must include all Cinder volumes
needed by the Base/Incremental module.
-- R-79531 The VNF Heat **MUST** define “outputs” in the volume template 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
The use of an environment file in OpenStack is optional. In ONAP, it is
mandatory.
-R-86285 The VNF Heat **MUST** have a
+R-86285 The VNF Heat Orchestration Template **MUST** have a
corresponding environment file, even if no parameters are required to be
enumerated.
(Note that ONAP, the open source version of ONAP, does not
programmatically enforce the use of an environment file.)
-R-67205 The VNF Heat **MUST** have a corresponding
+R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
environment file for a Base Module.
-R-35727 The VNF Heat **MUST** have a
+R-35727 The VNF Heat Orchestration Template **MUST** have a
corresponding environment file for an Incremental module.
-R-22656 The VNF Heat **MUST** have a corresponding environment file for a Cinder Volume Module.
+R-22656 The VNF Heat Orchestration Template **MUST** have a corresponding environment file
+for a Cinder Volume Module.
A nested heat template must not have an environment file; OpenStack does
not support it.
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
^^^^^^^^^^^^^^^^^^^^^^^^^
Nested Heat Templates
-~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
ONAP supports nested Heat templates per the OpenStack specifications.
Nested templates may be suitable for larger VNFs that contain many
resource OS::Heat::ResourceGroup.
Nested Heat Template Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ONAP supports nested Heat Orchestration Templates. A Base Module,
Incremental Module, and Cinder Volume Module may use nested heat.
resource\_registry in the environment file is not supported and must not
be used.
-R-89868 The VNF Heat **MUST** have unique file names within the scope
+R-89868 The VNF Heat Orchestration Template **MUST** have unique file names within the scope
of the VNF for a nested heat yaml file.
-R-52530 The VNF Heat **MUST NOT** use 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.
-- R-11041 The VNF Heat **MUST** have the resource calling the nested yaml file pass
- in as properties all parameters defined in 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.
-- R-61183 The VNF Heat **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
+- 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
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.
{ 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:
-R-76718 The VNF Heat **MUST** reference the get\_files targets in Heat templates by file
-name, and the corresponding files should be delivered to ONAP along
-with the Heat templates.
+R-76718 The VNF Heat Orchestration Template **MUST** reference the get\_files targets in
+Heat templates by file name, and the corresponding files should be
+delivered to ONAP along with the Heat templates.
R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
-R-62177 The VNF Heat **MUST** have unique file names for the included
+R-62177 The VNF Heat Orchestration Template **MUST** have unique file names for the included
files within the scope of the VNF.
-R-87848 The VNF Heat **MUST** have all included files in a single, flat
+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
2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
is a microservice providing a translation interface from VF-C to
-the vendor-specific VNFM. The interface definitions of vendor-specific VNFM adaptors are supplied by
-the VNF Providers themselves.
+the vendor-specific VNFM. The interface definitions of vendor-specific
+VNFM adaptors are supplied by the VNF Providers themselves.
Creating Vendor-Specific VNFM Adaptor Microservices
------------------------------------------------------------------------------------------------
-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.
+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 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:
+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