.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-**VNF Modeling Requirements**
-=====================================
+VNF Modeling Requirements
+=========================
TOSCA YAML
---------------------------
+----------
Introduction
The following table defines the TOSCA Type “derived from” values that
SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
-specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
+specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD with aggreed
+changes from ETSI SOL001 draft.
+---------------------+------------------------------------+-----------------+
| **ETSI NFV Element**| **TOSCA VNFD** | **Derived from**|
+=====================+====================================+=================+
| VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root|
+---------------------+------------------------------------+-----------------+
-| VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root|
+| Cpd (Connection | tosca.nodes.nfv.Cp | tosca.nodes.Root|
+| Point) | tosca.nodes.nfv.Cp | 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.VduCp | tosca.nodes.\ |
+| connection point) | | nfv.Cp |
+---------------------+------------------------------------+-----------------+
-| VduCpd (internal | tosca.nodes.nfv.VduCpd | tosca.nodes.\ |
-| connection point) | | nfv.Cpd |
-+---------------------+------------------------------------+-----------------+
-| VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root|
+| VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLink | tosca.nodes.Root|
| (Virtual Link) | | |
+---------------------+------------------------------------+-----------------+
-| VnfExtCpd (External | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root|
-| Connection Point) | | |
-+---------------------+------------------------------------+-----------------+
-| Virtual Storage | | |
+| VDU Virtual Storage | tosca.nodes.nfv.VDU.VirtualStorage | tosca.nodes.Root|
+---------------------+------------------------------------+-----------------+
-| Virtual Compute | | |
+| VDU Virtual Compute | tosca.nodes.nfv.VDU.Compute | tosca.nodes.Root|
+---------------------+------------------------------------+-----------------+
| Software Image | | |
+---------------------+------------------------------------+-----------------+
tosca.capabilites.nfv.VirtualCompute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+---------------------------+-----------------------------------------+
-| **Shorthand Name** | VirtualCompute |
-+===========================+=========================================+
-| **Type Qualified Name** | tosca: VirtualCompute |
-+---------------------------+-----------------------------------------+
-| **Type URI** | tosca.capabilities.nfv.VirtualCompute |
-+---------------------------+-----------------------------------------+
-| **derived from** | tosca.nodes.Root |
-+---------------------------+-----------------------------------------+
-
-Properties
-+++++++++++
-
-+---------------+---------+---------------+------------+----------------------+
-| Name | Required| Type | Constraints| Description |
-+===============+=========+===============+============+======================+
-| request\ | 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
-+++++++++++
-
-+-----------------------------------------------------------+
-| tosca.capabilities.nfv.VirtualCompute: |
-| |
-| derived\_from: tosca.capabilities.Root |
-| |
-| properties: |
-| |
-| requested\_additional\_capabilities: |
-| |
-| type: map |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatypes.nfv.RequestedAdditionalCapability |
-| |
-| required: false |
-| |
-| virtual\_memory: |
-| |
-| type: tosca.datatypes.nfv.VirtualMemory |
-| |
-| required: true |
-| |
-| virtual\_cpu: |
-| |
-| type: tosca.datatypes.nfv.VirtualCpu |
-| |
-| required: true |
-+-----------------------------------------------------------+
+This capability is used with the properties specified in ETSI SOL001 draft.
tosca.nodes.nfv.VDU.Compute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Artifact
++++++++++
+Note: currently not supported.
+
+--------+---------+----------------+------------+------------------------+
| Name | Required| Type | Constraints| Description |
+========+=========+================+============+========================+
-tosca.nodes.nfv.Cpd
-~~~~~~~~~~~~~~~~~~~~~
-
-The TOSCA Cpd node represents network connectivity to a compute resource
-or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
-used as parent for the various Cpd types.
-
-+-----------------------+-----------------------+
-| Shorthand Name | Cpd |
-+=======================+=======================+
-| Type Qualified Name | tosca:Cpd |
-+-----------------------+-----------------------+
-| Type URI | tosca.nodes.nfv.Cpd |
-+-----------------------+-----------------------+
-
-
-Attributes
-+++++++++++
-
-+--------+------------+--------+---------------+---------------+
-| Name | Required | Type | Constraints | Description |
-+========+============+========+===============+===============+
-+--------+------------+--------+---------------+---------------+
-
-Requirements
-+++++++++++++
-
-None
-
-Capabilities
-+++++++++++++
-
-None
-
-Definition
-+++++++++++
-
-+----------------------------------------------------------------------+
-| tosca.nodes.nfv.Cpd: |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| layer\_protocol: |
-| |
-| type:string |
-| |
-| constraints: |
-| |
-| - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
-| |
-| required:true |
-| |
-| role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
-| |
-| type:string |
-| |
-| constraints: |
-| |
-| - valid\_values: [ root, leaf ] |
-| |
-| required:flase |
-| |
-| description: |
-| |
-| type: string |
-| |
-| required: false |
-| |
-| address\_data: |
-| |
-| type: list |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatype.nfv.AddressData |
-| |
-| required:false |
-+----------------------------------------------------------------------+
-
-Additional Requirement
-+++++++++++++++++++++++
-
-None.
-
-tosca.nodes.nfv.VduCpd
-~~~~~~~~~~~~~~~~~~~~~~~
-
-The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
-network connectivity between a VNFC instance (based on this VDU) and an
-internal VL as defined by [ETSI GS NFV-IFA 011].
-
-+-----------------------+--------------------------+
-| Shorthand Name | VduCpd |
-+=======================+==========================+
-| Type Qualified Name | tosca: VduCpd |
-+-----------------------+--------------------------+
-| Type URI | tosca.nodes.nfv.VduCpd |
-+-----------------------+--------------------------+
-
-Properties
-+++++++++++
-
-
-+-----------------+---------+---------------+------------+--------------------+
-| Name | Required| Type | Constraints| Description |
-+=================+=========+===============+============+====================+
-| bitrate\ | 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
-+++++++++++
-
-None
-
-Requirements
-+++++++++++++
-
-+----------+---------+--------------------+------------+----------------------+
-| 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
-+++++++++++
-
-+----------------------------------------------------------------+
-| tosca.nodes.nfv.VduCpd: |
-| |
-| derived\_from: tosca.nodes.nfv.Cpd |
-| |
-| properties: |
-| |
-| bitrate\_requirement: |
-| |
-| type: integer |
-| |
-| required:false |
-| |
-| virtual\_network\_interface\_requirements |
-| |
-| type: list |
-| |
-| entry\_schema: |
-| |
-| type: VirtualNetworkInterfaceRequirements |
-| |
-| required:false |
-| |
-| requirements: |
-| |
-| - virtual\_link: |
-| |
-| capability: tosca.capabilities.nfv.VirtualLinkable |
-| |
-| relationship: tosca.relationships.nfv.VirtualLinksTo |
-| |
-| node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| relationship: tosca.relationships.nfv.VirtualBindsTo |
-| |
-| node: tosca.nodes.nfv.VDU |
-+----------------------------------------------------------------+
-
tosca.nodes.nfv.VDU.VirtualStorage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| required: false |
+-----------------------------------------------------+
-vNAT Example
-^^^^^^^^^^^^^
-
-openovnf\_\_vOpenNAT.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+-------------------------------------------------------------+
-| imports: |
-| |
-| - openonfv\_\_tosca.capabilities.Scalable.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Attachment.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
-| |
-| - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Container.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
-| |
-| - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
-| |
-| - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
-| |
-| - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
-| |
-| metadata: |
-| |
-| vnfProductName: openNAT |
-| |
-| vnfdVersion: 1.0.0 |
-| |
-| vnfProvider: intel |
-| |
-| vnfmInfo: GVNFM |
-| |
-| csarVersion: 1.0.0 |
-| |
-| vnfdId: openNAT-1.0 |
-| |
-| csarProvider: intel |
-| |
-| vnfProductInfoDescription: openNAT |
-| |
-| version: 1.0.0 |
-| |
-| csarType: NFAR |
-| |
-| vendor: intel |
-| |
-| localizationLanguage: '[english, chinese]' |
-| |
-| id: openNAT-1.0 |
-| |
-| defaultLocalizationLanguage: english |
-| |
-| vnfProductInfoName: openNAT |
-| |
-| vnfSoftwareVersion: 1.0.0 |
-| |
-| topology\_template: |
-| |
-| node\_templates: |
-| |
-| vdu\_vNat: |
-| |
-| artifacts: |
-| |
-| vNatVNFImage: |
-| |
-| file: /swimages/xenial-snat.qcow2 |
-| |
-| type: tosca.artifacts.nfv.SwImage |
-| |
-| properties: |
-| |
-| name: vNatVNFImage |
-| |
-| version: "1.0" |
-| |
-| checksum: "5000" |
-| |
-| container\_format: bare |
-| |
-| disk\_format: qcow2 |
-| |
-| min\_disk: 10 GB |
-| |
-| min\_ram: 1 GB |
-| |
-| size: 10 GB |
-| |
-| sw\_image: /swimages/xenial-snat.qcow2 |
-| |
-| operating\_system: unbantu |
-| |
-| attributes: |
-| |
-| tosca\_name: vdu\_vNat |
-| |
-| capabilities: |
-| |
-| virtual\_compute: |
-| |
-| properties: |
-| |
-| virtual\_memory: |
-| |
-| numa\_enabled: true |
-| |
-| virtual\_mem\_size: 2 GB |
-| |
-| requested\_additional\_capabilities: |
-| |
-| numa: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: numa |
-| |
-| target\_performance\_parameters: |
-| |
-| hw:numa\_nodes: "2" |
-| |
-| hw:numa\_cpus.0: "0,1" |
-| |
-| hw:numa\_mem.0: "1024" |
-| |
-| hw:numa\_cpus.1: "2,3,4,5" |
-| |
-| hw:numa\_mem.1: "1024" |
-| |
-| hyper\_threading: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: hyper\_threading |
-| |
-| target\_performance\_parameters: |
-| |
-| hw:cpu\_sockets : "2" |
-| |
-| hw:cpu\_threads : "2" |
-| |
-| hw:cpu\_cores : "2" |
-| |
-| hw:cpu\_threads\_policy: "isolate" |
-| |
-| ovs\_dpdk: |
-| |
-| support\_mandatory: true |
-| |
-| requested\_additional\_capability\_name: ovs\_dpdk |
-| |
-| target\_performance\_parameters: |
-| |
-| sw:ovs\_dpdk: "true" |
-| |
-| virtual\_cpu: |
-| |
-| cpu\_architecture: X86 |
-| |
-| num\_virtual\_cpu: 2 |
-| |
-| properties: |
-| |
-| configurable\_properties: |
-| |
-| test: |
-| |
-| additional\_vnfc\_configurable\_properties: |
-| |
-| aaa: 1 |
-| |
-| name: vNat |
-| |
-| descrption: the virtual machine of vNat |
-| |
-| boot\_order: |
-| |
-| - vNAT\_Storage |
-| |
-| requirements: |
-| |
-| - virtual\_storage: |
-| |
-| capability: virtual\_storage |
-| |
-| node: vNAT\_Storage |
-| |
-| relationship: |
-| |
-| properties: |
-| |
-| location: /mnt/volume\_0 |
-| |
-| type: tosca.relationships.nfv.VDU.AttachedTo |
-| |
-| - local\_storage: |
-| |
-| node: tosca.nodes.Root |
-| |
-| type: tosca.nodes.nfv.VDU.Compute |
-| |
-| SRIOV\_Port: |
-| |
-| attributes: |
-| |
-| tosca\_name: SRIOV\_Port |
-| |
-| properties: |
-| |
-| virtual\_network\_interface\_requirements: |
-| |
-| - name: sriov |
-| |
-| support\_mandatory: false |
-| |
-| description: sriov |
-| |
-| requirement: |
-| |
-| SRIOV: true |
-| |
-| role: root |
-| |
-| description: sriov port |
-| |
-| layer\_protocol: ipv4 |
-| |
-| requirements: |
-| |
-| - virtual\_binding: |
-| |
-| capability: virtual\_binding |
-| |
-| node: vdu\_vNat |
-| |
-| relationship: |
-| |
-| type: tosca.relationships.nfv.VirtualBindsTo |
-| |
-| - virtual\_link: |
-| |
-| node: tosca.nodes.Root |
-| |
-| type: tosca.nodes.nfv.VduCpd |
-| |
-| vNAT\_Storage: |
-| |
-| attributes: |
-| |
-| tosca\_name: vNAT\_Storage |
-| |
-| properties: |
-| |
-| id: vNAT\_Storage |
-| |
-| size\_of\_storage: 10 GB |
-| |
-| rdma\_enabled: false |
-| |
-| type\_of\_storage: volume |
-| |
-| type: tosca.nodes.nfv.VDU.VirtualStorage |
-| |
-| substitution\_mappings: |
-| |
-| requirements: |
-| |
-| sriov\_plane: |
-| |
-| - SRIOV\_Port |
-| |
-| - virtual\_link |
-| |
-| node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+-------------------------------------------------------------+
-
-openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+------------------------------------------------------------+
-| imports: |
-| |
-| - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
-| |
-| node\_types: |
-| |
-| tosca.nodes.nfv.VDU.VirtualStorage: |
-| |
-| capabilities: |
-| |
-| virtual\_storage: |
-| |
-| type: tosca.capabilities.nfv.VirtualStorage |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| id: |
-| |
-| type: string |
-| |
-| size\_of\_storage: |
-| |
-| type: string |
-| |
-| rdma\_enabled: |
-| |
-| required: false |
-| |
-| type: boolean |
-| |
-| type\_of\_storage: |
-| |
-| type: string |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+------------------------------------------------------------+
-
-openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-+-----------------------------------------------------------------+
-| data\_types: |
-| |
-| tosca.datatypes.nfv.L3AddressData: |
-| |
-| properties: |
-| |
-| number\_of\_ip\_address: |
-| |
-| required: false |
-| |
-| type: integer |
-| |
-| ip\_address\_assignment: |
-| |
-| type: boolean |
-| |
-| ip\_address\_type: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - ipv4 |
-| |
-| - ipv6 |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| floating\_ip\_activated: |
-| |
-| type: string |
-| |
-| tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
-| |
-| properties: |
-| |
-| name: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| support\_mandatory: |
-| |
-| type: boolean |
-| |
-| description: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| requirement: |
-| |
-| entry\_schema: |
-| |
-| type: string |
-| |
-| type: map |
-| |
-| tosca.datatype.nfv.AddressData: |
-| |
-| properties: |
-| |
-| address\_type: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - mac\_address |
-| |
-| - ip\_address |
-| |
-| type: string |
-| |
-| l2\_address\_data: |
-| |
-| required: false |
-| |
-| type: tosca.datatypes.nfv.L2AddressData |
-| |
-| l3\_address\_data: |
-| |
-| required: false |
-| |
-| type: tosca.datatypes.nfv.L3AddressData |
-| |
-| tosca.datatypes.nfv.L2AddressData: {} |
-| |
-| imports: |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
-| |
-| node\_types: |
-| |
-| tosca.nodes.nfv.VduCpd: |
-| |
-| derived\_from: tosca.nodes.Root |
-| |
-| properties: |
-| |
-| virtual\_network\_interface\_requirements: |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
-| |
-| required: false |
-| |
-| type: list |
-| |
-| role: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - root |
-| |
-| - leaf |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| bitrate\_requirement: |
-| |
-| required: false |
-| |
-| type: integer |
-| |
-| description: |
-| |
-| required: false |
-| |
-| type: string |
-| |
-| layer\_protocol: |
-| |
-| constraints: |
-| |
-| - valid\_values: |
-| |
-| - ethernet |
-| |
-| - mpls |
-| |
-| - odu2 |
-| |
-| - ipv4 |
-| |
-| - ipv6 |
-| |
-| - pseudo\_wire |
-| |
-| type: string |
-| |
-| address\_data: |
-| |
-| entry\_schema: |
-| |
-| type: tosca.datatype.nfv.AddressData |
-| |
-| required: false |
-| |
-| type: list |
-| |
-| requirements: |
-| |
-| - virtual\_binding: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| occurrences: |
-| |
-| - 0 |
-| |
-| - UNBOUNDED |
-| |
-| - virtual\_link: |
-| |
-| capability: tosca.capabilities.nfv.VirtualBindable |
-| |
-| occurrences: |
-| |
-| - 0 |
-| |
-| - UNBOUNDED |
-| |
-| tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
-+-----------------------------------------------------------------+
-
.. |image1| image:: Image1.png
:width: 5.76806in
:height: 4.67161in
YAML Format
~~~~~~~~~~~
-R-95303 A VNF's Heat Orchestration Template **MUST** be defined using valid YAML.
+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
- 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
validation constraints that apply to the value of the parameter.
The parameter values provided in the VNF Heat Orchestration Template
are validated against the constraints at instantiation time.
-The stack creation fails if the parameter value doesn’t comply to the constraints.
+The stack creation fails if the parameter value doesn’t comply to
+the constraints.
The constraints are defined as a list with the following syntax
outputs
+++++++
-R-36982 A VNF’s Heat Orchestration template **MAY** contain the “outputs:” section.
+R-36982 A VNF’s Heat Orchestration template **MAY**
+contain the “outputs:” section.
This section allows for specifying output parameters
available to users once the template has been instantiated. If the
R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
contain the “resource_registry:” section.
-ONAP implementation does not support the Environment File resource_registry
-section. The resource_registry section allows for the definition of custom resources.
+ONAP implementation does not support the Environment File
+resource_registry section. The resource_registry section
+allows for the definition of custom resources.
SDC Treatment of Environment Files
ONAP Volume Module Output Parameters
++++++++++++++++++++++++++++++++++++
-R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
-Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
+R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
+Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
template, while other Output Parameters **MAY** be included.
A VNF’s Heat Orchestration Template’s Cinder Volume Module Output Parameter(s)
{vm-type}
~~~~~~~~~
-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-01455 When a VNF's Heat Orchestration Template creates a
+Virtual Machine (i.e., 'OS::Nova::Server'), each 'class' of VMs
+**MUST** be assigned a VNF unique '{vm-type}'; where 'class'
+defines VMs that **MUST** have the following identical characteristics:
-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.
+ 1.) OS::Nova::Server property flavor value
-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.
+ 2.) OS::Nova::Server property image value
-Note that {vm-type} must not be a substring of {network-role}. A
-substring of a string is another string that occurs "in". For example,
-"oam" is a substring of "oam\_protected". It will cause the
-Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
-produce erroneous error messages.
+ 3.) Cinder Volume attachments
+ - Each VM in the 'class' **MUST** have the identical Cinder Volume
+ configuration
-The {vm-type} should not contain the string “\_int” or “int\_” or
-“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
-ICE Project) process to produce erroneous error messages.
+ 4.) Network attachments and IP address requirements
+ - Each VM in the 'class' **MUST** have the the identical number
+ of ports connecting to the identical networks and requiring the
+ identical IP address configuration.
+
+R-82481 A VNF's Heat Orchestration Template's Resource property
+parameter that is
+associated with a unique Virtual Machine type **MUST**
+include '{vm-type}' as part of the parameter name with two
+exceptions:
-R-32394 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
-parameter names in the VNF.
+ 1.) The Resource OS::Nova::Server property availability_zone parameter
+ **MUST NOT** be prefixed with a common '{vm-type} identifier,
-R-46839 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
-Resource IDs in the VNF.
+ 2.) The Resource OS::Nova::Server eight mandatory and optional metadata
+ parameters (vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role,
+ vf_module_index, environment_context, workload_context) **MUST NOT**
+ be prefixed with a common '{vm-type}' identifier.
-It is recommended that the {vm-type} case in the parameter names matches
-the {vm-type} case in the Resource IDs.
-There are two exceptions to the above rules:
+R-66729 A VNF’s Heat Orchestration Template’s Resource that is
+associated with a unique Virtual Machine type **MUST** include
+‘{vm-type}’ as part of the resource ID.
-1. 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`_.
+R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
+only alphanumeric characters and/or underscores '_' and
+**MUST NOT** contain any of the following strings: '_int' or 'int\_'
+or '\_int\_'.
-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`_.
+R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
+substring of {network-role}.
+
+It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
+ICE Project) process to produce erroneous error messages.
+
+R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’
+in all Resource property parameter names **MUST** be the same case.
+
+R-46839 A VNF’s Heat Orchestration Template’s use of
+‘{vm-type}’ in all Resource IDs **MUST** be the same case.
+
+R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in
+Resource property parameter names **SHOULD** match the case of
+‘{vm-type}’ in Resource IDs and vice versa.
{network-role}
~~~~~~~~~~~~~~
The assignment of a {network-role} is discussed in `Networking`_.
-R-21330 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-21330 A VNF’s Heat Orchestration Template’s Resource property
+parameter that is associated with external network **MUST**
+include the ‘{network-role}’’ as part of the parameter name
-R-11168 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-11168 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an external network **MUST** include the
+'{network-role}' as part of the resource ID.
-R-84322 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-84322 A VNF's Heat Orchestration Template's Resource property
+parameter that is associated with an internal network
+**MUST** include 'int\_{network-role}' as part of the parameter
+name, where 'int\_' is a hard coded string.
-R-96983 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.
+R-96983 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an internal network **MUST** include
+'int\_{network-role}' as part of the Resource ID, where
+'int\_' is a hard coded string.
-Note that {network-role} must not be a substring of {vm-type}. A
-substring of a string is another string that occurs "in". For example,
-"oam" is a substring of "oam\_protected". It will cause the
-Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
-produce erroneous error messages.
+R-26506 A VNF's Heat Orchestration Template's '{network-role}'
+**MUST** contain only alphanumeric characters and/or
+underscores '_' and **MUST NOT** contain any of the following
+strings: '_int' or 'int\_' or '\_int\_'.
-The {network-role} should not contain the string “\_int” or “int\_” or
-“\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
-ICE Project) process to produce erroneous error messages.
+R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’
+**MUST NOT** be a substring of ‘{vm-type}’.
-R-58424 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
-all parameter names in the VNF.
+For example, if a VNF has a ‘{vm-type}’ of ‘oam’ and a
+‘{network-role}’ of ‘oam_protected’ would be a violation of the requirement.
-R-21511 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
-all Resource IDs in the VNF.
+R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource property parameter names **MUST** be the same case
-It is recommended that the {network-role} case in the parameter names
-matches the {network-role} case in the Resource IDs.
+R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource IDs **MUST** be the same case.
+
+R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case
+in Resource property parameter names **SHOULD** match the case
+of ‘{network-role}’ in Resource IDs and vice versa.
Resource IDs
~~~~~~~~~~~~
-Heat Orchestration Template resources are described in `resources`_
+Requirement R-75141 states a VNF’s Heat Orchestration Template’s
+resource name (i.e., <resource ID>) MUST only contain alphanumeric
+characters and underscores (‘_’).*
-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.
+Requirement R-16447 states a VNF’s <resource ID> MUST be unique
+across all Heat Orchestration Templates and all HEAT Orchestration
+Template Nested YAML files that are used to create the VNF.
-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).
+As stated previously, OpenStack requires the <resource ID> to be unique
+to the Heat Orchestration Template and not unique across all Heat
+Orchestration Templates the compose the VNF.
+
+Heat Orchestration Template resources are described in `resources`_
-R-54517 The VNF Heat Orchestration Template **MUST** include {vm-type} in the resource ID
-when a resource is associated with a single {vm-type}.
+R-54517 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’.
-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-96482 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single external network, the Resource ID MUST contain the text
+‘{network-role}’.
-R-98138 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-98138 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single internal network, the Resource ID MUST contain the text
+‘int\_{network-role}’.
-R-82115 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.
+R-82115 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single external network, the Resource
+ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
-- The {vm-type} must appear before the {network-role} and must be
- separated by an underscore (i.e., {vm-type}\_{network-role}).
+- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
+ be separated by an underscore '_'
-- Note that an {index} value may separate the {vm-type} and the
- {network-role}. An underscore will separate the three values (i.e.,
- {vm-type}\_{index}\_{network-role}).
+ - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
-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.
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ '{network-role}' and when this occurs underscores **MUST** separate the
+ three values.
-- The {vm-type} must appear before the int\_{network-role} and must be
- separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
+R-82551 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single internal network, the Resource ID
+**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
-- Note that an {index} value may separate the {vm-type} and the
- int\_{network-role}. An underscore will separate the three values
- (i.e., {vm-type}\_{index}\_int\_{network-role}).
+- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
+ **MUST** be separated by an underscore '_'
-When a resource is associated with more than one {vm-type} and/or more
-than one network, the resource ID
+ - (e.g., '{vm-type}\_int\_{network-role}',
+ '{vm-type}_{index}\_int\_{network-role}')
-- must not contain the {vm-type} and/or
- {network-role}/int\_{network-role}
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ 'int\_{network-role}' and when this occurs underscores **MUST** separate
+ the three values.
-- should contain the term “shared” and/or contain text that identifies
- the VNF.
+R-67793 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’
+and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the
+term ‘shared’ and/or contain text that identifies the VNF
-R-69287 The VNF Heat Orchestration Template **MUST** use only alphanumeric characters and “\_”
-underscores in the resource ID. Special characters must not be used.
+R-27970 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MAY** contain the term ‘shared’
+and/or **MAY** contain text that identifies the VNF.
-All {index} values must be zero based. That is, the {index} must start
-at zero and increment by one.
+R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains
+an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’
+**MUST** start at zero and increment by one.
The table below provides example OpenStack Heat resource ID for
resources only associated with one {vm-type} and/or one network.
-+-----------------------------+--------------------------------------+
-| Resource Type | Resource ID Format |
-+=============================+======================================+
-| OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
-+-----------------------------+--------------------------------------+
-| OS::Cinder::VolumeAttachment| {vm\_type}\_volumeattachment\_{index}|
-+-----------------------------+--------------------------------------+
-| OS::Heat::CloudConfig | {vm\_type}\_RCC |
-+-----------------------------+--------------------------------------+
-| OS::Heat::MultipartMime | {vm\_type}\_RMM |
-+-----------------------------+--------------------------------------+
-| OS::Heat::ResourceGroup | {vm\_type}\_RRG |
-+-----------------------------+--------------------------------------+
-| OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
-+-----------------------------+--------------------------------------+
-| OS::Neutron::Port | {vm\_type}\_{index}\ |
-| | _{network\_role}\_{index}\_port |
-+-----------------------------+--------------------------------------+
-| | {vm\_type}\_{index}\ |
-| | _int\_{network\_role}\_{index}\_port |
-+-----------------------------+--------------------------------------+
-| OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
-+-----------------------------+--------------------------------------+
-| OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
-+-----------------------------+--------------------------------------+
-| OS::Nova::Server | {vm\_type}\_{index} |
-+-----------------------------+--------------------------------------+
-| OS::Nova::ServerGroup | {vm\_type}\_RSG |
-+-----------------------------+--------------------------------------+
-| OS::Swift::Container | {vm\_type}\_RSwiftC |
-+-----------------------------+--------------------------------------+
-
- Table 1: Example OpenStack Heat Resource ID
-
-The table below provides example Contrail Heat resource ID for resources
-only associated with one {vm-type} and/or one network.
-
-+-------------------------------------------+---------------------------------+
-| Resource Type | Resource ID Format |
-+===========================================+=================================+
-| OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\ |
-| | _{network\_role}\_RII |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
-+-------------------------------------------+---------------------------------+
-| OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
-+-------------------------------------------+---------------------------------+
-
- Table 2: Example Contrail Heat resource ID
+The Requirements column states if the Resource ID Format MUST be followed
+or SHOULD be followed. Resource ID formats that are marked MUST must be
+followed, no deviations are permitted. Resource ID formats that are marked
+SHOULD should be followed. However, deviations are permissible to meet
+the needs of the VNF’s Heat Orchestration Template.
+
++-----------------+-------------------------+-------------+------------------+
+|Resource Type |Resource ID Format | Requirements| Notes |
+| | | | |
++=================+=========================+=============+==================+
+| OS::Cinder:: | {vm-type}\_volume\ | **SHOULD** | |
+| Volume | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Cinder:: | {vm-type}\ | **SHOULD** | |
+| VolumeAttachment| _volumeattachment\ | | |
+| | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RCC | **SHOULD** | |
+| CloudConfig | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RMM | **SHOULD** | |
+| MultipartMime | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RRG | **SHOULD** | |
+| ResourceGroup | | | |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_{index}\ | **MUST** for| Resource ID for |
+| | _subint\_{network-role}\| subinterface| the OS::Heat:: |
+| | _port\_{index}\ | creation | ResourceGroup |
+| | _subinterfaces | | that creates |
+| | | | subinterfaces |
++-----------------+-------------------------+-------------+------------------+
+| OS::Heat:: | {vm-type}_RSC | **SHOULD** | |
+| SoftwareConfig | | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | {vm-type}\ | **MUST** | Resource ID for |
+| Port | _{vm-type-index}\ | | port connecting |
+| | _{network-role}\_port\ | | to an external |
+| | _{port-index} | | network. The |
+| | | | {vm-type-index} |
+| | | | is the instance |
+| | | | of the {vm_type}.|
+| | | | The {port-index} |
+| | | | is the instance |
+| | | | of the “port” on |
+| | | | the {vm-type}. |
+| | | | There is no index|
+| | | | after |
+| | | | {network_role} |
+| | | | since |
+| | | | {network-role} is|
+| | | | unique to the |
+| | | | VNF, there should|
+| | | | only be one |
+| | | | instance. |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_{index}\_int\| **MUST** | Resource ID for |
+| | _{network-role}\_port\ | | port connecting |
+| | _{index} | | to an internal |
+| | | | network. The |
+| | | | {index} that |
+| | | | follows {vm-type}|
+| | | | is the instance |
+| | | | of the {vm_type}.|
+| | | | The {index} that |
+| | | | follows “port” is|
+| | | | the instance of |
+| | | | the “port” on the|
+| | | | {vm-type}. There |
+| | | | is no index after|
+| | | | {network_role} |
+| | | | since |
+| | | | {network-role} is|
+| | | | unque to the AIC |
+| | | | LCP; there should|
+| | | | only be one |
+| | | | instance. |
++-----------------+-------------------------+-------------+------------------+
+| | Reserve_Port\_{vm-type}\| | Resource ID for a|
+| | _{network-role}\ | **MUST** | reserve port that|
+| | _floating_ip\_{index} | | is used for an |
+| | | | allowed_address |
+| | Reserve_Port\_{vm-type}\| | \_pair. See |
+| | _{network-role}\ | | Section 5.6.5.5 |
+| | _floating_v6_ip\ | | for additional |
+| | _{index} | | details. |
+| | | | |
+| | | | There is no |
+| | | | {index} that |
+| | | | follows {vm-type}|
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | {vm-type}\_Sec\_Grp | **SHOULD** | Security Group |
+| SecurityGroup | | | applicable to one|
+| | | | {vm-type} and |
+| | | | more than one |
+| | | | network (internal|
+| | | | and/or external) |
++-----------------+-------------------------+-------------+------------------+
+| | {network-role}\_Sec\_Grp| **SHOULD** | Security Group |
+| | | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and one|
+| | | | external network |
++-----------------+-------------------------+-------------+------------------+
+| | int\_{network-role}\ | **SHOULD** | Security Group |
+| | _Sec\_Grp | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and one|
+| | | | internal network |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\ | **SHOULD** | Security Group |
+| | _{network-role}\_Sec\ | | applicable to one|
+| | _Grp | | {vm-type} and one|
+| | | | external network |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}\_int\ | **SHOULD** | Security Group |
+| | _{network-role}\_Sec\ | | applicable to one|
+| | _Grp | | {vm-type} and one|
+| | | | internal network |
++-----------------+-------------------------+-------------+------------------+
+| | Shared\_Sec\_Grp | **SHOULD** | Security Group |
+| | | | applicable to |
+| | | | more than one |
+| | | | {vm-type} and |
+| | | | more than one |
+| | | | network (internal|
+| | | | and/or external) |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron:: | int\_{network-role}\ | **MUST** | VNF Heat |
+| Subnet | _subnet\_{index} | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. |
++-----------------+-------------------------+-------------+------------------+
+| OS::Neutron::Net| int\_{network-role}\ | **MUST** | VNF Heat |
+| | _network | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. There |
+| | | | is no {index} |
+| | | | because |
+| | | | {nework-role} |
+| | | |should be unique. |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova:: | {vm-type}\_keypair\ | **SHOULD** | Key Pair |
+| Keypair | _{index} | | applicable to one|
+| | | | a{vm-type} |
++-----------------+-------------------------+-------------+------------------+
+| | {vnf-type}_keypair | **SHOULD** | Key Pair |
+| | | | applicable to all|
+| | | | {vm-type} in the |
+| | | | VNF |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova::Server| {vm-type}\_server\ | Mandatory | |
+| | _{index} | | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Nova:: | {vm-type}_RSG | **SHOULD** | Both formats are |
+| ServerGroup | | | valid. |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}_Server_Grp | **SHOULD** | |
++-----------------+-------------------------+-------------+------------------+
+| | {vm-type}_ServerGroup | **SHOULD** | |
++-----------------+-------------------------+-------------+------------------+
+| OS::Swift:: | {vm-type}\_RSwiftC | **SHOULD** | |
+| Container | | | |
++-----------------+-------------------------+-------------+------------------+
+
+
+ Table 2: Example OpenStack Heat Resource ID
+
+The table below provides Resource ID Formats for Contrail heat resources.
+ - The Resource ID formats that are marked mandatory must be followed.
+ No deviations are permitted.
+ - The Resource ID formats that are marked optional should be followed.
+ However, deviations in the Resource ID format that is shown is
+ permitted.
+
++-----------------+---------------------+-----------------+-----------------+
+| Resource | Resource ID | Mandatory / | Notes |
+| Type | Format | Optional | |
++=================+=====================+=================+=================+
+| OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** – | The {index} |
+| :InstanceIp | _{network-role}\ | IPv4 address on | that follows |
+| | _vmi\_{index}\ | vmi external | {vm-type} is |
+| | _IP\_{index} | network | the instance of |
+| | | | the {vm_type}. |
+| | | | The {index} |
+| | | | that follows |
+| | | | “vmi” is the |
+| | | | instance of the |
+| | | | “vmi” on the |
+| | | | {vm-type}. |
+| | | | There is no |
+| | | | index after |
+| | | | {network_role} |
+| | | | since since |
+| | | | {network-role} |
+| | | | is unque. The |
+| | | | {index} that |
+| | | | follows the |
+| | | | “IP” is the |
+| | | | instance of the |
+| | | | “IP” on the |
+| | | | “vmi” |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _{network-role}\ | IPv6 address on | |
+| | _vmi\_{index}\_v6\ | vmi external | |
+| | _IP\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _int\ | IPv4 address on | |
+| | _{network-role}\ | vmi internal | |
+| | _vmi\_{index}\_IP\ | network | |
+| | _{index} | | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _int\ | IPv6 address on | |
+| | _{network-role}\ | vmi internal | |
+| | _vmi\_{index}\_v6\ | network | |
+| | _IP\_{index} | | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _subint\ | IPv4 address on | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index}\_IP\ | vmi external | |
+| | _{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** – | |
+| | _subint\ | IPv6 address on | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index}\_v6\ | vmi external | |
+| | _IP\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {network-role}\_RIRT| **MAY** | |
+| :InterfaceRoute | | | |
+| Table | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {network-role}\_RNI | **MAY** | |
+| :NetworkIpam | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RPT | **MAY** | |
+| :PortTuple | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RSHC\ | **MAY** | |
+| :ServiceHealthC | _{LEFT/RIGHT} | | |
+| heck | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_RST\ | **MAY** | |
+| :ServiceTemplat | _{index} | | |
+| e | | | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** - vmi | Resource ID for |
+| :VirtualMachine | _{network-role}\ | attached to an | virtual machine |
+| Interface | _vmi\_{index} | external | interface (vmi) |
+| | | network | connecting to |
+| | | | an external |
+| | | | network. The |
+| | | | {index} that |
+| | | | follows |
+| | | | {vm-type} is |
+| | | | the instance of |
+| | | | the {vm_type}. |
+| | | | The {index} |
+| | | | that follows |
+| | | | “vmi” is the |
+| | | | instance of the |
+| | | | “vmi” on the |
+| | | | {vm-type}. |
+| | | | There is no |
+| | | | index after |
+| | | | {network_role} |
+| | | | since since |
+| | | | {network-role} |
+| | | | is unque to the |
+| | | | AIC LCP; there |
+| | | | should only be |
+| | | | one instance. |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** - vmi | |
+| | _int\ | attached to an | |
+| | _{network-role}\ | internal | |
+| | _vmi\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| | {vm-type}\_{index}\ | **MUST** - vmi | |
+| | _subint\ | attached to a | |
+| | _{network-role}\ | sub-interface | |
+| | _vmi\_{index} | network | |
++-----------------+---------------------+-----------------+-----------------+
+| OS::ContrailV2: | int\_{network-role}\| **MAY** | VNF Heat |
+| :VirtualNetwork | _RVN | | Orchestration |
+| | | | Templates can |
+| | | | only create |
+| | | | internal |
+| | | | networks. There |
+| | | | is no {index} |
+| | | | because |
+| | | | {nework-role} |
+| | | | should be |
+| | | | unique. Both |
+| | | | formats are |
+| | | | valid. |
++-----------------+---------------------+-----------------+-----------------+
+| | int\_{network-role}\| **MAY** | |
+| | _network | | |
++-----------------+---------------------+-----------------+-----------------+
+
+ Table 3: Example Contrail Heat resource ID
+
+There is a use case where the template filename is used as the type: as
+shown in the example below. There is no suggested Resource ID naming
+convention for this use case.
+
+Example: Template Filename used as the type:
+
+.. code-block:: python
+
+ heat_template_version: 2015-04-30
+
+ resources:
+ <Resource ID>:
+ type: file.yaml
+ properties:
+ ...
Resource: OS::Nova::Server - Parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. availability\_zone
+Requirement R-01455 defines how the ‘{vm-type]’ is defined.
+
+Requirement R-82481 defines how the ‘{vm-type} is used.’
+
The table below provides a summary. The sections that follow provides
-additional details.
-
-Note that the {vm\_type} must be identical across all four property
-parameters for a given OS::Nova::Server resource.
-
-+----------------------------------------------------------------------------+
-| 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
+the detailed requirements.
+
+.. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
+ :header: Property Name,Parameter Type,Parameter Name,Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
+
+ image, string, {vm-type}\_image\_name, Environment File
+ flavor, string, {vm-type}\_flavor\_name, Environment File
+ name, string, {vm-type}\_name\_{index}, ONAP
+ name, CDL, {vm-type}_names, ONAP
+ availability_zone, string, availability\_zone\_{index}, ONAP
Property: image
+++++++++++++++
-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’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
+type: ‘string’.
-R-71152 The VNF Heat Orchestration Template **MUST** declare as type: string the parameter
-for property image.
+R-58670 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_image_name’.
-R-91125 The VNF Heat Orchestration Template **MUST** enumerate the parameter for property
-image in the Heat Orchestration Template environment file.
+R-91125 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in
+the Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
-R-57282 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.
+R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’
+**MUST** have a unique parameter name for the ‘OS::Nova::Server’
+property ‘image’ even if more than one {vm-type} shares the same image.
*Example Parameter Definition*
Property: flavor
++++++++++++++++
-The parameter associated with the property flavor is an ONAP Constant
-parameter.
+R-50436 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
+type: ‘string’.
-The parameters must be named {vm-type}\_flavor\_name in the Heat
-Orchestration Template.
+R-45188 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_flavor_name’.
-R-50436 The VNF Heat Orchestration Template **MUST** declare the parameter property for
-flavor as type: string.
+R-69431 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the
+Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
-R-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 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.
+R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST**
+have a unique parameter name for the ‘OS::Nova::Server’ property
+‘flavor’ even if more than one {vm-type} shares the same flavor.
*Example Parameter Definition*
Property: Name
++++++++++++++
-The parameter associated with the property name is an ONAP Orchestration
-parameter.
+R-51430 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as
+either type ‘string’ or type ‘comma_delimited_list”.
-The parameter value is provided to the Heat template by ONAP.
+R-54171 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+the parameter name **MUST** follow the naming convention
+‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts
+at zero and increments by one.
-R-22838 The VNF Heat Orchestration Template **MUST NOT** enumerate the parameter for property name
-in the environment file.
+R-40899 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource
+associated with the ‘{vm-type}’.
-R-51430 The VNF Heat Orchestration Template **MUST** declare the parameter for property name as
-type: string or type: comma\_delimited\_list
+R-87817 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a
+‘comma_delimited_list’, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_names’.
-If the parameter is declared as type:string, the parameter must be named
-{vm-type}\_name\_{index}, where {index} is a numeric value that starts
-at zero and increments by one.
+R-85800 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a
+‘comma_delimited_list’, a parameter **MUST** be delcared once for all
+‘OS::Nova::Server’ resources associated with the ‘{vm-type}’.
-If the parameter is declared as type:comma\_delimited\_list, the
-parameter must be named as {vm-type}\_names
+R-22838 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated
+in the Heat Orchestration Template’s Environment File.
-Each element in the VM Name list should be assigned to successive
-instances of that VM type.
+If a VNF’s Heat Orchestration Template’s contains more than three
+OS::Nova::Server resources of a given {vm-type}, the comma_delimited_list
+form of the parameter name (i.e., ‘{vm-type}_names’) should be used to
+minimize the number of unique parameters defined in the template.
-If a VNF contains more than three instances of a given {vm-type}, the
-comma\_delimited\_list form of the parameter name (i.e.,
-{vm-type}\_names) should be used to minimize the number of unique
-parameters defined in the Heat.
*Example: Parameter Definition*
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- {vm-type}_names:
- type: comma_delimited_list
- description: VM Names for {vm-type} VMs
- {vm-type}_name_{index}:
- type: string
- description: VM Name for {vm-type} VM {index}
+ parameters:
-*Example: comma\_delimited\_list*
+ {vm-type}_names:
+ type: comma_delimited_list
+ description: VM Names for {vm-type} VMs
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+ {vm-type}_name_{index}:
+ type: string
+ description: VM Name for {vm-type} VM {index}
-.. code-block:: yaml
+*Example: comma_delimited_list*
- parameters:
- lb_names:
- type: comma_delimited_list
- description: VM Names for lb VMs
+In this example, the {vm-type} has been defined as “lb” for load balancer.
- resources:
- lb_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: [lb_names, 0] }
- ...
+.. code-block:: python
- lb_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: [lb_names, 1] }
- ...
+ parameters:
+
+ lb_names:
+ type: comma_delimited_list
+ description: VM Names for lb VMs
+
+ resources:
+ lb_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [lb_names, 0] }
+ ...
+
+ lb_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [lb_names, 1] }
+ ...
*Example: fixed-index*
-In this example, the {vm-type} has been defined as “lb” for load
-balancer.
+In this example, the {vm-type} has been defined as “lb” for load balancer.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- lb_name_0:
- type: string
- description: VM Name for lb VM 0
+ parameters:
- lb_name_1:
- type: string
- description: VM Name for lb VM 1
+ lb_name_0:
+ type: string
+ description: VM Name for lb VM 0
- resources:
- lb_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: lb_name_0 }
- ...
+ lb_name_1:
+ type: string
+ description: VM Name for lb VM 1
- lb_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: lb_name_1 }
- ...
+ resources:
+
+ lb_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_0 }
+ ...
+
+ lb_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_1 }
+ ...
Contrail Issue with Values for OS::Nova::Server Property Name
_____________________________________________________________
-The Contrail GUI has a limitation displaying special characters. The
-issue is documented in
-https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
-recommended that special characters be avoided. However, if special
-characters must be used, the only special characters supported are:
+R-44271 The VNF's Heat Orchestration Template's Resource
+'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
+contain special characters since the Contrail GUI has a limitation
+displaying special characters.
+
+However, if special characters must be used, the only special characters
+supported are:
+
+--- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _
-- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
Property: availability\_zone
++++++++++++++++++++++++++++
-The parameter associated with the property availability\_zone is an ONAP
-Orchestration parameter.
+R-98450 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter name
+**MUST** follow the naming convention ‘availability\_zone\_{index}’
+where the ‘{index}’ **MUST** start at zero and increment by one.
-The parameter value is provided to the Heat template by ONAP. The
-parameter must not be enumerated in the environment file.
+R-23311 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST**
+be declared as type: ‘string’.
-R-98450 The VNF Heat Orchestration Template **MUST** name the parameter availability\_zone\_{index}
-in the Heat Orchestration Template.
+The parameter must not be declared as type ‘comma_delimited_list’,
+ONAP does not support it.
-R-13561 The VNF Heat Orchestration Template **MUST** start the {index} at zero.
+R-59568 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT**
+be enumerated in the Heat Orchestration Template’s Environment File.
-R-60204 The VNF Heat Orchestration Template **MUST** increment the {index} by one.
+Example Parameter Definition
-R-36887 The VNF Heat Orchestration Template **MUST NOT** include the {vm-type} in the parameter name.
+.. code-block:: python
-The parameter must be declared as type: string
+ parameters:
+ availability_zone_{index}:
+ type: string
+ description: availability zone {index} name
-The parameter must not be declared as type: comma\_delimited\_list
+Requirement R-90279 states that a VNF Heat Orchestration’s template’s
+parameter MUST be used in a resource with the exception of the parameters
+for the OS::Nova::Server resource property availability_zone.
+
+R-01359 A VNF’s Heat Orchstration Template that contains an
+‘OS::Nova:Server’ Resource **MAY** define a parameter for the property
+‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’
+resources in the Heat Orchestration Template.
Example
-_______
++++++++
The example below depicts part of a Heat Orchestration Template that
uses the four OS::Nova::Server properties discussed in this section.
-In the Heat Orchestration Template below, four Virtual Machines
-(OS::Nova::Server) are created: two dns servers with {vm-type} set to
-“dns” and two oam servers with {vm-type} set to “oam”. Note that the
-parameter associated with the property name is a comma\_delimited\_list
-for dns and a string for oam.
+In the Heat Orchestration Template below, four Virtual
+Machines (OS::Nova::Server) are created: two dns servers with
+{vm-type} set to “dns” and two oam servers with {vm-type} set to “oam”.
+Note that the parameter associated with the property name is a
+comma_delimited_list for dns and a string for oam.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- dns_image_name:
- type: string
- description: dns server image
- dns_flavor_name:
- type: string
- description: dns server flavor
- dns_names:
- type: comma_delimited_list
- description: dns server names
- oam_image_name:
- type: string
- description: oam server image
- oam_flavor_name:
- type: string
- description: oam server flavor
- oam_name_0:
- type: string
- description: oam server name 0
- oam_name_1:
- type: string
- description: oam server name 1
- availability_zone_0:
- type: string
- description: availability zone ID or Name
- availability_zone_1:
- type: string
- description: availability zone ID or Name
+ parameters:
- resources:
- dns_server_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: [ dns_names, 0 ] }
- image: { get_param: dns_image_name }
- flavor: { get_param: dns_flavor_name }
- availability_zone: { get_param: availability_zone_0 }
- . . .
+ dns_image_name:
+ type: string
+ description: dns server image
- dns_server_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: [ dns_names, 1 ] }
- image: { get_param: dns_image_name }
- flavor: { get_param: dns_flavor_name }
- availability_zone: { get_param: availability_zone_1 }
- . . .
+ dns_flavor_name:
+ type: string
+ description: dns server flavor
- oam_server_0:
- type: OS::Nova::Server
- properties:
- name: { get_param: oam_name_0 }
- image: { get_param: oam_image_name }
- flavor: { get_param: oam_flavor_name }
- availability_zone: { get_param: availability_zone_0 }
- . . .
+ dns_names:
+ type: comma_delimited_list
+ description: dns server names
- oam_server_1:
- type: OS::Nova::Server
- properties:
- name: { get_param: oam_name_1 }
- image: { get_param: oam_image_name }
- flavor: { get_param: oam_flavor_name }
- availability_zone: { get_param: availability_zone_1 }
- . . .
+ oam_image_name:
+ type: string
+ description: oam server image
-Resource: OS::Nova::Server – Metadata Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ oam_flavor_name:
+ type: string
+ description: oam server flavor
-The resource OS::Nova::Server has an OpenStack optional property
-metadata. The metadata property is mandatory for ONAP Heat Orchestration
-Templates; it must be included.
+ oam_name_0:
+ type: string
+ description: oam server name 0
-R-17020 The VNF Heat Orchestration Template **MUST** include the following three mandatory
-metadata parameters for an OS::Nova::Server resource:
+ oam_name_1:
+ type: string
+ description: oam server name 1
-- vnf\_id
+ availability_zone_0:
+ type: string
+ description: availability zone ID or Name
-- vf\_module\_id
+ availability_zone_1:
+ type: string
+ description: availability zone ID or Name
-- vnf\_name
+ resources:
-ONAP allows the following three optional metadata parameters for an
-OS::Nova::Server resource. They may be included
+ dns_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, 0 ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+
+ . . .
+
+ dns_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, 1 ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
+
+ . . .
+
+ oam_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_name_0 }
+ image: { get_param: oam_image_name }
+ flavor: { get_param: oam_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
-- vm\_role
+ . . .
-- vf\_module\_name
+ oam_server_1:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_name_1 }
+ image: { get_param: oam_image_name }
+ flavor: { get_param: oam_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
-Note that the metadata parameters do not and must not contain {vm-type}
-in their name.
+ . . .
-When Metadata parameters are past into a nested heat template, the
-parameter names must not change.
+Boot Options
+++++++++++++
-The table below provides a summary. The sections that follow provides
-additional details.
-
-+-------------------+----------+-------------------+----------------+
-| 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
+R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
+boot from a Cinder Volume.
+
+R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the
+‘OS::Nova::Server’ resource property ‘image’ **MUST** be used.
+
+The requirements associated with
+the 'image' property are detailed in `Property: image`_
+
+R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the
+‘OS::Nova::Server’ resource property ‘block_device_mapping’ or
+‘block_device_mapping_v2’ **MUST** be used.
+
+There are currently no heat guidelines
+associated with these two properties:
+'block_device_mapping' and 'block_device_mapping_v2'.
+
+Resource: OS::Nova::Server – Metadata Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OS::Nova::Server Resource property metadata is an optional
+OpenStack property.
+The table below summarizes the mandatory and optional metadata
+supported by ONAP.
+
+The sections that follow provides the requirements associated with each
+metadata parameter.
+
+.. csv-table:: **Table 5 OS::Nova::Server Mandatory and Optional Metadata**
+ :header: Metadata Parameter Name, Parameter Type, Required, Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
+
+ vnf_id, string, **MUST**, ONAP
+ vf_module_id, string, **MUST**, ONAP
+ vnf_name, string, **MUST**, ONAP
+ vf_module_name, string, **SHOULD**, ONAP
+ vm_role, string, **MAY**, YAML or Environment File
+ vf_module_index, string, **MAY**, ONAP
+ workload_context, string, **SHOULD**, ONAP
+ environment_context, string, **SHOULD**, ONAP
vnf\_id
+++++++
-The vnf\_id parameter is mandatory; it must be included in the Heat
-Orchestration Template.
-
-The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
-UUID that is the vnf\_id and supplies it to the Heat Orchestration
+The OS::Nova::Server Resource metadata map value parameter 'vnf_id'
+is an ONAP generated UUID that identifies the VNF. The value
+is provided by ONAP to the VNF's Heat Orchestration
Template at orchestration time.
-The parameter must be declared as type: string
+R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
-R-55218 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
-for the OS::Nova::Server metadata parameter vnf\_id.
+R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST** be declared
+as type: ‘string’.
-R-20856 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vnf\_id in environment file.
+R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have
+parameter contraints defined.
-*Example Parameter Definition*
+R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
-.. code-block:: yaml
+R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ is passed into a
+Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change.
- parameters:
- vnf_id:
- type: string
- description: Unique ID for this VNF instance
+
+*Example 'vnf_id' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_id:
+ type: string
+ description: Unique ID for this VNF instance
vf\_module\_id
++++++++++++++
-The vf\_module\_id parameter is mandatory; it must be included in the
-Heat Orchestration Template.
+The OS::Nova::Server Resource metadata map value parameter 'vf\_module\_id'
+is an ONAP generated UUID that identifies the VF Module (e.g., Heat
+Orchestration Template). The value
+is provided by ONAP to the VNF's Heat Orchestration
+Template at orchestration time.
-The vf\_module\_id parameter value will be supplied by ONAP. ONAP
-generates the UUID that is the vf\_module\_id and supplies it to the
-Heat Orchestration Template at orchestration time.
+R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vf\_module\_id’.
-The parameter must be declared as type: string
+R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST**
+be declared as type: ‘string’.
-R-98374 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints
-defined for the OS::Nova::Server metadata parameter vf\_module\_id.
+R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+have parameter contraints defined.
-R-72871 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vf\_module\_id in environment file.
+R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
-*Example Parameter Definition*
+R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf_module_id’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_id’
+**MUST NOT** change.
-.. code-block:: yaml
+*Example 'vf\_module\_id' Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ vnf_module_id:
+ type: string
+ description: Unique ID for this VNF module instance
- parameters:
- vnf_module_id:
- type: string
- 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 OS::Nova::Server Resource metadata map value parameter 'vnf_name'
+is the ONAP generated alphanumeric name of the deployed VNF instance.
+The value
+is provided by ONAP to the VNF's Heat Orchestration
+Template at orchestration time.
+The parameter must be declared as type: string
-The vnf\_name parameter value will be generated and/or assigned by ONAP
-and supplied to the Heat Orchestration Template by ONAP at orchestration
-time.
+R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vnf_name’.
-The parameter must be declared as type: string
+R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+declared as type: ‘string’.
-R-44318 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
-for the OS::Nova::Server metadata parameter vnf\_name.
+R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have
+parameter contraints defined.
-R-36542 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vnf\_name in the environment file.
+R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
-*Example Parameter Definition*
+R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ is passed into a
+Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change.
-.. code-block:: yaml
+*Example 'vnf_name' Parameter Definition*
- parameters:
- vnf_name:
- type: string
- description: Unique name for this VNF instance
+.. code-block:: python
+
+ parameters:
+
+ vnf_name:
+ type: string
+ 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.
+The OS::Nova::Server Resource metadata map value parameter 'vf_module_name'
+is the deployment name of the heat stack created (e.g., <STACK_NAME>) from the
+VNF's Heat Orchestration template
+in the command 'Heat stack-create'
+(e.g., 'Heat stack-create [-f <FILE>] [-e <FILE>] <STACK_NAME>').
+The 'vf_module_name' (e.g., <STACK_NAME> is specified as
+part of the orchestration process.
-The vf\_module\_name parameter is the name of the name of the Heat stack
-(e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
-stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
-needs to be specified as part of the orchestration process.
+R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘vf\_module\_name’.
-The parameter must be declared as type: string
+R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ **MUST**
+be declared as type: ‘string’.
-Parameter constraints must not be defined.
+R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** have parameter contraints defined.
-The parameter must not be enumerated in the Heat environment file.
+R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+environment file.
-*Example Parameter Definition*
+R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_name’
+**MUST NOT** change.
-.. code-block:: yaml
+*Example 'vf_module_name' Parameter Definition*
- parameters:
- vf_module_name:
- type: string
- description: Unique name for this VNF Module instance
+.. code-block:: python
+
+ parameters:
+
+ vf_module_name:
+ type: string
+ description: Unique name for this VNF Module instance
vm\_role
++++++++
-The vm\_role parameter is optional; it may be included in the Heat
-Orchestration Template.
+The OS::Nova::Server Resource metadata map value parameter 'vm-role'
+is a metadata tag that describes the role of the Virtual Machine.
+The 'vm_role' is stored in ONAP's A&AI module and is
+available for use by other ONAP components and/or north bound systems.
-Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
-system and available for use by other ONAP components and/or north bound
-systems.
+R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter ‘vm_role’.
-The vm\_role values must be either
+R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST** be
+declared as type: ‘string’.
-- hard-coded into the Heat Orchestration Template or
+R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST NOT** have
+parameter contraints defined.
-- enumerated in the environment file.
+R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+either
-Defining the vm\_role as the {vm-type} is a recommended convention
+ - enumerated in the VNF’s Heat Orchestration
+ Template’s environment file.
-The parameter must be declared as type: string
+ - hard coded in the VNF’s Heat Orchestration
+ Template’s OS::Nova::Resource metadata property.
-Parameter constraints must not be defined.
+Defining the 'vm_role' as the '{vm-type}' is a recommended convention
-*Example Parameter Definition*
+R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ value **MUST only**
+contain alphanumeric characters and underscores ‘_’.
-.. code-block:: yaml
+R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ is passed into a
+Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change.
- parameters:
- vm_role:
- type: string
- description: Unique role for this VM
-*Example Resource Definition: Hard Coded*
+*Example 'vm_role' Parameter Definition*
-In this example, the {vm-role} is hard coded in the Heat Orchestration
-Template.
+.. code-block:: python
-.. code-block:: yaml
+ parameters:
- resources:
- dns_servers:
- type: OS::Nova::Server
- properties:
- . . . .
- metadata:
- vm_role: lb
+ vm_role:
+ type: string
+ description: Unique role for this VM
-*Example Resource Definition: get\_param*
+*Example: 'vm-role' Definition: Hard Coded in
+OS::Nova::Resource metadata property*
-In this example, the {vm-role} is enumerated in the environment file.
+.. code-block:: python
-.. code-block:: yaml
+ resources:
- resources:
- dns_servers:
- type: OS::Nova::Server
- properties:
- . . . .
- metadata:
- vm_role: { get_param: vm_role }
+ dns_server_0
+ type: OS::Nova::Server
+ properties:
+ . . . .
+ metadata:
+ vm_role: dns
-Example
-+++++++
+*Example 'vm-role' Definition: Defined in Environment file
+and retrieved via 'get_param'*
-The example below depicts part of a Heat Orchestration Template that
-uses the five of the OS::Nova::Server metadata parameter discussed in
-this section. The {vm-type} has been defined as lb for load balancer.
+.. code-block:: python
-.. code-block:: yaml
+ resources:
- parameters:
+ dns_server_0:
+ type: OS::Nova::Server
+ properties:
+ . . . .
+ metadata:
+ vm_role: { get_param: vm_role }
+
+Example vnf_id, vf_module_id, vnf_name, vf_module_name, vm_role
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+The example below depicts part of a Heat Orchestration Template
+that uses the five of the OS::Nova::Server metadata parameter
+discussed in this section. The {vm-type} has been defined as lb
+for load balancer.
+
+.. code-block:: python
+
+ parameters:
lb_name_0
- type: string
- description: VM Name for lb VM 0
+ type: string
+ description: VM Name for lb VM 0
vnf_name:
- type: string
- description: Unique name for this VNF instance
+ type: string
+ description: Unique name for this VNF instance
vnf_id:
- type: string
- description: Unique ID for this VNF instance
+ type: string
+ description: Unique ID for this VNF instance
vf_module_name:
- type: string
- description: Unique name for this VNF Module instance
+ type: string
+ description: Unique name for this VNF Module instance
vf_module_id:
- type: string
- description: Unique ID for this VNF Module instance
+ type: string
+ description: Unique ID for this VNF Module instance
vm_role:
- type: string
- description: Unique role for this VM
+ type: string
+ description: Unique role for this VM
+ resources:
+ lb_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: lb_name_0 }
+ ...
+ metadata:
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_name: { get_param: vf_module_name }
+ vf_module_id: { get_param: vf_module_id }
+ vm_role: lb
- resources:
+vf\_module\_index
++++++++++++++++++
+
+R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter
+‘vf\_module\_index’.
+
+R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be
+declared as type: ‘number’.
+
+R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+have parameter contraints defined.
+
+R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_index’
+**MUST NOT** change.
+
+R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be
+used in a VNF’s Volume Template; it is not supported.
+
+The vf_module_index parameter indicates which instance of the module is being
+deployed into the VNF.
+This parameter may be used in cases where multiple instances of the same
+incremental module may be instantiated for scaling purposes. The index
+can be used in the Heat Orchestration Template for indexing into a
+pseudo-constant array parameter when unique values are required for each
+module instance, e.g., for fixed private IP addresses on VM types.
+
+The vf_module_index will start at 0 for the first instance of a module
+type. Subsequent instances of the same module type will receive the
+lowest unused index. This means that indexes will be reused if a module
+is deleted and re-added. As an example, if three copies of a module are
+deployed with vf_module_index values of 0, 1, and 2 then subsequently
+the second one is deleted (index 1), and then re-added, index 1 will be
+reused.
+
+*Example*
+
+In this example, the {vm-type} has been defined as oam_vm to represent
+an OAM VM. An incremental heat module is used to deploy the OAM VM. The
+OAM VM attaches to an internal control network which has a
+{network-role} of ctrl. A maximum of four OAM VMs can be deployed. The
+environment file contains the four IP addresses that each successive OAM
+VM will be assigned. The vf_module_index is used as the index to
+determine the IP assignment.
+
+Environment File
+
+.. code-block:: python
+
+ parameters:
+ oam_vm_int_ctrl_ips: 10.10.10.1,10.10.10.2,10.10.10.3,10.10.10.4
+
+YAML File
+
+.. code-block:: python
+
+ parameters:
+ vf_module_index:
+ type: number
+ description: Unique index for this VNF Module instance
+ oam_vm_name_0:
+ type: string
+ description: VM Name for lb VM 0
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for the internal control network
+ oam_vm_int_ctrl_ips:
+ type: comma_delimited_list
+ description: Fixed IP assignments for oam VMs on the internal control
+ network
+ resources:
+ oam_vm_server_0:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: oam_vm_name_0 }
+ networks:
+ - port: { get_resource: oam_vm_0_int_ctrl_port_0 }
+ . . .
+ metadata:
+ vf_module_index: { get_param: vf_module_index }
+ oam_vm_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ oam_vm_int_ctrl_ips, { get_param, vf_module_index]}}}]
- lb_vm_0:
+workload_context
+++++++++++++++++
+
+R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘workload_context’.
+
+R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST** be
+declared as type: ‘string’.
+
+R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ is passed
+into a Nested YAML file, the parameter name ‘workload_context’
+**MUST NOT** change.
+
+The 'workload_context' parameter value will be chosen by the Service Model
+Distribution context client in VID and will be supplied to the
+Heat Orchestration Template by ONAP at orchestration time.
+
+*Example Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+ workload_context:
+ type: string
+ description: Workload Context for this VNF instance
+
+
+*Example OS::Nova::Server with metadata*
+
+.. code-block:: python
+
+ resources:
+ . . .
+
+ {vm-type}_server_{index}:
type: OS::Nova::Server
properties:
- name: { get_param: lb_name_0 }
- ...
+ name:
+ flavor:
+ image:
+ ...
metadata:
vnf_name: { get_param: vnf_name }
vnf_id: { get_param: vnf_id }
vf_module_name: { get_param: vf_module_name }
vf_module_id: { get_param: vf_module_id }
- vm_role: lb
+ workload_context: {get_param: workload_context}
+
+environment_context
++++++++++++++++++++
+
+R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘environment_context’.
+
+R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST**
+be declared as type: ‘string’.
+
+R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ is
+passed into a Nested YAML file, the parameter name
+‘environment_context’ **MUST NOT** change.
+
+The 'environment_context' parameter value will be defined by the
+service designer as part of the service model during the SDC
+on-boarding process and will be supplied to the Heat Orchestration
+Template by ONAP at orchestration time.
+
+
+*Example Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+ environment_context:
+ type: string
+ description: Environment Context for this VNF instance
+
+
+*Example OS::Nova::Server with metadata*
+
+.. code-block:: python
+
+ resources:
+ . . .
+
+ {vm-type}_server_{index}:
+ type: OS::Nova::Server
+ properties:
+ name:
+ flavor:
+ image:
+ ...
+ metadata:
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_name: { get_param: vf_module_name }
+ vf_module_id: { get_param: vf_module_id }
+ workload_context: {get_param: workload_context}
+ environment_context: {get_param: environment_context }
+
Resource: OS::Neutron::Port - Parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ONAP parameter naming convention. The four properties are:
1. network
+2. fixed_ips, ip_address
+3. fixed_ips, subnet_id or fixed_ips, subnet
-2. fixed\_ips, ip\_address
+ * Note that in many examples in this document fixed_ips, subnet_id is used.
-3. fixed\_ips, subnet\_id
+4. allowed_address_pairs, ip_address
-4. allowed\_address\_pairs, ip\_address
+Below is a generic example. Note that for some parameters
+comma_delimited_list are supported in addition to String.
+
+.. code-block:: python
+
+ resources:
+
+ ...
+
+ <resource ID>:
+ type: OS::Neutron::Port
+ properties:
+ allowed_address_pairs: [{"ip_address": String, "mac_address": String},
+ {"ip_address": String, "mac_address": String}, ...]
+ fixed_ips: [{"ip_address": String, "subnet_id": String, "subnet":
+ String}, {"ip_address": String, "subnet_id": String, "subnet": String},
+ ...]
+ network: String
The parameters associated with these properties may reference an
external network or internal network. External networks and internal
networks are defined in `Networking`_.
-External Networks
-_________________
+When the OS::Neutron::Port is attaching to an external network, all
+property values are parameters that are retrieved via the intrinsic
+function 'get_param'.
-When the parameter references an external network
-
-- 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, | {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)
+When the OS::Neutron::Port is attaching to an internal network, a
+property value maybe retrieved via the intrinsic
+function 'get_param', 'get_resource', or 'get_attr'.
-Internal Networks
-_________________
+This will be described in the forth coming sections.
+
+Items to Note
+_____________
+
+A network (internal or external) may contain one or or more subnets.
+
+A VNF can have one or more ports connected to the same network.
+
+A port can have one or more IP addresses assigned.
+
+The IP address assignments can be IPv4 addresses and/or IPv6 addresses.
+
+The IP addresses assignments for a unique external network **MUST**
+be all Cloud Assigned addresses OR **MUST** be all ONAP
+SDN-C assigned IP addresses.
+
+If the IP addresses are Cloud Assigned, all the IPv4 Addresses **MUST**
+be from
+the same subnet and all the IPv6 Addresses **MUST** be from the
+same subnet.
+
+If the IP addresses are ONAP SDN-C assigned,
+the IPv4 Addresses **MAY**
+be from
+different subnets and the IPv6 Addresses **MAY** be from different
+subnets.
+
+If a VNF's Port is attached to an external network the IP addresses **MAY**
+either be assigned by
+
+ 1. ONAP's SDN-Controller (SDN-C)
+ 2. Cloud Assigned by OpenStack’s DHCP Service
+
+If a VNF's Port is attached to an external network and the port's IP addresses
+are assigned by ONAP's SDN-Controller, the 'OS::Neutron::Port' Resource's
+
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used
+
+If a VNF's Port is attached to an external network and the port's IP addresses
+are Cloud Assigned by OpenStack’s DHCP Service,
+the 'OS::Neutron::Port' Resource's
+
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
+
+If a VNF's Port is attached to an internal network and the port's IP addresses
+are assigned by the VNF's Heat Orchestration Template
+(i.e., enumerated in the Heat Orchestration Template's environment file),
+the 'OS::Neutron::Port' Resource's
+
+ * property 'fixed_ips' map property 'ip_address' **MUST** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id'
+ **MUST NOT** be used
+
+If a VNF's Port is attached to an internal network and the port's IP addresses
+are Cloud Assigned by OpenStack’s DHCP Service,
+the 'OS::Neutron::Port' Resource's
+
+ * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
+ * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
+
+If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
+'fixed_ips' map property 'ip_address' is specified, then the
+'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT**
+be specified.
-When the parameter references an internal network
-
-- 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 | 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)
+If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
+'fixed_ips' map property 'subnet'/'subnet_id' is specified, then the
+'fixed_ips' map property 'ip_address' **MUST NOT**
+be specified.
+
+.. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
+ :header: Resource,Property,Parameter Type,Parameter Name,Parameter Value Provided to Heat
+ :align: center
+ :widths: auto
+
+ OS::Nova::Server, image, string, {vm-type}_image_name, Environment File
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.
+The Resource 'OS::Neutron::Port' property 'network' determines what network
+the port is attached to.
-External Networks
-_________________
-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:
+R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘network’ parameter **MUST** be declared as type: ‘string’.
-- {network-role}\_net\_id for the Neutron network ID
+R-62983 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external network,
+the ‘network’ parameter name **MUST**
-- {network-role}\_net\_name for the network name in OpenStack
+- follow the naming convention ‘{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘{network-role}_net_name’ if the OpenStack
+ network name is used to reference the network.
-The parameter must be declared as type: string
+where ‘{network-role}’ is the network-role of the external network and
+a ‘get_param’ **MUST** be used as the intrinsic function.
-The parameter must not be enumerated in the Heat environment file.
+R-86182 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an internal network,
+and the internal network is created in a different
+Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
+parameter name **MUST**
-*Example Parameter Definition*
+- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘int\_{network-role}_net_name’ if the
+ OpenStack network name in is used to reference the network.
-.. code-block:: yaml
+where ‘{network-role}’ is the network-role of the internal network
+and a ‘get_param’ **MUST** be used as the intrinsic function.
+
+In Requirement R-86182, the internal network is created in the VNF's
+Base Module (Heat Orchestration Template) and the parameter name is
+declared in the Base Module's outputs' section.
+The output parameter name will be declared as a parameter in the
+'parameters' section of the incremental module.
+
+R-93177 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an internal
+network, and the internal network is created in the same Heat
+Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
+parameter name **MUST** obtain the UUID of the internal network
+by using the intrinsic function ‘get_resource’ or ‘get_attr’
+and referencing the Resource ID of the internal network.
+
+R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’
+property ‘network’ parameter **MUST NOT** be enumerated in the Heat
+Orchestration Template’s Environment File.
+
+The parameter values for external networks are provided by ONAP
+to the VNF's Heat Orchestration Template at orchestration time.
+
+The parameter values for internal networks created in the VNF's Base Module
+Heat Orchestration Template
+are provided to the VNF's Incremental Module Heat Orchestration Template
+at orchestration time.
+
+*Example Parameter Definition of External Networks*
+
+.. code-block:: python
+
+ parameters:
+
+ {network-role}_net_id:
+ type: string
+ description: Neutron UUID for the external {network-role} network
+
+ {network-role}_net_name:
+ type: string
+ description: Neutron name for the external {network-role} network
+
+
+*Example Parameter Definition of Internal Networks in an Incremental Module*
+
+.. code-block:: python
+
+ parameters:
+
+ int_{network-role}_net_id:
+ type: string
+ description: Neutron UUID for the internal int_{network-role} network
+
+ int_{network-role}_net_name:
+ type: string
+ description: Neutron name for the internal int_{network-role} network
+
+Property: fixed_ips, Map Property: ip_address
++++++++++++++++++++++++++++++++++++++++++++++
+
+The resource 'OS::Neutron::Port' property 'fixed_ips'
+map property 'ip_address'
+is used to assign one IPv4 or IPv6
+addresses to port.
+
+One 'OS::Neutron::Port' resource may assign one or more
+IPv4 and/or IPv6 addresses.
+
+R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST**
+be declared as either type ‘string’ or type ‘comma_delimited_list’.
+
+R-40971 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 address is
+assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined
+as a string, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_{network-role}\_ip\_{index}’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
+
+R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
+
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
+
+*Example External Network IPv4 Address string Parameter Definition*
+
+.. code-block:: python
+
+ parameters:
+
+ {vm-type}_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
- parameters:
- {network-role}_net_id:
- type: string
- description: Neutron UUID for the {network-role} network
- {network-role}_net_name:
- type: string
- description: Neutron name for the {network-role} network
+R-04697 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external
+network, and an IPv4 address is assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type
+is defined as a comma_delimited_list, the parameter name **MUST**
+follow the naming convention ‘{vm-type}_{network-role}_ips’,
+where
-*Example: One Cloud Assigned IP Address (DHCP) assigned to a network
-that has only one subnet*
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
-In this example, the {network-role} has been defined as oam to represent
-an oam network and the {vm-type} has been defined as lb for load
-balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
-to assign IP addresses.
+R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s
+Heat Orchestration Template’s Environment File.
-.. code-block:: yaml
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+*Example External Network IPv4 Address comma_delimited_list
+Parameter Definition*
- resources:
- lb_port_1:
- type: OS::Neutron::Port
- network: { get_param: oam_net_id }
+.. code-block:: python
-Internal Networks
-_________________
+ parameters:
-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:
+ {vm-type}_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the {network-role} network
-- int\_{network-role}\_net\_id for the Neutron network ID
+R-71577 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where
-- int\_{network-role}\_net\_name for the network name in OpenStack
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
-The parameter must be declared as type: string
-The assumption is that internal networks are created in the base module.
-The Neutron Network ID will be passed as an output parameter (e.g., ONAP
-Base Module Output Parameter) to the incremental modules. In the
-incremental modules, it will be defined as input parameter.
+R-87123 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration
+Template’s Environment File.
-*Example Parameter Definition*
+ONAP's SDN-Controller assigns the IP Address and ONAP provides
+the value at orchestration to the Heat Orchestration Template.
-.. code-block:: yaml
+*Example External Network IPv6 Address string Parameter Definition*
- parameters:
- int_{network-role}_net_id:
- type: string
- description: Neutron UUID for the {network-role} network
- int_{network-role}_net_name:
- type: string
- description: Neutron name for the {network-role} network
+.. code-block:: python
-Property: fixed\_ips, Map Property: subnet\_id
-++++++++++++++++++++++++++++++++++++++++++++++
+ parameters:
-The property fixed\_ips is used to assign IPs to a port. The Map
-Property subnet\_id specifies the subnet the IP is assigned from.
+ {vm-type}_{network-role}_v6_ip_{index}:
+ type: string
+ description: Fixed IPv6 assignment for {vm-type} VM {index} on the {network-role} network
-The property fixed\_ips and Map Property subnet\_id must be used if a
-Cloud (i.e., DHCP) IP address assignment is being requested and the
-Cloud IP address assignment is targeted at a specific subnet when two or
-more subnets exist.
+R-23503 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}_{network-role}_v6_ips’, where
-The property fixed\_ips and Map Property subnet\_id should not be used
-if all IP assignments are fixed, or if the Cloud IP address assignment
-does not target a specific subnet or there is only one subnet.
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
-Note that DHCP assignment of IP addresses is also referred to as cloud
-assigned IP addresses.
+R-93030 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
-Subnet of an External Networks
-______________________________
+ONAP's SDN-Controller assigns the IP Address and ECOMP provides
+the value at orchestration to the Heat Orchestration Template.
-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.
+*Example External Network IPv6 Address comma_delimited_list Parameter
+Definition*
-- {network-role}\_subnet\_id if the subnet is an IPv4 subnet
+.. code-block:: python
-- {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+ parameters:
-The parameter must be declared as type: string
+ {vm-type}_{network-role}_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
-The parameter must not be enumerated in the Heat environment file.
+R-78380 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where
-*Example Parameter Definition*
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
-.. code-block:: yaml
+R-28795 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated
+in the VNF’s Heat Orchestration Template’s Environment File.
- parameters:
- {network-role}_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
- {network-role}_v6_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+*Example Internal Network IPv4 Address string Parameter Definition*
-*Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
-that has two or more subnets subnet:*
+.. code-block:: python
-In this example, the {network-role} has been defined as oam to represent
-an oam network and the {vm-type} has been defined as lb for load
-balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
-to assign IP addresses.
+ parameters:
-.. code-block:: yaml
+ {vm-type}_int_{network-role}_ip_{index}:
+ type: string
+ description: Fixed IPv4 assignment for {vm-type} VM {index} on the int_{network-role} network
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+R-85235 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_ips’, where
- oam_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
- resources:
- lb_port_1:
- type: OS::Neutron::Port
- network: { get_param: oam_net_id }
- fixed_ips:
- - subnet_id: { get_param: oam_subnet_id }
+R-90206 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
-*Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
-address assigned to a network that has at least one IPv4 subnet and one
-IPv6 subnet*
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-In this example, the {network-role} has been defined as oam to represent
-an oam network and the {vm-type} has been defined as lb for load
-balancer.
+.. code-block:: python
-.. code-block:: yaml
+ parameters:
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for the oam network
+ {vm-type}_int_{network-role}_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
- oam_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+R-27818 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where
- oam_v6_subnet_id:
- type: string
- description: Neutron subnet UUID for the oam network
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
- resources:
- lb_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: oam_net_id }
- fixed_ips:
- - subnet_id: { get_param: oam_subnet_id }
- - subnet_id: { get_param: oam_v6_subnet_id }
+R-97201 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’
+**MUST** be enumerated in the VNF’s Heat Orchestration
+Template’s Environment File.
-Internal Networks
-_________________
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-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:
+*Example Internal Network IPv6 Address string Parameter Definition*
-- int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
+.. code-block:: python
-- int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+ parameters:
-The parameter must be declared as type: string
+ {vm-type}_int_{network-role}_v6_ip_{index}:
+ type: string
+ description: Fixed IPv6 assignment for {vm-type} VM {index} on the int_{network-role} network
-The assumption is that internal networks are created in the base module.
-The Neutron subnet network ID will be passed as an output parameter
-(e.g., ONAP Base Module Output Parameter) to the incremental modules. In
-the incremental modules, it will be defined as input parameter.
+R-29765 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_v6_ips’, where
-*Example Parameter Definition*
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
-.. code-block:: yaml
+*Example Internal Network IPv6 Address comma_delimited_list Parameter
+Definition*
- parameters:
- int_{network-role}_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+.. code-block:: python
- int_{network-role}_v6_subnet_id:
- type: string
- description: Neutron subnet UUID for the {network-role} network
+ parameters:
-Property: fixed\_ips, Map Property: ip\_address
-+++++++++++++++++++++++++++++++++++++++++++++++
+ {vm-type}_int_{network-role}_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
-The property fixed\_ips is used to assign IPs to a port. The Map
-Property ip\_address specifies the IP address to be assigned to the
-port.
+R-98569 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
-The property fixed\_ips and Map Property ip\_address must be used when
-statically assigning one or more IP addresses to a port. This is also
-referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
-the IP address assignment.
+The IP address is local to the VNF's internal network and is (re)used
+in every VNF spin up, thus the constant value is declared in the VNF's
+Heat Orchestration Template's Environment File.
-An IP address is assigned to a port on a VM (referenced by {vm-type})
-that is connected to an external network (referenced by {network-role})
-or internal network (referenced by int\_{network-role}).
+R-62590 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an external network, i.e.,
-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.
+- {vm-type}_{network-role}\_ip\_{index}
+- {vm-type}_{network-role}\_ip\_v6\_{index}
+- {vm-type}_{network-role}_ips
+- {vm-type}_{network-role}_v6_ips
-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}.
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+Environment File. ONAP provides the IP address assignments at
+orchestration time.
-IP Address Assignments on External Networks
-___________________________________________
+R-93496 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an internal network, i.e.,
-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).
+- {vm-type}\_int\_{network-role}\_ip\_{index}
+- {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
+- {vm-type}\_int\_{network-role}_ips
+- {vm-type}\_int\_{network-role}_v6_ips
-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:
+**MUST** be enumerated in the Heat Orchestration Template’s Environment
+File and IP addresses **MUST** be assigned.
-- {vm-type}\_{network-role}\_ips for IPv4 address
+Summary Table
+_____________
-- {vm-type}\_{network-role}\_v6\_ips for IPv6 address
+.. csv-table:: **Table # OS::Neutron::Port Property fixed_ips map property ip_address Parameter Naming Convention**
+ :header: Resource,Property,Map Property,Network Type,IP Address,Parameter Type,Parameter Name, Environment File
+ :align: center
+ :widths: auto
-Each element in the IP list should be assigned to successive instances
-of {vm-type} on {network-role}.
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, string, {vm-type}\_{network-role}\_ip\_{index}, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, comma\_delimited\_list, {vm-type}\_{network-role}\_ips, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, string, {vm-type}\_{network-role}\_v6\_ip\_{index}, NO
+ OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, comma\_delimited\_list, {vm-type}\_{network-role}\_v6\_ips, NO
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, string, {vm-type}\_int\_{network-role}\_ip\_{index}, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_ips, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, string, {vm-type}\_int\_{network-role}\_v6\_ip\_{index}, YES
+ OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_v6\_ips, YES
-The parameter must not be enumerated in the Heat environment file.
-*Example Parameter Definition*
+Examples
+________
-.. code-block:: yaml
+*Example: comma_delimited_list parameters for IPv4 and IPv6 Address
+Assignments to an external network*
- parameters:
+In this example, the '{network-role}' has been defined as 'oam' to represent
+an oam network and the '{vm-type}' has been defined as 'db' for database.
- {vm-type}_{network-role}_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
+.. code-block:: python
- {vm-type}_{network-role}_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for a oam network
+ db_oam_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for db VMs on the oam network
+ db_oam_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for db VMs on the oam network
+ resources:
+ db_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {
+ “ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
+ db_1_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
+ - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
-*Example: comma\_delimited\_list 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 database.
+In this example, the '{network-role}' has been defined as 'oam' to
+represent an oam network and the '{vm-type}' has been defined as 'db' for
+database.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
+ parameters:
oam_net_id:
- type: string
- description: Neutron UUID for a oam network
+ type: string
+ description: Neutron UUID for an OAM network
+ db_oam_ip_0:
+ type: string
+ description: Fixed IPv4 assignment for db VM 0 on the OAM network
+ db_oam_ip_1:
+ type: string
+ description: Fixed IPv4 assignment for db VM 1 on the OAM network
+ db_oam_v6_ip_0:
+ type: string
+ description: Fixed IPv6 assignment for db VM 0 on the OAM network
+ db_oam_v6_ip_1:
+ type: string
+ description: Fixed IPv6 assignment for db VM 1 on the OAM network
+ resources:
+ db_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, { “ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
+ db_1_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: db_oam_ip_1}}]
+ - “ip_address”: {get_param: db_oam_v6_ip_1}}]
- db_oam_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for db VMs on the oam network
- db_oam_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for db VMs on the oam network
+*Example: comma_delimited_list parameters for IPv4 and IPv6 Address
+Assignments to an internal network*
- resources:
- db_0_port_1:
- type: OS::Neutron::Port
- network: { get_param: oam_net_id }
- fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
+In this example, the '{network-role}' has been defined as 'ctrl' to
+represent an ctrl network internal to the vnf.
+The '{vm-type}' has been defined as 'db' for
+database.
- db_1_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: oam_net_id }
- fixed_ips:
- - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
- - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
+.. code-block:: python
-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:
+ parameters:
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for the ctrl internal network
+ db_int_ctrl_ips:
+ type: comma_delimited_list
+ description: Fixed IPv4 assignments for db VMs on the ctrl internal
+ network
+ db_int_ctrl_v6_ips:
+ type: comma_delimited_list
+ description: Fixed IPv6 assignments for db VMs on the ctrl internal
+ network
+ resources:
+ db_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: [ db_int_ctrl_ips, 0 ]}}, {
+ “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 0 ]}}]
+ db_1_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_ctrl_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: [ db_int_ctrl_ips, 1 ]}
+ - “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 1 ]}
-- {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
-- {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+*Example: string parameters for IPv4 and IPv6 Address Assignments to an
+internal network*
-The value for {index} must start at zero (0) and increment by one.
+In this example, the int\_{network-role} has been defined as
+int_ctrl to represent a control network internal to the vnf.
+The {vm-type} has been defined as db for database.
-The parameter must not be enumerated in the Heat environment file.
+.. code-block:: python
-*Example Parameter Definition*
+ parameters:
+ int_ctrl_net_id:
+ type: string
+ description: Neutron UUID for an OAM internal network
+ db_int_ctrl_ip_0:
+ type: string
+ description: Fixed IPv4 assignment for db VM on the oam_int network
+ db_int_ctrl_ip_1:
+ type: string
+ description: Fixed IPv4 assignment for db VM 1 on the oam_int network
+ db_int_ctrl_v6_ip_0:
+ type: string
+ description: Fixed IPv6 assignment for db VM 0 on the oam_int network
+ db_int_ctrl_v6_ip_1:
+ type: string
+ description: Fixed IPv6 assignment for db VM 1 on the oam_int network
+ resources:
+ db_0_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_oam_int_net_id }
+ fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {
+ “ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
+ db_1_int_ctrl_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: int_oam_int_net_id }
+ fixed_ips:
+ - “ip_address”: {get_param: db_oam_int_ip_1}}]
+ - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
-.. code-block:: yaml
- parameters:
- {vm-type}_{network-role}_ip_{index}:
- type: string
- description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
+Property: fixed\_ips, Map Property: subnet\_id
+++++++++++++++++++++++++++++++++++++++++++++++
- {vm-type}_{network-role}_v6_ip_{index}:
- type: string
- description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
+The resource 'OS::Neutron::Port' property 'fixed_ips' map
+property 'subnet'/'subnet_id' is used when a
+port is requesting an IP assignment via
+OpenStack’s DHCP Service (i.e., Cloud Assigned).
-*Example: string parameters for IPv4 and IPv6 Address Assignments
-to an external network*
+The IP address assignment will be made from the specified subnet.
-In this example, the {network-role} has been defined as “oam” to
-represent an oam network and the {vm-type} has been defined as “db” for
-database.
+Specifying the subnet is not required; it is optional.
-.. code-block:: yaml
+If the network (external or internal) that the port is attaching
+to only contains one subnet, specifying the subnet is
+superfluous. The IP address will be assigned from the one existing
+subnet.
- parameters:
- oam_net_id:
- type: string
- description: Neutron UUID for an OAM network
+If the network (external or internal) that the port is attaching
+to contains two or more subnets, specifying the subnet in the
+'fixed_ips' map property 'subnet'/'subnet_id' determines which
+subnet the IP address will be assigned from.
- db_oam_ip_0:
- type: string
- description: Fixed IPv4 assignment for db VM 0 on the OAM network
+If the network (external or internal) that the port is attaching
+to contains two or more subnets, and the subnet is not is not
+specified, OpenStack will randomly(?) determine which subnet
+the IP address will be assigned from.
- db_oam_ip_1:
- type: string
- description: Fixed IPv4 assignment for db VM 1 on the OAM network
+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.
- db_oam_v6_ip_0:
- type: string
- description: Fixed IPv6 assignment for db VM 0 on the OAM network
+R-38236 The VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’.
- db_oam_v6_ip_1:
- type: string
- description: Fixed IPv6 assignment for db VM 1 on the OAM network
+R-62802 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv4
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv4 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_id’, where
+‘{network-role}’ is the network role of the network.
- resources:
- db_0_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: oam_net_id }
- fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
+R-83677 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
- db_1_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: oam_net_id }
- fixed_ips:
- - “ip_address”: {get_param: db_oam_ip_1}}]
- - “ip_address”: {get_param: db_oam_v6_ip_1}}]
+ONAP's SDN-Controller provides the network's subnet's UUID
+value at orchestration to the Heat Orchestration Template.
-IP Address Assignment on Internal Networks
-__________________________________________
+*Example Parameter Definition*
-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).
+.. code-block:: python
-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:
+ parameters:
-- {vm-type}\_int\_{network-role}\_ips for IPv4 address
+ {network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the {network-role} network
-- {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
+R-15287 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv6 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_v6_id’, where
+‘{network-role}’ is the network role of the network.
-Each element in the IP list should be assigned to successive instances
-of {vm-type} on {network-role}.
+R-80829 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
-The parameter must be enumerated in the Heat environment file. Since an
-internal network is local to the VNF, IP addresses can be re-used at
-every VNF instance.
+ONAP's SDN-Controller provides the network's subnet's UUID
+value at orchestration to the Heat Orchestration Template.
*Example Parameter Definition*
-.. code-block:: yaml
+.. code-block:: python
- parameters:
+ parameters:
- {vm-type}_int_{network-role}_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
+ {network-role}_v6_subnet_id:
+ type: string
+ description: Neutron IPv6 subnet UUID for the {network-role} network
- {vm-type}_int_{network-role}_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
-*Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
-Assignments to an internal network*
+*Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
+that has two or more IPv4 subnets*
-In this example, the {network-role} has been defined as oam\_int to
-represent an oam network internal to the vnf. The role oam\_int was
-picked to differentiate from an external oam network with a
-{network-role} of oam. The {vm-type} has been defined as db for
-database.
+In this example, the '{network-role}' has been defined as 'oam' to represent
+an oam network and the '{vm-type}' has been defined as 'lb' for load
+balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
+to assign IP addresses.
-.. code-block:: yaml
+.. code-block:: python
- parameters:
- int_oam_int_net_id:
- type: string
- description: Neutron UUID for the oam internal network
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
+ oam_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the oam network
+ resources:
+ lb_0_oam_port_0:
+ type: OS::Neutron::Port
+ parameters:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - subnet_id: { get_param: oam_subnet_id }
- db_int_oam_int_ips:
- type: comma_delimited_list
- description: Fixed IPv4 assignments for db VMs on the oam internal network
+*Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
+address assigned to a network that has at least one IPv4 subnet and one
+IPv6 subnet*
- db_int_oam_int_v6_ips:
- type: comma_delimited_list
- description: Fixed IPv6 assignments for db VMs on the oam internal network
+In this example, the '{network-role}' has been defined as 'oam' to represent
+an oam network and the '{vm-type}' has been defined as 'lb' for load
+balancer.
- resources:
- db_0_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
+.. code-block:: python
- db_1_port_1:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips:
- - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
- - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
+ parameters:
+ oam_net_id:
+ type: string
+ description: Neutron UUID for the oam network
+ oam_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the oam network
+ oam_v6_subnet_id:
+ type: string
+ description: Neutron IPv6 subnet UUID for the oam network
+ resources:
+ lb_0_oam_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: { get_param: oam_net_id }
+ fixed_ips:
+ - subnet_id: { get_param: oam_subnet_id }
+ - subnet_id: { get_param: oam_v6_subnet_id }
-R-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:
+R-84123 When
-- {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
+- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+ in an Incremental Module is attaching to an internal network
+ that is created in the Base Module, AND
+- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv4 subnet is to be specified using the
+ property ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
-- {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the
+network role of the internal network
-The value for {index} must start at zero (0) and increment by one.
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
-The parameter must be enumerated in the Heat environment file. Since an
-internal network is local to the VNF, IP addresses can be re-used at
-every VNF instance.
+R-69634 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
-*Example Parameter Definition*
+The assumption is that internal networks are created in the base module.
+The Neutron subnet network ID will be passed as an output parameter
+(e.g., ECOMP Base Module Output Parameter) to the incremental modules.
+In the incremental modules, the output parameter name will be defined as
+input parameter.
-.. code-block:: yaml
+*Example Parameter Definition*
- parameters:
+.. code-block:: python
- {vm-type}_int_{network-role}_ip_{index}:
- type: string
- description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
+ parameters:
- {vm-type}_int_{network-role}_v6_ip_{index}:
- type: string
- description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
+ int_{network-role}_subnet_id:
+ type: string
+ description: Neutron IPv4 subnet UUID for the int_{network-role} network
-*Example: string parameters for IPv4 and IPv6 Address Assignments
-to an internal network*
+R-76160 When
-In this example, the {network-role} has been defined as oam\_int to
-represent an oam network internal to the vnf. The role oam\_int was
-picked to differentiate from an external oam network with a
-{network-role} of oam. The {vm-type} has been defined as db for
-database.
+- the VNF’s Heat Orchestration Template’s resource
+ ‘OS::Neutron::Port’ in an Incremental Module is attaching to an
+ internal network that is created in the Base Module, AND
+- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv6 subnet is to be specified using the property
+ ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
-.. code-block:: yaml
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
+is the network role of the internal network
- parameters:
- int_oam_int_net_id:
- type: string
- description: Neutron UUID for an OAM internal network
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
- db_oam_int_ip_0:
- type: string
- description: Fixed IPv4 assignment for db VM on the oam_int network
+R-22288 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
- db_oam_int_ip_1:
- type: string
- description: Fixed IPv4 assignment for db VM 1 on the oam_int network
+*Example Parameter Definition*
- db_oam_int_v6_ip_0:
- type: string
- description: Fixed IPv6 assignment for db VM 0 on the oam_int network
+.. code-block:: python
- db_oam_int_v6_ip_1:
- type: string
- description: Fixed IPv6 assignment for db VM 1 on the oam_int network
+ parameters:
- resources:
- db_0_port_0:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
+ int_{network-role}_v6_subnet_id:
+ type: string
+ description: Neutron subnet UUID for the int_{network-role} network
- db_1_port_0:
- type: OS::Neutron::Port
- properties:
- network: { get_param: int_oam_int_net_id }
- fixed_ips:
- - “ip_address”: {get_param: db_oam_int_ip_1}}]
- - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
Property: allowed\_address\_pairs, Map Property: ip\_address
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Internal Networks
_________________
-R-16805 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention
-for the property allowed\_address\_pairs and Map Property ip\_address
-parameter when the parameter is referencing an “internal” network.
+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.
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 Orchestration Template **MUST** use the intrinsic function str\_replace
-in conjunction with the ONAP supplied metadata parameter
-vnf\_name to generate a unique value,
-when the property name for a non OS::Nova::Server resources is defined
-in a Heat Orchestration Template.
+R-85734 The VNF Heat Orchestration Template **MUST** use the
+intrinsic function str\_replace in conjunction with the ONAP
+supplied metadata parameter vnf\_name to generate a unique
+value, when the property name for a non OS::Nova::Server
+resources is defined in a Heat Orchestration Template.
This prevents the enumeration of a
unique value for the property name in a per instance environment file.
- get_param: fw_sec_grp_id
Interface Route Table Prefixes for Contrail InterfaceRoute Table
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The parameter associated with the resource
OS::ContrailV2::InterfaceRouteTable property
be embedded within the Base Module or Incremental Module if persistence
is not required.
-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
+R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
+scope of a cinder volume module, when it exists, with the
+Base Module or Incremental Module
A single volume module must create only the volumes
required by a single Incremental module or Base module.
- A single Cinder volume module must include all Cinder volumes
needed by the Base/Incremental module.
-- 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).
+- 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
R-35727 The VNF Heat Orchestration Template **MUST** have a
corresponding environment file for an Incremental module.
-R-22656 The VNF Heat Orchestration Template **MUST** have a corresponding environment file
-for a Cinder Volume Module.
+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.
resource\_registry in the environment file is not supported and must not
be used.
-R-89868 The VNF Heat Orchestration Template **MUST** have unique file names within the scope
-of the VNF for a nested heat yaml file.
+R-89868 The VNF Heat Orchestration Template **MUST** have unique
+file names within the scope of the VNF for a nested heat yaml file.
-R-52530 The VNF Heat Orchestration Template **MUST NOT** use a directory hierarchy for
-nested templates. All templates must be in a single, flat directory
-(per VNF).
+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 Orchestration Template **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 Orchestration Template **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
- template.
+- R-61183 The VNF Heat Orchestration Template **MUST NOT**
+ change the parameter names, when OS::Nova::Server metadata
+ parameters are past into a nested heat template.
- With nested templates, outputs are required to expose any resource
properties of the child templates to the parent template. Those would
Support for Heat Files is subject to the following limitations:
-R-76718 The VNF Heat Orchestration Template **MUST** reference the get\_files targets in
-Heat templates by file name, and the corresponding files should be
-delivered to ONAP along with the Heat templates.
+R-76718 The VNF Heat Orchestration Template **MUST** reference
+the get\_files targets in Heat templates by file name, and the
+corresponding files should be delivered to ONAP along with the
+Heat templates.
R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
-R-62177 The VNF Heat Orchestration Template **MUST** have unique file names for the included
-files within the scope of the VNF.
+R-62177 The VNF Heat Orchestration Template **MUST** have unique
+file names for the included files within the scope of the VNF.
-R-87848 The VNF Heat Orchestration Template **MUST** have all included files in a single, flat
-directory per VNF. ONAP does not support a directory hierarchy.
+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.
Code Review / vnfrqts / requirements.git / blobdiff