1 **5. VNF Modeling Requirements**
2 =====================================
11 This reference document is the VNF TOSCA Template Requirements for
12 ONAP, which provides recommendations and standards for building VNF
13 TOSCA templates compatible with ONAP initial implementations of
14 Network Cloud. It has the following features:
16 1. VNF TOSCA template designer supports GUI and CLI.
18 2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
19 Draft 04-Revision 06”.
21 3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
22 Threading, SRIOV， etc.
27 This document is intended for persons developing VNF TOSCA templates
28 that will be orchestrated by ONAP.
33 ONAP implementations of Network Cloud supports TOSCA Templates, also
34 referred to as TOSCA in this document.
36 ONAP requires the TOSCA Templates to follow a specific format. This
37 document provides the mandatory, recommended, and optional requirements
38 associated with this format.
43 The document includes three charters to help the VNF vendors to use the
44 VNF model design tools and understand the VNF package structure and VNF
47 In the ONAP, VNF Package and VNFD template can be designed by manually
48 or via model designer tools. VNF model designer tools can provide the
49 GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD
52 The VNF package structure is align to the NFV TOSCA protocol, and
55 The VNFD and VNF package are all align to the NFV TOSCA protocol, which
56 supports multiple TOSCA template yaml files, and also supports
57 self-defined node or other extensions.
62 TOSCA templates supported by ONAP must follow the requirements
63 enumerated in this section.
68 TOSCA defines a Meta model for defining IT services. This Meta model
69 defines both the structure of a service as well as how to manage it. A
70 Topology Template (also referred to as the topology model of a service)
71 defines the structure of a service. Plans define the process models that
72 are used to create and terminate a service as well as to manage a
73 service during its whole lifetime.
75 A Topology Template consists of a set of Node Templates and Relationship
76 Templates that together define the topology model of a service as a (not
77 necessarily connected) directed graph. A node in this graph is
78 represented by a *Node Template*. A Node Template specifies the
79 occurrence of a Node Type as a component of a service. A *Node Type*
80 defines the properties of such a component (via *Node Type Properties*)
81 and the operations (via *Interfaces*) available to manipulate the
82 component. Node Types are defined separately for reuse purposes and a
83 Node Template references a Node Type and adds usage constraints, such as
84 how many times the component can occur.
87 Figure 1: Structural Elements of Service Template and their Relations
89 TOSCA Modeling Principles & Data Model
90 --------------------------------------
92 This section describing TOSCA modeling principles and data model for
93 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
94 V1.0], or new type based on ETSI NFV requirements, etc.
96 VNF Descriptor Template
97 -----------------------
99 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
100 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
101 Links, External Connection Points, Scaling Aspects, Instantiation Levels
102 and Deployment Flavours.
104 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
105 represents the contract & interface of a VNF and ensures the
106 interoperability across the NFV functional blocks.
108 The main parts of the VNFD are the following:
110 - VNF topology: it is modeled in a cloud agnostic way using virtualized
111 containers and their connectivity. Virtual Deployment Units (VDU)
112 describe the capabilities of the virtualized containers, such as
113 virtual CPU, RAM, disks; their connectivity is modeled with VDU
114 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
115 and VNF External Connection Point Descriptors (VnfExternalCpd);
117 - VNF deployment aspects: they are described in one or more deployment
118 flavours, including instantiation levels, supported LCM operations,
119 VNF LCM operation configuration parameters, placement constraints
120 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
121 and scaling aspect for horizontal scaling.
123 The following table defines the TOSCA Type “derived from” values that
124 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
125 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
127 +-----------------------------------------+---------------------------------------+-----------------------+
128 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
130 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
131 +=========================================+=======================================+=======================+
132 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
133 +-----------------------------------------+---------------------------------------+-----------------------+
134 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
135 +-----------------------------------------+---------------------------------------+-----------------------+
136 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
137 +-----------------------------------------+---------------------------------------+-----------------------+
138 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
139 +-----------------------------------------+---------------------------------------+-----------------------+
140 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
141 +-----------------------------------------+---------------------------------------+-----------------------+
142 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
143 +-----------------------------------------+---------------------------------------+-----------------------+
144 | Virtual Storage | | |
145 +-----------------------------------------+---------------------------------------+-----------------------+
146 | Virtual Compute | | |
147 +-----------------------------------------+---------------------------------------+-----------------------+
148 | Software Image | | |
149 +-----------------------------------------+---------------------------------------+-----------------------+
150 | Deployment Flavour | | |
151 +-----------------------------------------+---------------------------------------+-----------------------+
152 | Scaling Aspect | | |
153 +-----------------------------------------+---------------------------------------+-----------------------+
154 | Element Group | | |
155 +-----------------------------------------+---------------------------------------+-----------------------+
156 | Instantiation Level | | |
157 +-----------------------------------------+---------------------------------------+-----------------------+
159 +--------------------------------------------------------------------+
160 | +--------------------------------------------------------------+ |
161 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
163 | | description: VNFD TOSCA file demo | |
167 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
169 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
171 | | | **node\_types: | |
172 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
173 | | derived\_from:** tosca.nodes.nfv.VNF | |
174 | | | **requirements: | |
175 | | **- **sriov\_plane: | |
176 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
177 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
178 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
179 | +--------------------------------------------------------------+ |
180 +====================================================================+
181 +--------------------------------------------------------------------+
186 1. SR-IOV Passthrought
188 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
191 +------------------------------------------------+
200 | tosca\_name: SRIOV\_Port |
204 | virtual\_network\_interface\_requirements: |
208 | support\_mandatory: false |
210 | description: sriov |
218 | description: sriov port |
220 | layer\_protocol: ipv4 |
224 | - virtual\_binding: |
226 | capability: virtual\_binding |
232 | type: tosca.relationships.nfv.VirtualBindsTo |
236 | node: tosca.nodes.Root |
238 | type: tosca.nodes.nfv.VduCpd |
240 | substitution\_mappings: |
250 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
251 +------------------------------------------------+
255 Definitions of mem\_page\_size as one property shall be added to
256 Properties and set the value to large if one VDU node supports
257 huagepages. Here is an example.
259 +----------------------------------+
268 | tosca\_name: Huge\_pages\_demo |
272 | mem\_page\_size:large |
273 +==================================+
274 +----------------------------------+
278 Likewise, we shall add definitions of numa to
279 requested\_additional\_capabilities if we wand VUD nodes to support
280 NUMA. Here is an example.
282 +-------------------------------------------------+
283 | topology\_template: |
291 | virtual\_compute: |
297 | numa\_enabled: true |
299 | virtual\_mem\_size: 2 GB |
301 | requested\_additional\_capabilities: |
305 | support\_mandatory: true |
307 | requested\_additional\_capability\_name: numa |
309 | target\_performance\_parameters: |
311 | hw:numa\_nodes: "2" |
313 | hw:numa\_cpus.0: "0,1" |
315 | hw:numa\_mem.0: "1024" |
317 | hw:numa\_cpus.1: "2,3,4,5" |
319 | hw:numa\_mem.1: "1024" |
320 +-------------------------------------------------+
324 Definitions of Hyper-Theading are necessary as one of
325 requested\_additional\_capabilities of one VUD node if that node
326 supports Hyper-Theading. Here is an example.
328 +-------------------------------------------------------------+
329 | topology\_template: |
337 | virtual\_compute: |
343 | numa\_enabled: true |
345 | virtual\_mem\_size: 2 GB |
347 | requested\_additional\_capabilities: |
349 | hyper\_threading: |
351 | support\_mandatory: true |
353 | requested\_additional\_capability\_name: hyper\_threading |
355 | target\_performance\_parameters: |
357 | hw:cpu\_sockets : "2" |
359 | hw:cpu\_threads : "2" |
361 | hw:cpu\_cores : "2" |
363 | hw:cpu\_threads\_policy: "isolate" |
364 +-------------------------------------------------------------+
368 Definitions of ovs\_dpdk are necessary as one of
369 requested\_additional\_capabilities of one VUD node if that node
370 supports dpdk. Here is an example.
372 +------------------------------------------------------+
373 | topology\_template: |
381 | virtual\_compute: |
387 | numa\_enabled: true |
389 | virtual\_mem\_size: 2 GB |
391 | requested\_additional\_capabilities: |
395 | support\_mandatory: true |
397 | requested\_additional\_capability\_name: ovs\_dpdk |
399 | target\_performance\_parameters: |
401 | sw:ovs\_dpdk: "true" |
402 +------------------------------------------------------+
404 NFV TOSCA Type Definition
405 -------------------------
407 tosca.capabilites.nfv.VirtualCompute
408 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
410 +---------------------------+-----------------------------------------+
411 | **Shorthand Name** | VirtualCompute |
412 +===========================+=========================================+
413 | **Type Qualified Name** | tosca: VirtualCompute |
414 +---------------------------+-----------------------------------------+
415 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
416 +---------------------------+-----------------------------------------+
417 | **derived from** | tosca.nodes.Root |
418 +---------------------------+-----------------------------------------+
423 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
424 | Name | Required | Type | Constraints | Description |
425 +=====================================+============+=====================================================+===============+=========================================================+
426 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
427 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
428 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
429 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
430 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
431 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
432 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
434 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
439 +-----------------------------------------------------------+
440 | tosca.capabilities.nfv.VirtualCompute: |
442 | derived\_from: tosca.capabilities.Root |
446 | requested\_additional\_capabilities: |
452 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
458 | type: tosca.datatypes.nfv.VirtualMemory |
464 | type: tosca.datatypes.nfv.VirtualCpu |
467 +-----------------------------------------------------------+
469 tosca.nodes.nfv.VDU.Compute
470 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
472 The NFV Virtualization Deployment Unit (VDU) compute node type
473 represents a VDU entity which it describes the deployment and
474 operational behavior of a VNF component (VNFC), as defined by **[ETSI
477 +-----------------------+-------------------------------+
478 | Shorthand Name | VDU.Compute |
479 +=======================+===============================+
480 | Type Qualified Name | tosca:VDU.Compute |
481 +-----------------------+-------------------------------+
482 | Type URI | tosca.nodes.nfv.VDU.Compute |
483 +-----------------------+-------------------------------+
484 | derived\_from | tosca.nodes.Compute |
485 +-----------------------+-------------------------------+
498 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
499 | Name | Type | Constraints | Description |
500 +=========================+=================================================+===============+=====================================================================================================+
501 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
502 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
503 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
505 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
506 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
507 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
509 | | editor note: need to create a capability type | | |
510 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
515 +-----------------------------------------------------------------------------------------------------+
516 | tosca.nodes.nfv.VDU.Compute: |
518 | derived\_from: tosca.nodes.Compute |
536 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
544 | nfvi\_constraints: |
554 | configurable\_properties: |
560 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
566 | private\_address: |
568 | status: deprecated |
572 | status: deprecated |
576 | status: deprecated |
580 | status: deprecated |
584 | virtual\_compute: |
586 | type: tosca.capabilities.nfv.VirtualCompute |
588 | virtual\_binding: |
590 | type: tosca.capabilities.nfv.VirtualBindable |
592 | #monitoring\_parameter: |
594 | # modeled as ad hoc (named) capabilities in VDU node template |
600 | # cpu\_load: tosca.capabilities.nfv.Metric |
602 | # memory\_usage: tosca.capabilities.nfv.Metric |
604 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
606 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
608 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
610 | occurrences: [0,UNBOUNDED] |
614 | occurrences: [0,0] |
618 | occurrences: [0,0] |
620 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
622 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
626 | occurrences: [0,UNBOUND] |
630 | - virtual\_storage: |
632 | capability: tosca.capabilities.nfv.VirtualStorage |
634 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
636 | node: tosca.nodes.nfv.VDU.VirtualStorage |
638 | occurences: [ 0, UNBOUNDED ] |
640 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
642 | occurrences: [0,0] |
650 | type: tosca.artifacts.nfv.SwImage |
651 +-----------------------------------------------------------------------------------------------------+
655 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
656 | Name | Required | Type | Constraints | Description |
657 +===========+============+===============================+===============+================================================+
658 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
659 | | | | | directly realizing this virtual storage |
660 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
670 The TOSCA Cpd node represents network connectivity to a compute resource
671 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
672 used as parent for the various Cpd types.
674 +-----------------------+-----------------------+
675 | Shorthand Name | Cpd |
676 +=======================+=======================+
677 | Type Qualified Name | tosca:Cpd |
678 +-----------------------+-----------------------+
679 | Type URI | tosca.nodes.nfv.Cpd |
680 +-----------------------+-----------------------+
686 +--------+------------+--------+---------------+---------------+
687 | Name | Required | Type | Constraints | Description |
688 +========+============+========+===============+===============+
689 +--------+------------+--------+---------------+---------------+
704 +----------------------------------------------------------------------+
705 | tosca.nodes.nfv.Cpd: |
707 | derived\_from: tosca.nodes.Root |
717 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
721 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
727 | - valid\_values: [ root, leaf ] |
743 | type: tosca.datatype.nfv.AddressData |
746 +----------------------------------------------------------------------+
748 Additional Requirement
749 ^^^^^^^^^^^^^^^^^^^^^^
753 tosca.nodes.nfv.VduCpd
754 ~~~~~~~~~~~~~~~~~~~~~~
756 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
757 network connectivity between a VNFC instance (based on this VDU) and an
758 internal VL as defined by [ETSI GS NFV-IFA 011].
760 +-----------------------+--------------------------+
761 | Shorthand Name | VduCpd |
762 +=======================+==========================+
763 | Type Qualified Name | tosca: VduCpd |
764 +-----------------------+--------------------------+
765 | Type URI | tosca.nodes.nfv.VduCpd |
766 +-----------------------+--------------------------+
772 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
773 | Name | Required | Type | Constraints | Description |
774 +===============================+============+==========================================+==========================================================================+
775 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
776 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
777 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
778 | requirements | | | | realising the CPs instantiated from this CPD |
779 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
789 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
790 | Name | Required | Type | Constraints | Description |
791 +====================+============+==========================================+===============+==========================================================+
792 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
793 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
794 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
795 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
800 +----------------------------------------------------------------+
801 | tosca.nodes.nfv.VduCpd: |
803 | derived\_from: tosca.nodes.nfv.Cpd |
807 | bitrate\_requirement: |
813 | virtual\_network\_interface\_requirements |
819 | type: VirtualNetworkInterfaceRequirements |
827 | capability: tosca.capabilities.nfv.VirtualLinkable |
829 | relationship: tosca.relationships.nfv.VirtualLinksTo |
831 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
833 | capability: tosca.capabilities.nfv.VirtualBindable |
835 | relationship: tosca.relationships.nfv.VirtualBindsTo |
837 | node: tosca.nodes.nfv.VDU |
838 +----------------------------------------------------------------+
840 tosca.nodes.nfv.VDU.VirtualStorage
841 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
843 The NFV VirtualStorage node type represents a virtual storage entity
844 which it describes the deployment and operational behavior of a virtual
845 storage resources, as defined by **[ETSI NFV IFA011].**
847 **[editor note]** open issue: should NFV profile use the current storage
848 model as described in YAML 1.1. Pending on Shitao proposal (see
849 NFVIFA(17)000110 discussion paper)
851 **[editor note]** new relationship type as suggested in Matt
852 presentation. Slide 8. With specific rules of “valid\_target\_type”
854 +---------------------------+--------------------------------------+
855 | **Shorthand Name** | VirtualStorage |
856 +===========================+======================================+
857 | **Type Qualified Name** | tosca: VirtualStorage |
858 +---------------------------+--------------------------------------+
859 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
860 +---------------------------+--------------------------------------+
861 | **derived\_from** | tosca.nodes.Root |
862 +---------------------------+--------------------------------------+
864 tosca.artifacts.nfv.SwImage
865 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
867 +---------------------------+------------------------------------+
868 | **Shorthand Name** | SwImage |
869 +===========================+====================================+
870 | **Type Qualified Name** | tosca:SwImage |
871 +---------------------------+------------------------------------+
872 | **Type URI** | tosca.artifacts.nfv.SwImage |
873 +---------------------------+------------------------------------+
874 | **derived\_from** | tosca.artifacts.Deployment.Image |
875 +---------------------------+------------------------------------+
880 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
881 | Name | Required | Type | Constraints | Description |
882 +==========================================+============+====================+===============+====================================================================================================+
883 | name | yes | string | | Name of this software image |
884 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
885 | version | yes | string | | Version of this software image |
886 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
887 | checksum | yes | string | | Checksum of the software image file |
888 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
889 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
890 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
891 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
892 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
893 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
894 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
895 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
896 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
897 | Size | yes | scalar-unit.size | | The size of this software image |
898 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
899 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
900 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
901 | operating\_system | no | string | | Identifies the operating system used in the software image. |
902 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
903 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
904 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
909 +-----------------------------------------------------+
910 | tosca.artifacts.nfv.SwImage: |
912 | derived\_from: tosca.artifacts.Deployment.Image |
914 | properties or metadata: |
938 | container\_format: |
952 | type: scalar-unit.size # Number |
958 | type: scalar-unit.size # Number |
964 | type: scalar-unit.size # Number |
974 | operating\_system: |
980 | supported\_virtualisation\_environments: |
989 +-----------------------------------------------------+
994 openovnf\_\_vOpenNAT.yaml
995 ~~~~~~~~~~~~~~~~~~~~~~~~~
997 +-------------------------------------------------------------+
1000 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1002 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1004 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1006 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1008 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1010 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1012 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1014 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1016 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1018 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1020 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1022 | - openonfv\_\_tosca.capabilities.Container.yaml |
1024 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1026 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1028 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1030 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1032 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1034 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1036 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1040 | vnfProductName: openNAT |
1042 | vnfdVersion: 1.0.0 |
1044 | vnfProvider: intel |
1048 | csarVersion: 1.0.0 |
1050 | vnfdId: openNAT-1.0 |
1052 | csarProvider: intel |
1054 | vnfProductInfoDescription: openNAT |
1062 | localizationLanguage: '[english, chinese]' |
1066 | defaultLocalizationLanguage: english |
1068 | vnfProductInfoName: openNAT |
1070 | vnfSoftwareVersion: 1.0.0 |
1072 | topology\_template: |
1074 | node\_templates: |
1082 | file: /swimages/xenial-snat.qcow2 |
1084 | type: tosca.artifacts.nfv.SwImage |
1088 | name: vNatVNFImage |
1092 | checksum: "5000" |
1094 | container\_format: bare |
1096 | disk\_format: qcow2 |
1098 | min\_disk: 10 GB |
1104 | sw\_image: /swimages/xenial-snat.qcow2 |
1106 | operating\_system: unbantu |
1110 | tosca\_name: vdu\_vNat |
1114 | virtual\_compute: |
1118 | virtual\_memory: |
1120 | numa\_enabled: true |
1122 | virtual\_mem\_size: 2 GB |
1124 | requested\_additional\_capabilities: |
1128 | support\_mandatory: true |
1130 | requested\_additional\_capability\_name: numa |
1132 | target\_performance\_parameters: |
1134 | hw:numa\_nodes: "2" |
1136 | hw:numa\_cpus.0: "0,1" |
1138 | hw:numa\_mem.0: "1024" |
1140 | hw:numa\_cpus.1: "2,3,4,5" |
1142 | hw:numa\_mem.1: "1024" |
1144 | hyper\_threading: |
1146 | support\_mandatory: true |
1148 | requested\_additional\_capability\_name: hyper\_threading |
1150 | target\_performance\_parameters: |
1152 | hw:cpu\_sockets : "2" |
1154 | hw:cpu\_threads : "2" |
1156 | hw:cpu\_cores : "2" |
1158 | hw:cpu\_threads\_policy: "isolate" |
1162 | support\_mandatory: true |
1164 | requested\_additional\_capability\_name: ovs\_dpdk |
1166 | target\_performance\_parameters: |
1168 | sw:ovs\_dpdk: "true" |
1172 | cpu\_architecture: X86 |
1174 | num\_virtual\_cpu: 2 |
1178 | configurable\_properties: |
1182 | additional\_vnfc\_configurable\_properties: |
1188 | descrption: the virtual machine of vNat |
1196 | - virtual\_storage: |
1198 | capability: virtual\_storage |
1200 | node: vNAT\_Storage |
1206 | location: /mnt/volume\_0 |
1208 | type: tosca.relationships.nfv.VDU.AttachedTo |
1210 | - local\_storage: |
1212 | node: tosca.nodes.Root |
1214 | type: tosca.nodes.nfv.VDU.Compute |
1220 | tosca\_name: SRIOV\_Port |
1224 | virtual\_network\_interface\_requirements: |
1228 | support\_mandatory: false |
1230 | description: sriov |
1238 | description: sriov port |
1240 | layer\_protocol: ipv4 |
1244 | - virtual\_binding: |
1246 | capability: virtual\_binding |
1252 | type: tosca.relationships.nfv.VirtualBindsTo |
1254 | - virtual\_link: |
1256 | node: tosca.nodes.Root |
1258 | type: tosca.nodes.nfv.VduCpd |
1264 | tosca\_name: vNAT\_Storage |
1268 | id: vNAT\_Storage |
1270 | size\_of\_storage: 10 GB |
1272 | rdma\_enabled: false |
1274 | type\_of\_storage: volume |
1276 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1278 | substitution\_mappings: |
1288 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1290 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1291 +-------------------------------------------------------------+
1293 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1294 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1296 +------------------------------------------------------------+
1299 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1303 | tosca.nodes.nfv.VDU.VirtualStorage: |
1307 | virtual\_storage: |
1309 | type: tosca.capabilities.nfv.VirtualStorage |
1311 | derived\_from: tosca.nodes.Root |
1319 | size\_of\_storage: |
1329 | type\_of\_storage: |
1333 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1334 +------------------------------------------------------------+
1336 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1337 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1339 +-----------------------------------------------------------------+
1342 | tosca.datatypes.nfv.L3AddressData: |
1346 | number\_of\_ip\_address: |
1352 | ip\_address\_assignment: |
1356 | ip\_address\_type: |
1360 | - valid\_values: |
1370 | floating\_ip\_activated: |
1374 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1384 | support\_mandatory: |
1402 | tosca.datatype.nfv.AddressData: |
1410 | - valid\_values: |
1418 | l2\_address\_data: |
1422 | type: tosca.datatypes.nfv.L2AddressData |
1424 | l3\_address\_data: |
1428 | type: tosca.datatypes.nfv.L3AddressData |
1430 | tosca.datatypes.nfv.L2AddressData: {} |
1434 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1436 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1440 | tosca.nodes.nfv.VduCpd: |
1442 | derived\_from: tosca.nodes.Root |
1446 | virtual\_network\_interface\_requirements: |
1450 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1460 | - valid\_values: |
1470 | bitrate\_requirement: |
1482 | layer\_protocol: |
1486 | - valid\_values: |
1506 | type: tosca.datatype.nfv.AddressData |
1514 | - virtual\_binding: |
1516 | capability: tosca.capabilities.nfv.VirtualBindable |
1524 | - virtual\_link: |
1526 | capability: tosca.capabilities.nfv.VirtualBindable |
1534 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1535 +-----------------------------------------------------------------+
1537 .. |image1| image:: Image1.png
1540 .. |image2| image:: Image2.png
1554 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1555 Markup Language) is a human friendly data serialization standard for all
1556 programming languages. See http://www.yaml.org/.
1558 Heat Orchestration Template Format
1559 ----------------------------------
1561 Heat Orchestration templates must be defined in YAML.
1565 - Tabs are NOT allowed, use spaces ONLY.
1567 - You MUST indent your properties and lists with 1 or more spaces.
1569 - All Resource IDs and resource property parameters are case-sensitive.
1570 (e.g., "ThIs", is not the same as "thiS")
1572 Heat Orchestration Template Structure
1573 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1575 Heat Orchestration template structure follows the following format, as
1576 defined by OpenStack at
1577 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1579 .. code-block:: yaml
1581 heat_template_version: <date>
1584 # a description of the template
1587 # a declaration of input parameter groups and order
1590 # declaration of input parameters
1593 # declaration of template resources
1596 # declaration of output parameters
1599 # declaration of conditions
1602 Heat Orchestration templates for ONAP must contain the following
1605 - heat\_template\_version:
1613 Heat Orchestration templates for ONAP may contain the following
1616 - parameter\_groups:
1620 heat\_template\_version
1621 ^^^^^^^^^^^^^^^^^^^^^^^
1623 This section is ONAP mandatory. The heat\_template\_version must be set
1624 to a date that is supported by the OpenStack environment.
1629 This ONAP mandatory section allows for a description of the template.
1634 This ONAP optional section allows for specifying how the input
1635 parameters should be grouped and the order to provide the parameters in.
1640 The parameter section is ONAP mandatory. This section allows for
1641 specifying input parameters that have to be provided when instantiating
1642 the template. Each parameter is specified in a separated nested block
1643 with the name of the parameters defined in the first line and additional
1644 attributes (e.g., type, label) defined as nested elements.
1646 The Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process
1647 requires all parameters declared in a template to be used in a resource
1648 with the exception of the parameters for the OS::Nova::Server property
1649 availability\_zone. See `Property: availability\_zone`_. for more details on
1652 .. code-block:: yaml
1656 type: <string | number | json | comma_delimited_list | boolean>
1657 label: <human-readable name of the parameter>
1658 description: <description of the parameter>
1659 default: <default value for parameter>
1660 hidden: <true | false>
1662 <parameter constraints>
1663 immutable: <true | false>
1667 - The name of the parameter.
1669 - ONAP requires that the param name must contain only alphanumeric
1670 characters and “\_” underscores. Special characters must not be
1675 - The type of the parameter. Supported types are string, number,
1676 comma\_delimited\_list, json and boolean.
1678 - This attribute must be provided per the OpenStack Heat
1679 Orchestration Template standard.
1683 - A human readable name for the parameter.
1685 - This attribute is optional.
1689 - A human readable description for the parameter.
1691 - This attribute is ONAP mandatory; it must be provided. (Note that
1692 this attribute is OpenStack optional.)
1696 - A default value for the parameter.
1698 - ONAP does not support this attribute; it *must not* be provided in
1699 the Heat Orchestration Template. If a parameter has a default
1700 value, it must be provided in the environment file. (Note that
1701 this attribute is OpenStack optional.)
1705 - Defines whether the parameters should be hidden when a user
1706 requests information about a stack created from the template. This
1707 attribute can be used to hide passwords specified as parameters.
1709 - This attribute is optional and defaults to false.
1713 - A list of constraints to apply. The constraints block of a
1714 parameter definition defines additional validation constraints
1715 that apply to the value of the parameter. The parameter values
1716 provided in the Heat Orchestration Template are validated against
1717 the constraints at instantiation time. The constraints are defined
1718 as a list with the following syntax
1722 - <constraint type>: <constraint definition>
1724 description: <constraint description>
1726 - constraint type: Type of constraint to apply.
1728 - constraint definition: The actual constraint, depending on the
1731 - description: A description of the constraint. The text is presented
1732 to the user when the value the user defines violates the constraint.
1733 If omitted, a default validation message is presented to the user.
1734 This attribute is optional.
1736 - When the parameter type is set to number, the Heat Orchestration
1737 Template uploaded into ONAP must have constraints for range or
1740 - range: The range constraint applies to parameters of type number.
1741 It defines a lower and upper limit for the numeric value of the
1742 parameter. The syntax of the range constraint is
1744 range: { min: <lower limit>, max: <upper limit> }
1746 It is possible to define a range constraint with only a lower limit
1749 - allowed\_values: The allowed\_values constraint applies to parameters
1750 of type string or number. It specifies a set of possible values for a
1751 parameter. At deployment time, the user-provided value for the
1752 respective parameter must match one of the elements of the list. The
1753 syntax of the allowed\_values constraint is
1755 allowed\_values: [ <value>, <value>, ... ]
1757 Alternatively, the following YAML list notation can be used
1767 - Other <constraint type> are optional, they may be used (e.g., length,
1768 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1771 - Note that constrains must not be defined for any parameter enumerated
1772 in a nested heat template.
1774 - Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
1778 - Defines whether the parameter is updatable. Stack update fails, if
1779 this is set to true and the parameter value is changed.
1781 - This attribute is optional and defaults to false.
1786 This section is ONAP mandatory; it must be provided. This section
1787 contains the declaration of the single resources of the template. This
1788 section with at least one resource must be defined in the Heat
1789 Orchestration Template, or the template would not create any resources
1790 when being instantiated.
1792 Each resource is defined as a separate block in the resources section
1793 with the following syntax.
1795 .. code-block:: yaml
1799 type: <resource type>
1801 <property name>: <property value>
1803 <resource specific metadata>
1804 depends\_on: <resource ID or list of ID>
1805 update\_policy: <update policy>
1806 deletion\_policy: <deletion policy>
1807 external\_id: <external resource ID>
1808 condition: <condition name or expression or boolean>
1812 - A resource ID that must be unique within the resources section of
1813 the Heat Orchestration Template.
1815 - ONAP requires that the resource ID must be unique across all Heat
1816 Orchestration Templates that compose the VNF. This requirement
1817 also applies when a VNF is composed of more than one Heat
1818 Orchestration Template (see ONAP VNF Modularity Overview).
1820 - The naming convention for a resource ID is provided in `Resource IDs`_.
1824 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1825 Note that the type may specify a nested heat file. This attribute
1830 - A list of resource-specific properties. The property value can be
1831 provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
1833 - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
1837 - Resource-specific metadata. This section is optional, except for
1838 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1842 - Dependencies of the resource on one or more resources of the
1843 template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
1847 - Update policy for the resource, in the form of a nested
1848 dictionary. Whether update policies are supported and what the
1849 exact semantics are depends on the type of the current resource.
1850 This attribute is optional.
1854 - Deletion policy for the resource. The allowed deletion policies
1855 are Delete, Retain, and Snapshot. Beginning with
1856 heat\_template\_version 2016-10-14, the lowercase equivalents
1857 delete, retain, and snapshot are also allowed. This attribute is
1858 optional; the default policy is to delete the physical resource
1859 when deleting a resource from the stack.
1863 - Allows for specifying the resource\_id for an existing external
1864 (to the stack) resource. External resources cannot depend on other
1865 resources, but we allow other resources to depend on external
1866 resource. This attribute is optional. Note: when this is
1867 specified, properties will not be used for building the resource
1868 and the resource is not managed by Heat. This is not possible to
1869 update that attribute. Also, resource won’t be deleted by heat
1870 when stack is deleted.
1874 - Condition for the resource. The condition decides whether to
1875 create the resource or not. This attribute is optional.
1880 This ONAP optional section allows for specifying output parameters
1881 available to users once the template has been instantiated. If the
1882 section is specified, it will need to adhere to specific requirements.
1883 See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
1885 Environment File Format
1886 -----------------------
1888 The environment file is a yaml text file.
1889 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1891 The environment file can contain the following sections:
1893 - parameters: A list of key/value pairs.
1895 - resource\_registry: Definition of custom resources.
1897 - parameter\_defaults: Default parameters passed to all template
1900 - encrypted\_parameters: List of encrypted parameters.
1902 - event\_sinks: List of endpoints that would receive stack events.
1904 - parameter\_merge\_strategies: Merge strategies for merging parameters
1905 and parameter defaults from the environment file.
1907 Environment files for ONAP must contain the following sections:
1911 Environment files for ONAP may contain the following sections:
1913 - resource\_registry:
1915 - parameter\_defaults:
1917 - encrypted\_parameters:
1921 - parameter\_merge\_strategies:
1923 The use of an environment file in OpenStack is optional. In ONAP, it is
1924 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
1925 corresponding environment file, even if no parameters are enumerated in
1926 the mandatory parameter section.
1928 (Note that ONAP, the open source version of ONAP, does not
1929 programmatically enforce the use of an environment file.)
1931 SDC Treatment of Environment Files
1932 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1934 Parameter values enumerated in the environment file are used by SDC as
1935 the default value. However, the SDC user may use the SDC GUI to
1936 overwrite the default values in the environment file.
1938 SDC generates a new environment file for distribution to MSO based on
1939 the uploaded environment file and the user provided GUI updates. The
1940 user uploaded environment file is discarded when the new file is
1943 ONAP has requirements for what parameters must be enumerated in the
1944 environment file and what parameter must not be enumerated in the
1945 environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1947 Nested Heat Orchestration Templates Overview
1948 --------------------------------------------
1950 ONAP supports nested Heat Orchestration Templates per OpenStack
1953 A Base Module may utilize nested templates.
1955 An Incremental Module may utilize nested templates.
1957 A Cinder Volume Module may utilize nested templates.
1959 A nested template must not define parameter constraints in the parameter
1962 Nested templates may be suitable for larger VNFs that contain many
1963 repeated instances of the same VM type(s). A common usage pattern is to
1964 create a nested template for each VM type along with its supporting
1965 resources. The Heat Orchestration Template may then reference these
1966 nested templates either statically (by repeated definition) or
1967 dynamically (via OS::Heat::ResourceGroup).
1969 See `Nested Heat Templates`_ for additional details.
1971 ONAP Heat Orchestration Template Filenames
1972 ------------------------------------------
1974 In order to enable ONAP to understand the relationship between Heat
1975 files, the following Heat file naming convention must be utilized.
1977 In the examples below, <text> represents any alphanumeric string that
1978 must not contain any special characters and must not contain the word
1984 The file name for the base module must include “base” in the filename
1985 and must match one of the following options:
1987 - base\_<text>.y[a]ml
1989 - <text>\_base.y[a]ml
1993 - <text>\_base\_<text>.y[a]ml
1995 The base module’s corresponding environment file must be named identical
1996 to the base module with “.y[a]ml” replaced with “.env”.
2001 There is no explicit naming convention for the incremental modules. As
2002 noted above, <text> represents any alphanumeric string that must not
2003 contain any special characters and must not contain the word “base”.
2007 The incremental module’s corresponding environment file must be named
2008 identical to the incremental module with “.y[a]ml” replaced with “.env”.
2010 To clearly identify the incremental module, it is recommended to use the
2011 following naming options for modules:
2013 - module\_<text>.y[a]ml
2015 - <text>\_module.y[a]ml
2019 Cinder Volume Modules
2020 ~~~~~~~~~~~~~~~~~~~~~
2022 The file name for the Cinder volume module must be named the same as the
2023 corresponding module it is supporting (base module or incremental
2024 module) with “\_volume” appended
2026 - <base module name>\_volume.y[a]ml
2028 - <incremental module name>\_volume.y[a]ml
2030 The volume module’s corresponding environment file must be named
2031 identical to the volume module with “.y[a]ml” replaced with “.env”.
2036 There is no explicit naming convention for nested Heat files with the
2037 following exceptions; the name should contain “nest”. As noted above,
2038 <text> represents any alphanumeric string that must not contain any
2039 special characters and must not contain the word “base”.
2043 Nested Heat files do not have corresponding environment files, per
2044 OpenStack specifications. All parameter values associated with the
2045 nested heat file must be passed in as properties in the resource
2046 definition defined in the parent heat template.
2048 ONAP Parameter Classifications Overview
2049 ---------------------------------------
2051 In order for ONAP to support workflow automation, Heat Orchestration
2052 Template resource property parameters must adhere to specific naming
2053 conventions and requirements.
2055 Broadly, ONAP categorizes parameters into four categories:
2057 1. ONAP metadata parameters
2059 2. Instance specific parameters
2061 3. Constant parameters
2063 4. Output parameters.
2065 ONAP Metadata Parameters
2066 ~~~~~~~~~~~~~~~~~~~~~~~~
2068 There are both mandatory and optional ONAP metadata parameters
2069 associated with the resource OS::Nova::Server.
2071 - ONAP metadata parameters must not have parameter constraints defined.
2073 - Both mandatory and optional (if specified) ONAP metadata parameter
2074 names must follow the ONAP metadata parameter naming convention.
2076 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
2078 Instance specific parameters
2079 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2081 The instance specific parameters are VNF instance specific. The value of
2082 the parameter will be different for every instance of a VNF (e.g., IP
2083 address). The instance specific parameters are subdivided into two
2084 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2087 ONAP Orchestration Parameters
2088 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2090 ONAP Orchestration Parameters are per instance parameters where the
2091 value is assigned via ONAP automation. (Note that in some cases,
2092 automation is currently not available and the value is loaded into ONAP
2093 prior to instantiation.)
2095 - ONAP orchestration parameters must not be enumerated in the
2098 - When the ONAP orchestration parameter type is set to number, the
2099 parameter must have constraints for range and/or allowed\_values.
2101 - Parameter constraints for ONAP orchestration parameters are optional
2102 for all parameter types other than number. If constraints are
2103 specified, they must adhere to the OpenStack specifications.
2105 - The ONAP orchestration parameter names must follow the ONAP
2106 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2109 VNF Orchestration Parameters
2110 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2112 VNF Orchestration Parameters are per instance parameters where the
2113 values are assigned manually. They are not supported by ONAP automation.
2114 The per instance values are loaded into ONAP prior to VNF instantiation.
2116 - VNF orchestration parameters must not be enumerated in the
2119 - When the VNF orchestration parameter type is set to number, the
2120 parameter must have constraints for range or allowed\_values.
2122 - Parameter constraints for VNF orchestration parameters are optional
2123 for all parameter types other than number. If constraints are
2124 specified, they must adhere to the OpenStack specifications.
2126 - The VNF orchestration parameter names should follow the VNF
2127 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2133 The constant parameters are parameters that remain constant across many
2134 VNF instances (e.g., image, flavor). The constant parameters are
2135 subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
2137 ONAP Constant Parameters
2138 ^^^^^^^^^^^^^^^^^^^^^^^^
2140 - ONAP Constant Parameters must be enumerated in the environment file.
2141 These parameter values are not assigned by ONAP.
2143 - When the ONAP Constant Parameter type is set to number, the parameter
2144 must have constraints for range and/or allowed\_values.
2146 - Parameter constraints for ONAP constant parameters are optional for
2147 all parameter types other than number. If constraints are specified,
2148 they must adhere to the OpenStack specifications.
2150 - The ONAP Constant Parameter names must follow the ONAP orchestration
2151 parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2153 VNF Constant Parameters
2154 ^^^^^^^^^^^^^^^^^^^^^^^
2156 - VNF Constant Parameters must be enumerated in the environment file.
2157 These parameter values are not assigned by ONAP.
2159 - When the VNF Constant Parameters type is set to number, the parameter
2160 must have constraints for range and/or allowed\_values.
2162 - Parameter constraints for ONAP constant parameters are optional for
2163 all parameter types other than number. If constraints are specified,
2164 they must adhere to the OpenStack specifications.
2166 - The VNF Constant Parameters names should follow the ONAP
2167 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2173 The output parameters are parameters defined in the output section of a
2174 Heat Orchestration Template. The ONAP output parameters are subdivided
2175 into three categories:
2177 1. ONAP Base Module Output Parameters
2179 2. ONAP Volume Module Output Parameters
2181 3. ONAP Predefined Output Parameters.
2183 ONAP Base Module Output Parameters
2184 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2186 ONAP Base Module Output Parameters are declared in the outputs: section
2187 of the base module Heat Orchestration Template. A Base Module Output
2188 Parameter is available as an input parameter (i.e., declared in the
2189 “parameters:” section) to all incremental modules in the VNF.
2191 - A Base Module Output Parameter may be used as an input parameter in
2192 an incremental module.
2194 - The Output parameter name and type must match the input parameter
2195 name and type unless the Output parameter is of the type
2196 comma\_delimited\_list.
2198 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2199 a collection of UUIDs from a Resource Group), then the
2200 corresponding input parameter must be declared as type json and
2201 not a comma\_delimited\_list, which is actually a string value
2202 with embedded commas.
2204 - When a Base Module Output Parameter is declared as an input parameter
2205 in an incremental module Heat Orchestration Template, parameter
2206 constraints must not be declared.
2208 Additional details on ONAP Base Module Output Parameters are provided in
2209 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2211 ONAP Volume Module Output Parameters
2212 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2214 The volume template output parameters are only available for the module
2215 (base or add on) that the volume is associated with.
2217 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2218 section of the Cinder volume module Heat Orchestration Template
2220 - An ONAP Volume Module Output Parameter is available as an input
2221 parameter (i.e., declared in the parameters: section) only for the
2222 module (base or incremental) that the Cinder volume module is
2223 associated with. The Output parameter name and type must match the
2224 input parameter name and type unless the Output parameter is of the
2225 type comma\_delimited\_list.
2227 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2228 collection of UUIDs from a Resource Group), then the corresponding
2229 input parameter must be declared as type json and not a
2230 comma\_delimited\_list, which is actually a string value with
2233 - When an ONAP Volume Module Output Parameter is declared as an input
2234 parameter in a base module or incremental module, parameter
2235 constraints must not be declared.
2237 Additional details on ONAP Base Module Output Parameters are provided in
2238 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2240 ONAP Predefined Output Parameters
2241 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2243 ONAP will look for a small set of pre-defined Heat output parameters to
2244 capture resource attributes for inventory in ONAP. These output
2245 parameters are optional and are specified in `OAM Management IP Addresses`_.
2247 Support of heat stack update
2248 ----------------------------
2250 VNF Heat Orchestration Templates must not be designed to utilize the
2251 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2252 does not support the use of heat stack-update command for scaling.
2254 It is important to note that ONAP only supports heat stack-update for
2260 ONAP defines two types of networks: External Networks and Internal
2263 ONAP defines an external network in relation to the VNF and not with
2264 regard to the Network Cloud site. External networks may also be referred
2265 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2267 - VMs in another VNF or
2269 - an external gateway or router
2271 ONAP defines an internal network in relation to the VNF and not with
2272 regard to the Network Cloud site. Internal networks may also be referred
2273 to as “intra-VNF” networks or “private” networks. An internal network
2274 only connects VMs in a single VNF. It must not connect to other VNFs or
2275 an external gateway or router.
2280 VNF Heat Orchestration Templates must not include any resources for
2281 external networks connected to the VNF. External networks must be
2282 orchestrated separately, as independent, stand-alone VNF Heat
2283 Orchestration Templates, so they can be shared by multiple VNFs and
2284 managed independently.
2286 When the external network is created, it must be assigned a unique
2287 {network-role}. The {network-role} should describe the network (e.g.,
2288 oam). The {network-role} while unique to the LCP, can repeat across
2291 An External Network may be a Neutron Network or a Contrail Network
2293 External networks must be passed into the VNF Heat Orchestration
2294 Templates as parameters.
2296 - Neutron Network-id (UUID)
2298 - Neutron Network subnet ID (UUID)
2300 - Contrail Network Fully Qualified Domain Name (FQDN)
2302 ONAP enforces a naming convention for parameters associated with
2303 external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2305 Parameter values associated with an external network will be generated
2306 and/or assigned by ONAP at orchestration time. Parameter values
2307 associated with an external network must not be enumerated in the
2308 environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2310 VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
2311 when attaching VMs to an external network
2313 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2315 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2318 - Note that Neutron Floating IPs must not be used. ONAP does not
2319 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2321 - ONAP supports the property allowed\_address\_pairs in the resource
2322 OS::Neutron:Port and the property
2323 virtual\_machine\_interface\_allowed\_address\_pairs in
2324 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2325 of a virtual IP (VIP) address to a set of VMs.
2327 VNF Heat Orchestration Templates must pass the appropriate external
2328 network IDs into nested VM templates when nested Heat is used.
2333 The VNF Heat Orchestration Templates must include the resource(s) to
2334 create the internal network. The internal network must be either a
2335 Neutron Network or a Contrail Network.
2337 In the modular approach, internal networks must be created in the Base
2338 Module, with their resource IDs exposed as outputs (i.e., ONAP Base
2339 Module Output Parameters) for use by all incremental modules. If the
2340 Network resource ID is required in the base template, then a
2341 get\_resource must be used.
2343 When the internal network is created, it should be assigned a unique
2344 {network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
2347 VNFs may use **Cloud assigned IP addresses** or
2348 **predetermined static IPs** when attaching VMs to an internal network.
2350 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2352 - A predetermined static IP address is enumerated in the Heat
2353 environment file. Since an internal network is local to the VNF, IP
2354 addresses can be re-used at every VNF instance.
2356 - Note that Neutron Floating IPs must not be used. ONAP does not
2357 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2359 - ONAP supports the property allowed\_address\_pairs in the resource
2360 OS::Neutron:Port and the property
2361 virtual\_machine\_interface\_allowed\_address\_pairs in
2362 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2363 of a virtual IP (VIP) address to a set of VMs.
2365 ONAP does not programmatically enforce a naming convention for
2366 parameters for internal network. However, a naming convention is
2367 provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2369 ONAP Resource ID and Parameter Naming Convention
2370 ------------------------------------------------
2372 This section provides the ONAP naming requirements for
2376 2. Resource Property Parameters
2381 The Heat Orchestration Templates for a VNF must assign a VNF unique
2382 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2383 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2384 it does not have to be globally unique across all VNFs that ONAP
2387 Any parameter that is associated with a unique Virtual Machine type in
2388 the VNF must include {vm-type} as part of the parameter name.
2390 Any resource ID that is associated with a unique Virtual Machine type in
2391 the VNF must include {vm-type} as part of the resource ID.
2393 Note that {vm-type} must not be a substring of {network-role}. A
2394 substring of a string is another string that occurs "in". For example,
2395 "oam" is a substring of "oam\_protected". It will cause the
2396 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2397 produce erroneous error messages.
2399 The {vm-type} should not contain the string “\_int” or “int\_” or
2400 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2401 ICE Project) process to produce erroneous error messages.
2403 The {vm-type} must be the same case in all parameter names in the VNF.
2405 The {vm-type} must be the same case in all Resource IDs in the VNF.
2407 It is recommended that the {vm-type} case in the parameter names matches
2408 the {vm-type} case in the Resource IDs.
2410 There are two exceptions to the above rules:
2412 1. The six ONAP Metadata parameters must not be prefixed with a common
2413 {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
2414 *vf\_module\_id*, *vf\_module\_name, vm\_role*. The ONAP Metadata
2415 parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
2417 2. The parameter referring to the OS::Nova::Server property
2418 availability\_zone must not be prefixed with a common {vm-type}
2419 identifier. availability\_zone is described in `Property: availability_zone`_.
2424 The assignment of a {network-role} is discussed in `Networking`_.
2426 Any parameter that is associated with an external network must include
2427 the {network-role} as part of the parameter name.
2429 Any resource ID that is associated with an external network must include
2430 the {network-role} as part of the resource ID.
2432 Any parameter that is associated with an internal network must include
2433 int\_{network-role} as part of the parameter name.
2435 Any resource ID that is associated with an internal network must include
2436 int\_{network-role} as part of the resource ID.
2438 Note that {network-role} must not be a substring of {vm-type}. A
2439 substring of a string is another string that occurs "in". For example,
2440 "oam" is a substring of "oam\_protected". It will cause the
2441 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2442 produce erroneous error messages.
2444 The {network-role} should not contain the string “\_int” or “int\_” or
2445 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2446 ICE Project) process to produce erroneous error messages.
2448 The {network-role} must be the same case in all parameter names in the
2451 The {network-role} must be the same case in all Resource IDs in the VNF.
2453 It is recommended that the {network-role} case in the parameter names
2454 matches the {network-role} case in the Resource IDs.
2459 Heat Orchestration Template resources are described in `resources`_
2461 A resource ID that must be unique within the resources section of a Heat
2462 Orchestration Template. This is an OpenStack Requirement.
2464 When a VNF is composed of more than one Heat Orchestration Template
2465 (i.e., modules), ONAP requires that the resource ID must be unique
2466 across all modules that compose the VNF.
2468 When a resource is associated with a single {vm-type}, the resource ID
2469 must contain {vm-type}.
2471 When a resource is associated with a single external network, the
2472 resource ID must contain {network-role}.
2474 When a resource is associated with a single internal network, the
2475 resource ID must contain int\_{network-role}.
2477 When a resource is associated with a single {vm-type} and a single
2478 external network, the resource ID must contain both the {vm-type} and
2481 - The {vm-type} must appear before the {network-role} and must be
2482 separated by an underscore (i.e., {vm-type}\_{network-role}).
2484 - Note that an {index} value may separate the {vm-type} and the
2485 {network-role}. An underscore will separate the three values (i.e.,
2486 {vm-type}\_{index}\_{network-role}).
2488 When a resource is associated with a single {vm-type} and a single
2489 internal network, the resource ID must contain both the {vm-type} and
2490 int\_{network-role}.
2492 - The {vm-type} must appear before the int\_{network-role} and must be
2493 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2495 - Note that an {index} value may separate the {vm-type} and the
2496 int\_{network-role}. An underscore will separate the three values
2497 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2499 When a resource is associated with more than one {vm-type} and/or more
2500 than one network, the resource ID
2502 - must not contain the {vm-type} and/or
2503 {network-role}/int\_{network-role}
2505 - should contain the term “shared” and/or contain text that identifies
2508 Only alphanumeric characters and “\_” underscores must be used in the
2509 resource ID. Special characters must not be used.
2511 All {index} values must be zero based. That is, the {index} must start
2512 at zero and increment by one.
2514 The table below provides example OpenStack Heat resource ID for
2515 resources only associated with one {vm-type} and/or one network.
2517 +--------------------------------+------------------------------------------------------------+
2518 | Resource Type | Resource ID Format |
2519 +================================+============================================================+
2520 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2521 +--------------------------------+------------------------------------------------------------+
2522 | OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
2523 +--------------------------------+------------------------------------------------------------+
2524 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2525 +--------------------------------+------------------------------------------------------------+
2526 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2527 +--------------------------------+------------------------------------------------------------+
2528 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2529 +--------------------------------+------------------------------------------------------------+
2530 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2531 +--------------------------------+------------------------------------------------------------+
2532 | OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
2533 +--------------------------------+------------------------------------------------------------+
2534 | | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
2535 +--------------------------------+------------------------------------------------------------+
2536 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2537 +--------------------------------+------------------------------------------------------------+
2538 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2539 +--------------------------------+------------------------------------------------------------+
2540 | OS::Nova::Server | {vm\_type}\_{index} |
2541 +--------------------------------+------------------------------------------------------------+
2542 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2543 +--------------------------------+------------------------------------------------------------+
2544 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2545 +--------------------------------+------------------------------------------------------------+
2547 Table 1: Example OpenStack Heat Resource ID
2549 The table below provides example Contrail Heat resource ID for resources
2550 only associated with one {vm-type} and/or one network.
2552 +-------------------------------------------+---------------------------------------------+
2553 | Resource Type | Resource ID Format |
2554 +===========================================+=============================================+
2555 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
2556 +-------------------------------------------+---------------------------------------------+
2557 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2558 +-------------------------------------------+---------------------------------------------+
2559 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2560 +-------------------------------------------+---------------------------------------------+
2561 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2562 +-------------------------------------------+---------------------------------------------+
2563 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2564 +-------------------------------------------+---------------------------------------------+
2565 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2566 +-------------------------------------------+---------------------------------------------+
2567 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2568 +-------------------------------------------+---------------------------------------------+
2569 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2570 +-------------------------------------------+---------------------------------------------+
2572 Table 2: Example Contrail Heat resource ID
2574 Resource: OS::Nova::Server - Parameters
2575 ---------------------------------------
2577 The resource OS::Nova::Server manages the running virtual machine (VM)
2578 instance within an OpenStack cloud. (See
2579 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2581 Four properties of this resource must follow the ONAP parameter naming
2582 convention. The four properties are:
2590 4. availability\_zone
2592 The table below provides a summary. The sections that follow provides
2595 Note that the {vm\_type} must be identical across all four property
2596 parameter for a given OS::Nova::Server resource.
2598 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2599 | Resource OS::Nova::Server |
2600 +=============================+===============================+==================+==============================+=================================+
2601 | Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
2602 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2603 | image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
2604 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2605 | flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
2606 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2607 | name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
2608 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2609 | | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
2610 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2611 | availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
2612 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2614 Table 3 Resource Property Parameter Names
2619 The parameter associated with the property image is an ONAP Constant
2622 The parameters must be named {vm-type}\_image\_name in the Heat
2623 Orchestration Template.
2625 The parameter must be declared as type: string
2627 The parameter must be enumerated in the Heat Orchestration Template
2630 Each VM type (i.e., {vm-type}) must have a separate parameter for image,
2631 even if more than one {vm-type} shares the same image. This provides
2632 maximum clarity and flexibility.
2634 *Example Parameter Definition*
2636 .. code-block:: yaml
2639 {vm-type}_image_name:
2641 description: {vm-type} server image
2646 The parameter associated with the property flavor is an ONAP Constant
2649 The parameters must be named {vm-type}\_flavor\_name in the Heat
2650 Orchestration Template.
2652 The parameter must be declared as type: string
2654 The parameter must be enumerated in the Heat Orchestration Template
2657 Each VM type (i.e., {vm-type}) must have a separate parameter for
2658 flavors, even if more than one {vm-type} shares the same flavor. This
2659 provides maximum clarity and flexibility.
2661 *Example Parameter Definition*
2663 .. code-block:: yaml
2666 {vm-type}_flavor_name:
2668 description: {vm-type} flavor
2673 The parameter associated with the property name is an ONAP Orchestration
2676 The parameter value is provided to the Heat template by ONAP. The
2677 parameter must not be enumerated in the environment file.
2679 The parameter must be declared as type: string or type:
2680 comma\_delimited\_list
2682 If the parameter is declared as type:string, the parameter must be named
2683 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2684 at zero and increments by one.
2686 If the parameter is declared as type:comma\_delimited\_list, the
2687 parameter must be named as {vm-type}\_names
2689 Each element in the VM Name list should be assigned to successive
2690 instances of that VM type.
2692 If a VNF contains more than three instances of a given {vm-type}, the
2693 comma\_delimited\_list form of the parameter name (i.e.,
2694 {vm-type}\_names) should be used to minimize the number of unique
2695 parameters defined in the Heat.
2697 *Example: Parameter Definition*
2699 .. code-block:: yaml
2703 type: comma_delimited_list
2704 description: VM Names for {vm-type} VMs
2705 {vm-type}_name_{index}:
2707 description: VM Name for {vm-type} VM {index}
2709 *Example: comma\_delimited\_list*
2711 In this example, the {vm-type} has been defined as “lb” for load
2714 .. code-block:: yaml
2718 type: comma_delimited_list
2719 description: VM Names for lb VMs
2723 type: OS::Nova::Server
2725 name: { get_param: [lb_names, 0] }
2729 type: OS::Nova::Server
2731 name: { get_param: [lb_names, 1] }
2734 *Example: fixed-index*
2736 In this example, the {vm-type} has been defined as “lb” for load
2739 .. code-block:: yaml
2744 description: VM Name for lb VM 0
2748 description: VM Name for lb VM 1
2752 type: OS::Nova::Server
2754 name: { get_param: lb_name_0 }
2758 type: OS::Nova::Server
2760 name: { get_param: lb_name_1 }
2763 Contrail Issue with Values for OS::Nova::Server Property Name
2764 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2766 The Contrail GUI has a limitation displaying special characters. The
2767 issue is documented in
2768 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2769 recommended that special characters be avoided. However, if special
2770 characters must be used, the only special characters supported are:
2772 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2774 Property: availability\_zone
2775 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2777 The parameter associated with the property availability\_zone is an ONAP
2778 Orchestration parameter.
2780 The parameter value is provided to the Heat template by ONAP. The
2781 parameter must not be enumerated in the environment file.
2783 The parameter must be named availability\_zone\_{index} in the Heat
2784 Orchestration Template. The {index} must start at zero. The {index} must
2785 increment by one. The parameter name must not include the {vm-type}.
2787 The parameter must be declared as type: string
2789 The parameter must not be declared as type: comma\_delimited\_list
2794 The example below depicts part of a Heat Orchestration Template that
2795 uses the four OS::Nova::Server properties discussed in this section.
2797 In the Heat Orchestration Template below, four Virtual Machines
2798 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2799 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2800 parameter associated with the property name is a comma\_delimited\_list
2801 for dns and a string for oam.
2803 .. code-block:: yaml
2808 description: dns server image
2811 description: dns server flavor
2813 type: comma_delimited_list
2814 description: dns server names
2817 description: oam server image
2820 description: oam server flavor
2823 description: oam server name 0
2826 description: oam server name 1
2827 availability_zone_0:
2829 description: availability zone ID or Name
2830 availability_zone_1:
2832 description: availability zone ID or Name
2836 type: OS::Nova::Server
2838 name: { get_param: [ dns_names, 0 ] }
2839 image: { get_param: dns_image_name }
2840 flavor: { get_param: dns_flavor_name }
2841 availability_zone: { get_param: availability_zone_0 }
2845 type: OS::Nova::Server
2847 name: { get_param: [ dns_names, 1 ] }
2848 image: { get_param: dns_image_name }
2849 flavor: { get_param: dns_flavor_name }
2850 availability_zone: { get_param: availability_zone_1 }
2854 type: OS::Nova::Server
2856 name: { get_param: oam_name_0 }
2857 image: { get_param: oam_image_name }
2858 flavor: { get_param: oam_flavor_name }
2859 availability_zone: { get_param: availability_zone_0 }
2863 type: OS::Nova::Server
2865 name: { get_param: oam_name_1 }
2866 image: { get_param: oam_image_name }
2867 flavor: { get_param: oam_flavor_name }
2868 availability_zone: { get_param: availability_zone_1 }
2871 Resource: OS::Nova::Server – Metadata Parameters
2872 ------------------------------------------------
2874 The resource OS::Nova::Server has an OpenStack optional property
2875 metadata. The metadata property is mandatory for ONAP Heat Orchestration
2876 Templates; it must be included.
2878 ONAP requires the following three mandatory metadata parameters for an
2879 OS::Nova::Server resource:
2887 ONAP allows the following three optional metadata parameters for an
2888 OS::Nova::Server resource. They may be included
2894 Note that the metadata parameters do not and must not contain {vm-type}
2897 When Metadata parameters are past into a nested heat template, the
2898 parameter names must not change.
2900 The table below provides a summary. The sections that follow provides
2903 +---------------------------+------------------+----------------------+------------------------------+
2904 | Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
2905 +===========================+==================+======================+==============================+
2906 | vnf\_id | string | Mandatory | ONAP |
2907 +---------------------------+------------------+----------------------+------------------------------+
2908 | vf\_module\_id | string | Mandatory | ONAP |
2909 +---------------------------+------------------+----------------------+------------------------------+
2910 | vnf\_name | string | Mandatory | ONAP |
2911 +---------------------------+------------------+----------------------+------------------------------+
2912 | vf\_module\_name | string | Optional | ONAP |
2913 +---------------------------+------------------+----------------------+------------------------------+
2914 | vm\_role | string | Optional | YAML or Environment File |
2915 +---------------------------+------------------+----------------------+------------------------------+
2916 +---------------------------+------------------+----------------------+------------------------------+
2918 Table 4: ONAP Metadata
2923 The vnf\_id parameter is mandatory; it must be included in the Heat
2924 Orchestration Template.
2926 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
2927 UUID that is the vnf\_id and supplies it to the Heat Orchestration
2928 Template at orchestration time.
2930 The parameter must be declared as type: string
2932 Parameter constraints must not be defined.
2934 The parameter must not be enumerated in the Heat environment file.
2936 *Example Parameter Definition*
2938 .. code-block:: yaml
2943 description: Unique ID for this VNF instance
2948 The vf\_module\_id parameter is mandatory; it must be included in the
2949 Heat Orchestration Template.
2951 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
2952 generates the UUID that is the vf\_module\_id and supplies it to the
2953 Heat Orchestration Template at orchestration time.
2955 The parameter must be declared as type: string
2957 Parameter constraints must not be defined.
2959 The parameter must not be enumerated in the Heat environment file.
2961 *Example Parameter Definition*
2963 .. code-block:: yaml
2968 description: Unique ID for this VNF module instance
2973 The vnf\_name parameter is mandatory; it must be included in the Heat
2974 Orchestration Template.
2976 The vnf\_name parameter value will be generated and/or assigned by ONAP
2977 and supplied to the Heat Orchestration Template by ONAP at orchestration
2980 The parameter must be declared as type: string
2982 Parameter constraints must not be defined.
2984 The parameter must not be enumerated in the Heat environment file.
2986 *Example Parameter Definition*
2988 .. code-block:: yaml
2993 description: Unique name for this VNF instance
2998 The vf\_module\_name parameter is optional; it may be included in the
2999 Heat Orchestration Template.
3001 The vf\_module\_name parameter is the name of the name of the Heat stack
3002 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3003 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3004 needs to be specified as part of the orchestration process.
3006 The parameter must be declared as type: string
3008 Parameter constraints must not be defined.
3010 The parameter must not be enumerated in the Heat environment file.
3012 *Example Parameter Definition*
3014 .. code-block:: yaml
3019 description: Unique name for this VNF Module instance
3024 The vm\_role parameter is optional; it may be included in the Heat
3025 Orchestration Template.
3027 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3028 system and available for use by other ONAP components and/or north bound
3031 The vm\_role values must be either
3033 - hard-coded into the Heat Orchestration Template or
3035 - enumerated in the environment file.
3037 Defining the vm\_role as the {vm-type} is a recommended convention
3039 The parameter must be declared as type: string
3041 Parameter constraints must not be defined.
3043 *Example Parameter Definition*
3045 .. code-block:: yaml
3050 description: Unique role for this VM
3052 *Example Resource Definition: Hard Coded*
3054 In this example, the {vm-role} is hard coded in the Heat Orchestration
3057 .. code-block:: yaml
3061 type: OS::Nova::Server
3067 *Example Resource Definition: get\_param*
3069 In this example, the {vm-role} is enumerated in the environment file.
3071 .. code-block:: yaml
3075 type: OS::Nova::Server
3079 vm_role: { get_param: vm_role }
3084 The example below depicts part of a Heat Orchestration Template that
3085 uses the five of the OS::Nova::Server metadata parameter discussed in
3086 this section. The {vm-type} has been defined as lb for load balancer.
3088 .. code-block:: yaml
3093 description: VM Name for lb VM 0
3096 description: Unique name for this VNF instance
3099 description: Unique ID for this VNF instance
3102 description: Unique name for this VNF Module instance
3105 description: Unique ID for this VNF Module instance
3108 description: Unique role for this VM
3113 type: OS::Nova::Server
3115 name: { get_param: lb_name_0 }
3118 vnf_name: { get_param: vnf_name }
3119 vnf_id: { get_param: vnf_id }
3120 vf_module_name: { get_param: vf_module_name }
3121 vf_module_id: { get_param: vf_module_id }
3124 Resource: OS::Neutron::Port - Parameters
3125 ----------------------------------------
3127 The resource OS::Neutron::Port is for managing Neutron ports (See
3128 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3133 Four properties of the resource OS::Neutron::Port that must follow the
3134 ONAP parameter naming convention. The four properties are:
3138 2. fixed\_ips, ip\_address
3140 3. fixed\_ips, subnet\_id
3142 4. allowed\_address\_pairs, ip\_address
3144 The parameters associated with these properties may reference an
3145 external network or internal network. External networks and internal
3146 networks are defined in `Networking`_.
3151 When the parameter references an external network
3153 - the parameter name must contain {network-role}
3155 - the parameter must not be enumerated in the Heat environment file
3157 - the parameter is classified as an ONAP Orchestration Parameter
3159 +----------------------------------------+-----------------------------------------------+--------------------------+
3160 | Property Name | ONAP Parameter Name | Parameter Type |
3161 +========================================+===============================================+==========================+
3162 | network | {network-role}\_net\_id | string |
3163 +----------------------------------------+-----------------------------------------------+--------------------------+
3164 | | {network-role}\_net\_name | string |
3165 +----------------------------------------+-----------------------------------------------+--------------------------+
3166 | fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
3167 +----------------------------------------+-----------------------------------------------+--------------------------+
3168 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3169 +----------------------------------------+-----------------------------------------------+--------------------------+
3170 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3171 +----------------------------------------+-----------------------------------------------+--------------------------+
3172 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3173 +----------------------------------------+-----------------------------------------------+--------------------------+
3174 | fixed\_ips, subnet | {network-role}\_subnet\_id | string |
3175 +----------------------------------------+-----------------------------------------------+--------------------------+
3176 | | {network-role}\_v6\_subnet\_id | string |
3177 +----------------------------------------+-----------------------------------------------+--------------------------+
3178 | allowed\_address\_pairs, ip\_address | {vm-type}\_{network-role}\_floating\_ip | string |
3179 +----------------------------------------+-----------------------------------------------+--------------------------+
3180 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
3181 +----------------------------------------+-----------------------------------------------+--------------------------+
3182 | | {vm-type}\_{network-role}\_ip\_{index} | string |
3183 +----------------------------------------+-----------------------------------------------+--------------------------+
3184 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3185 +----------------------------------------+-----------------------------------------------+--------------------------+
3186 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3187 +----------------------------------------+-----------------------------------------------+--------------------------+
3188 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3189 +----------------------------------------+-----------------------------------------------+--------------------------+
3191 Table 5: OS::Neutron::Port Resource Property Parameters (External
3197 When the parameter references an internal network
3199 - the parameter name must contain int\_{network-role}
3201 - the parameter may be enumerated in the environment file.
3203 +----------------------------------------+----------------------------------------------------+--------------------------+
3204 | Property | Parameter Name for Internal Networks | Parameter Type |
3205 +========================================+====================================================+==========================+
3206 | network | int\_{network-role}\_net\_id | string |
3207 +----------------------------------------+----------------------------------------------------+--------------------------+
3208 | | int\_{network-role}\_net\_name | string |
3209 +----------------------------------------+----------------------------------------------------+--------------------------+
3210 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3211 +----------------------------------------+----------------------------------------------------+--------------------------+
3212 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3213 +----------------------------------------+----------------------------------------------------+--------------------------+
3214 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3215 +----------------------------------------+----------------------------------------------------+--------------------------+
3216 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3217 +----------------------------------------+----------------------------------------------------+--------------------------+
3218 | fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
3219 +----------------------------------------+----------------------------------------------------+--------------------------+
3220 | | int\_{network-role}\_v6\_subnet\_id | string |
3221 +----------------------------------------+----------------------------------------------------+--------------------------+
3222 | allowed\_address\_pairs, ip\_address | {vm-type}\_int\_{network-role}\_floating\_ip | string |
3223 +----------------------------------------+----------------------------------------------------+--------------------------+
3224 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
3225 +----------------------------------------+----------------------------------------------------+--------------------------+
3226 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3227 +----------------------------------------+----------------------------------------------------+--------------------------+
3228 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3229 +----------------------------------------+----------------------------------------------------+--------------------------+
3230 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3231 +----------------------------------------+----------------------------------------------------+--------------------------+
3232 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3233 +----------------------------------------+----------------------------------------------------+--------------------------+
3235 Table 6: Port Resource Property Parameters (Internal Networks)
3240 The property networks in the resource OS::Neutron::Port must be
3241 referenced by Neutron Network ID, a UUID value, or by the network name
3242 defined in OpenStack.
3247 When the parameter associated with the property network is referencing
3248 an “external” network, the parameter must adhere to the following naming
3249 convention in the Heat Orchestration Template
3251 - {network-role}\_net\_id for the Neutron network ID
3253 - {network-role}\_net\_name for the network name in OpenStack
3255 The parameter must be declared as type: string
3257 The parameter must not be enumerated in the Heat environment file.
3259 *Example Parameter Definition*
3261 .. code-block:: yaml
3264 {network-role}_net_id:
3266 description: Neutron UUID for the {network-role} network
3267 {network-role}_net_name:
3269 description: Neutron name for the {network-role} network
3271 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3272 that has only one subnet*
3274 In this example, the {network-role} has been defined as oam to represent
3275 an oam network and the {vm-type} has been defined as lb for load
3276 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3277 to assign IP addresses.
3279 .. code-block:: yaml
3284 description: Neutron UUID for the oam network
3288 type: OS::Neutron::Port
3289 network: { get_param: oam_net_id }
3294 When the parameter associated with the property network is referencing
3295 an “internal” network, the parameter must adhere to the following naming
3298 - int\_{network-role}\_net\_id for the Neutron network ID
3300 - int\_{network-role}\_net\_name for the network name in OpenStack
3302 The parameter must be declared as type: string
3304 The assumption is that internal networks are created in the base module.
3305 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3306 Base Module Output Parameter) to the incremental modules. In the
3307 incremental modules, it will be defined as input parameter.
3309 *Example Parameter Definition*
3311 .. code-block:: yaml
3314 int_{network-role}_net_id:
3316 description: Neutron UUID for the {network-role} network
3317 int_{network-role}_net_name:
3319 description: Neutron name for the {network-role} network
3321 Property: fixed\_ips, Map Property: subnet\_id
3322 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3324 The property fixed\_ips is used to assign IPs to a port. The Map
3325 Property subnet\_id specifies the subnet the IP is assigned from.
3327 The property fixed\_ips and Map Property subnet\_id must be used if a
3328 Cloud (i.e., DHCP) IP address assignment is being requested and the
3329 Cloud IP address assignment is targeted at a specific subnet when two or
3332 The property fixed\_ips and Map Property subnet\_id should not be used
3333 if all IP assignments are fixed, or if the Cloud IP address assignment
3334 does not target a specific subnet or there is only one subnet.
3336 Note that DHCP assignment of IP addresses is also referred to as cloud
3337 assigned IP addresses.
3339 Subnet of an External Networks
3340 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3342 When the parameter is referencing a subnet of an “external” network, the
3343 property fixed\_ips and Map Property subnet\_id parameter must adhere to
3344 the following naming convention.
3346 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3348 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3350 The parameter must be declared as type: string
3352 The parameter must not be enumerated in the Heat environment file.
3354 *Example Parameter Definition*
3356 .. code-block:: yaml
3359 {network-role}_subnet_id:
3361 description: Neutron subnet UUID for the {network-role} network
3363 {network-role}_v6_subnet_id:
3365 description: Neutron subnet UUID for the {network-role} network
3367 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3368 that has two or more subnets subnet:*
3370 In this example, the {network-role} has been defined as oam to represent
3371 an oam network and the {vm-type} has been defined as lb for load
3372 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3373 to assign IP addresses.
3375 .. code-block:: yaml
3380 description: Neutron UUID for the oam network
3384 description: Neutron subnet UUID for the oam network
3388 type: OS::Neutron::Port
3389 network: { get_param: oam_net_id }
3391 - subnet_id: { get_param: oam_subnet_id }
3393 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3394 address assigned to a network that has at least one IPv4 subnet and one
3397 In this example, the {network-role} has been defined as oam to represent
3398 an oam network and the {vm-type} has been defined as lb for load
3401 .. code-block:: yaml
3406 description: Neutron UUID for the oam network
3410 description: Neutron subnet UUID for the oam network
3414 description: Neutron subnet UUID for the oam network
3418 type: OS::Neutron::Port
3420 network: { get_param: oam_net_id }
3422 - subnet_id: { get_param: oam_subnet_id }
3423 - subnet_id: { get_param: oam_v6_subnet_id }
3428 When the parameter is referencing the subnet of an “internal” network,
3429 the property fixed\_ips and Map Property subnet\_id parameter must
3430 adhere to the following naming convention.
3432 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3434 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3436 The parameter must be declared as type: string
3438 The assumption is that internal networks are created in the base module.
3439 The Neutron subnet network ID will be passed as an output parameter
3440 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3441 the incremental modules, it will be defined as input parameter.
3443 *Example Parameter Definition*
3445 .. code-block:: yaml
3448 int_{network-role}_subnet_id:
3450 description: Neutron subnet UUID for the {network-role} network
3452 int_{network-role}_v6_subnet_id:
3454 description: Neutron subnet UUID for the {network-role} network
3456 Property: fixed\_ips, Map Property: ip\_address
3457 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3459 The property fixed\_ips is used to assign IPs to a port. The Map
3460 Property ip\_address specifies the IP address to be assigned to the
3463 The property fixed\_ips and Map Property ip\_address must be used when
3464 statically assigning one or more IP addresses to a port. This is also
3465 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3466 the IP address assignment.
3468 An IP address is assigned to a port on a VM (referenced by {vm-type})
3469 that is connected to an external network (referenced by {network-role})
3470 or internal network (referenced by int\_{network-role}).
3472 When a SDN-C IP assignment is made to a port connected to an external
3473 network, the parameter name must contain {vm-type} and {network-role}.
3475 When a SDN-C IP assignment is made to a port connected to an internal
3476 network, the parameter name must contain {vm-type} and
3477 int\_{network-role}.
3479 IP Address Assignments on External Networks
3480 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3482 When the property fixed\_ips and Map Property ip\_address is used to
3483 assign IP addresses to an external network, the parameter name is
3484 dependent on the parameter type (comma\_delimited\_list or string) and
3485 IP address type (IPv4 or IPv6).
3487 When the parameter for property fixed\_ips and Map Property ip\_address
3488 is declared type: comma\_delimited\_list, the parameter must adhere to
3489 the following naming convention
3491 - {vm-type}\_{network-role}\_ips for IPv4 address
3493 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3495 Each element in the IP list should be assigned to successive instances
3496 of {vm-type} on {network-role}.
3498 The parameter must not be enumerated in the Heat environment file.
3500 *Example Parameter Definition*
3502 .. code-block:: yaml
3506 {vm-type}_{network-role}_ips:
3507 type: comma_delimited_list
3508 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3510 {vm-type}_{network-role}_v6_ips:
3511 type: comma_delimited_list
3512 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3514 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3515 Assignments to an external network*
3517 In this example, the {network-role} has been defined as oam to represent
3518 an oam network and the {vm-type} has been defined as db for database.
3520 .. code-block:: yaml
3525 description: Neutron UUID for a oam network
3528 type: comma_delimited_list
3529 description: Fixed IPv4 assignments for db VMs on the oam network
3532 type: comma_delimited_list
3533 description: Fixed IPv6 assignments for db VMs on the oam network
3537 type: OS::Neutron::Port
3538 network: { get_param: oam_net_id }
3539 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3542 type: OS::Neutron::Port
3544 network: { get_param: oam_net_id }
3546 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3547 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3549 When the parameter for property fixed\_ips and Map Property ip\_address
3550 is declared type: string, the parameter must adhere to the following
3553 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3555 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3557 The value for {index} must start at zero (0) and increment by one.
3559 The parameter must not be enumerated in the Heat environment file.
3561 *Example Parameter Definition*
3563 .. code-block:: yaml
3566 {vm-type}_{network-role}_ip_{index}:
3568 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3570 {vm-type}_{network-role}_v6_ip_{index}:
3572 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3574 *Example: string parameters for IPv4 and IPv6 Address Assignments to an external network*
3576 In this example, the {network-role} has been defined as “oam” to
3577 represent an oam network and the {vm-type} has been defined as “db” for
3580 .. code-block:: yaml
3585 description: Neutron UUID for an OAM network
3589 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3593 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3597 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3601 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3605 type: OS::Neutron::Port
3607 network: { get_param: oam_net_id }
3608 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3611 type: OS::Neutron::Port
3613 network: { get_param: oam_net_id }
3615 - “ip_address”: {get_param: db_oam_ip_1}}]
3616 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3618 IP Address Assignment on Internal Networks
3619 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3621 When the property fixed\_ips and Map Property ip\_address is used to
3622 assign IP addresses to an internal network, the parameter name is
3623 dependent on the parameter type (comma\_delimited\_list or string) and
3624 IP address type (IPv4 or IPv6).
3626 When the parameter for property fixed\_ips and Map Property ip\_address
3627 is declared type: comma\_delimited\_list, the parameter must adhere to
3628 the following naming convention
3630 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3632 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3634 Each element in the IP list should be assigned to successive instances
3635 of {vm-type} on {network-role}.
3637 The parameter must be enumerated in the Heat environment file. Since an
3638 internal network is local to the VNF, IP addresses can be re-used at
3641 *Example Parameter Definition*
3643 .. code-block:: yaml
3647 {vm-type}_int_{network-role}_ips:
3648 type: comma_delimited_list
3649 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3651 {vm-type}_int_{network-role}_v6_ips:
3652 type: comma_delimited_list
3653 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3655 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3656 Assignments to an internal network*
3658 In this example, the {network-role} has been defined as oam\_int to
3659 represent an oam network internal to the vnf. The role oam\_int was
3660 picked to differentiate from an external oam network with a
3661 {network-role} of oam. The {vm-type} has been defined as db for
3664 .. code-block:: yaml
3669 description: Neutron UUID for the oam internal network
3672 type: comma_delimited_list
3673 description: Fixed IPv4 assignments for db VMs on the oam internal network
3675 db_int_oam_int_v6_ips:
3676 type: comma_delimited_list
3677 description: Fixed IPv6 assignments for db VMs on the oam internal network
3681 type: OS::Neutron::Port
3683 network: { get_param: int_oam_int_net_id }
3684 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3687 type: OS::Neutron::Port
3689 network: { get_param: int_oam_int_net_id }
3691 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3692 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3694 When the parameter for property fixed\_ips and Map Property ip\_address
3695 is declared type: string, the parameter must adhere to the following
3698 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3700 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3702 The value for {index} must start at zero (0) and increment by one.
3704 The parameter must be enumerated in the Heat environment file. Since an
3705 internal network is local to the VNF, IP addresses can be re-used at
3708 *Example Parameter Definition*
3710 .. code-block:: yaml
3714 {vm-type}_int_{network-role}_ip_{index}:
3716 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3718 {vm-type}_int_{network-role}_v6_ip_{index}:
3720 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3722 *Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
3724 In this example, the {network-role} has been defined as oam\_int to
3725 represent an oam network internal to the vnf. The role oam\_int was
3726 picked to differentiate from an external oam network with a
3727 {network-role} of oam. The {vm-type} has been defined as db for
3730 .. code-block:: yaml
3735 description: Neutron UUID for an OAM internal network
3739 description: Fixed IPv4 assignment for db VM on the oam_int network
3743 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3747 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3751 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3755 type: OS::Neutron::Port
3757 network: { get_param: int_oam_int_net_id }
3758 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3761 type: OS::Neutron::Port
3763 network: { get_param: int_oam_int_net_id }
3765 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3766 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3768 Property: allowed\_address\_pairs, Map Property: ip\_address
3769 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3771 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3772 allows the user to specify a mac\_address and/or ip\_address that will
3773 pass through a port regardless of subnet. This enables the use of
3774 protocols such as VRRP, which floats an IP address between two instances
3775 to enable fast data plane failover. The map property ip\_address
3776 specifies the IP address.
3778 The allowed\_address\_pairs is an optional property. It is not required.
3780 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3781 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3782 and {network-role}/int\_{network-role} combination.
3784 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3785 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3786 and {network-role}/int\_{network-role} combination.
3788 Note that the management of these IP addresses (i.e. transferring
3789 ownership between active and standby VMs) is the responsibility of the
3792 Note that these parameters are **not** intended to represent Neutron
3793 “Floating IP” resources, for which OpenStack manages a pool of public IP
3794 addresses that are mapped to specific VM ports. In that case, the
3795 individual VMs are not even aware of the public IPs, and all assignment
3796 of public IPs to VMs is via OpenStack commands. ONAP does not support
3797 Neutron-style Floating IPs.
3802 When the parameter is referencing an “external” network, the property
3803 allowed\_address\_pairs and Map Property ip\_address parameter must
3804 adhere to the following naming convention.
3806 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3808 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3810 The parameter must be declared as type: string
3812 The parameter must not be enumerated in the Heat environment file.
3814 *Example Parameter Definition*
3816 .. code-block:: yaml
3820 {vm-type}_{network-role}_floating_ip:
3822 description: VIP for {vm-type} VMs on the {network-role} network
3824 {vm-type}_{network-role}_floating_v6_ip:
3826 description: VIP for {vm-type} VMs on the {network-role} network
3830 In this example, the {network-role} has been defined as oam to represent
3831 an oam network and the {vm-type} has been defined as db for database.
3833 .. code-block:: yaml
3838 description: Neutron UUID for the oam network
3841 type: comma_delimited_list
3842 description: Fixed IPs for db VMs on the oam network
3846 description: VIP IP for db VMs on the oam network
3850 type: OS::Neutron::Port
3852 network: { get_param: oam_net_id }
3853 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
3854 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3857 type: OS::Neutron::Port
3859 network: { get_param: oam_net_id }
3860 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
3861 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3866 When the parameter is referencing an “internal” network, the property
3867 allowed\_address\_pairs and Map Property ip\_address parameter must
3868 adhere to the following naming convention.
3870 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
3872 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
3874 The parameter must be declared as type: string
3876 The parameter must be enumerated in the Heat environment file.
3878 *Example Parameter Definition*
3880 .. code-block:: yaml
3884 {vm-type}_int_{network-role}_floating_ip:
3886 description: VIP for {vm-type} VMs on the int_{network-role} network
3888 {vm-type}_int_{network-role}_floating_v6_ip:
3890 description: VIP for {vm-type} VMs on the int_{network-role} network
3892 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
3893 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3895 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
3896 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
3898 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
3899 one allowed address pair IPv6 address per {vm-type} and {network-role}
3902 If there is a need for multiple allowed address pair IPs for a given
3903 {vm-type} and {network-role} combination within a VNF, then the
3904 parameter names defined for the property fixed\_ips and Map Property
3905 ip\_address should be used with the allowed\_address\_pairs property.
3906 The examples below illustrate this.
3908 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
3910 In this example, there are two administrative VM pairs. Each pair has
3911 one VIP. The {network-role} has been defined as oam to represent an oam
3912 network and the {vm-type} has been defined as admin for an
3915 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
3916 VIP, [admin\_oam\_ips,2]
3918 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
3919 VIP, [admin\_oam\_ips,5]
3921 .. code-block:: yaml
3926 description: Neutron UUID for the oam network
3928 type: comma_delimited_list
3929 description: Fixed IP assignments for admin VMs on the oam network
3934 type: OS::Neutron::Port
3936 network: { get_param: oam_net_id }
3937 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
3938 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3941 type: OS::Neutron::Port
3943 network: { get_param: oam_net_id }
3944 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
3945 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3948 type: OS::Neutron::Port
3950 network: { get_param: oam_net_id }
3951 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
3952 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3955 type: OS::Neutron::Port
3957 network: { get_param: oam_net_id }
3958 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
3959 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3961 *Example: A VNF has two load balancers. The pair of load balancers share
3964 In this example, there is one load balancer pairs. The pair has two
3965 VIPs. The {network-role} has been defined as oam to represent an oam
3966 network and the {vm-type} has been defined as lb for a load balancer VM.
3968 .. code-block:: yaml
3972 type: OS::Neutron::Port
3974 network: { get_param: oam_net_id }
3975 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
3976 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3979 type: OS::Neutron::Port
3981 network: { get_param: oam_net_id }
3982 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
3983 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3985 As a general rule, provide the fixed IPs for the VMs indexed first in
3986 the CDL and then the VIPs as shown in the examples above.
3988 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
3989 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3991 The following items must be taken into consideration when designing Heat
3992 Orchestration Templates that expect ONAP’s SDN-C to assign
3993 allowed\_address\_pair IP addresses via automation.
3995 The VMs must be of the same {vm-type}.
3997 The VMs must be created in the same module (base or incremental).
3999 Resource Property “name”
4000 ------------------------
4002 The parameter naming convention of the property name for the resource
4003 OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
4005 This section provides the requirements how the property name for non
4006 OS::Nova::Server resources must be defined when the property is used.
4007 Not all resources require the property name (e.g., it is optional) and
4008 some resources do not support the property.
4010 When the property name for a non OS::Nova::Server resources is defined
4011 in a Heat Orchestration Template, the intrinsic function str\_replace
4012 must be used in conjunction with the ONAP supplied metadata parameter
4013 vnf\_name to generate a unique value. This prevents the enumeration of a
4014 unique value for the property name in a per instance environment file.
4018 - In most cases, only the use of the metadata value vnf\_name is
4019 required to create a unique property name
4021 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4022 may also be used in the str\_replace construct to generate a unique
4023 name when the vnf\_name does not provide uniqueness
4025 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4027 .. code-block:: yaml
4031 type: OS::Neutron::SecurityGroup
4033 description: vDNS security group
4036 template: VNF_NAME_sec_grp_DNS
4038 VNF_NAME: {get_param: vnf_name}
4042 *Example: Property name for resource* OS::Cinder::Volume
4044 .. code-block:: yaml
4048 type: OS::Cinder::Volume
4050 description: Cinder Volume
4053 template: VNF_NAME_STACK_NAME_dns_volume
4055 VNF_NAME: {get_param: vnf_name}
4056 STACK_NAME: { get_param: 'OS::stack_name' }
4059 Contrail Issue with Values for the Property Name
4060 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4062 The Contrail GUI has a limitation displaying special characters. The
4063 issue is documented in
4064 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4065 recommended that special characters be avoided. However, if special
4066 characters must be used, note that for the following resources:
4080 the only special characters supported are:
4082 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4084 ONAP Output Parameter Names
4085 ---------------------------
4087 ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
4089 ONAP Base Module Output Parameters:
4090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4092 ONAP Base Module Output Parameters do not have an explicit naming
4093 convention. The parameter name must contain {vm-type} and {network-role}
4096 ONAP Volume Template Output Parameters:
4097 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4099 ONAP Base Module Output Parameters do not have an explicit naming
4100 convention. The parameter name must contain {vm-type} when appropriate.
4102 Predefined Output Parameters
4103 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4105 ONAP currently defines one predefined output parameter the OAM
4106 Management IP Addresses.
4108 OAM Management IP Addresses
4109 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
4111 A VNF may have a management interface for application controllers to
4112 interact with and configure the VNF. Typically, this will be via a
4113 specific VM that performs a VNF administration function. The IP address
4114 of this interface must be captured and inventoried by ONAP. The IP
4115 address might be a VIP if the VNF contains an HA pair of management VMs,
4116 or may be a single IP address assigned to one VM.
4118 The Heat template may define either (or both) of the following Output
4119 parameters to identify the management IP address.
4121 - oam\_management\_v4\_address
4123 - oam\_management\_v6\_address
4127 - The use of this output parameters are optional.
4129 - The Management IP Address should be defined only once per VNF, so it
4130 must only appear in one Module template
4132 - If a fixed IP for the admin VM is passed as an input parameter, it
4133 may be echoed in the output parameters. In this case, a IPv4 and/or
4134 IPv6 parameter must be defined in the parameter section of the YAML
4135 Heat template. The parameter maybe named oam\_management\_v4\_address
4136 and/or oam\_management\_v6\_address or may be named differently.
4138 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4139 from the resource attributes. In this case,
4140 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4141 not be defined in the parameter section of the YAML Heat template.
4143 *Example: SDN-C Assigned IP Address echoed as*
4144 oam\_management\_v4\_address
4146 .. code-block:: yaml
4151 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4155 admin_oam_net_0_port:
4156 type: OS::Neutron::Port
4160 template: VNF_NAME_admin_oam_net_0_port
4162 VNF_NAME: {get_param: vnf_name}
4163 network: { get_param: oam_net_id }
4164 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4165 security_groups: [{ get_param: security_group }]
4168 type: OS::Nova::Server
4170 name: { get_param: admin_names }
4171 image: { get_param: admin_image_name }
4172 flavor: { get_param: admin_flavor_name }
4173 availability_zone: { get_param: availability_zone_0 }
4175 - port: { get_resource: admin_oam_net_0_port }
4177 vnf_id: { get_param: vnf_id }
4178 vf_module_id: { get_param: vf_module_id }
4179 vnf_name: {get_param: vnf_name }
4181 oam_management_v4_address:
4182 value: {get_param: admin_oam_ip_0 }
4184 *Example: Cloud Assigned IP Address output as*
4185 oam\_management\_v4\_address
4187 .. code-block:: yaml
4192 admin_oam_net_0_port:
4193 type: OS::Neutron::Port
4197 template: VNF_NAME_admin_oam_net_0_port
4199 VNF_NAME: {get_param: vnf_name}
4200 network: { get_param: oam_net_id }
4201 security_groups: [{ get_param: security_group }]
4204 type: OS::Nova::Server
4206 name: { get_param: admin_names }
4207 image: { get_param: admin_image_name }
4208 flavor: { get_param: admin_flavor_name }
4209 availability_zone: { get_param: availability_zone_0 }
4211 - port: { get_resource: admin_oam_net_0_port }
4213 vnf_id: { get_param: vnf_id }
4214 vf_module_id: { get_param: vf_module_id }
4215 vnf_name: {get_param: vnf_name }
4218 oam_management_v4_address:
4219 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4221 Contrail Resource Parameters
4222 ----------------------------
4224 ONAP requires the parameter names of certain Contrail Resources to
4225 follow specific naming conventions. This section provides these
4228 Contrail Network Parameters
4229 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4231 Contrail based resources may require references to a Contrail network
4232 using the network FQDN.
4237 When the parameter associated with the Contrail Network is referencing
4238 an “external” network, the parameter must adhere to the following naming
4239 convention in the Heat Orchestration Template
4241 - {network-role}\_net\_fqdn
4243 The parameter must be declared as type: string
4245 The parameter must not be enumerated in the Heat environment file.
4247 *Example: Parameter declaration*
4249 .. code-block:: yaml
4252 {network-role}_net_fqdn:
4254 description: Contrail FQDN for the {network-role} network
4256 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4257 Reference to a Network FQDN.*
4259 In this example, the {network-role} has been defined as oam to represent
4260 an oam network and the {vm-type} has been defined as fw for firewall.
4261 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4262 virtual\_network\_refs references a contrail network FQDN.
4264 .. code-block:: yaml
4267 type: OS::ContrailV2::VirtualMachineInterface
4271 template: VM_NAME_virtual_machine_interface_1
4273 VM_NAME: { get_param: fw_name_0 }
4274 virtual_machine_interface_properties:
4275 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4276 virtual_network_refs:
4277 - get_param: oam_net_fqdn
4278 security_group_refs:
4279 - get_param: fw_sec_grp_id
4281 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4282 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4284 The parameter associated with the resource
4285 OS::ContrailV2::InterfaceRouteTable property
4286 interface\_route\_table\_routes, map property
4287 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4290 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4291 in the Heat Orchestration Template.
4293 The parameter must be declared as type: json
4295 The parameter supports IP addresses in the format:
4297 1. Host IP Address (e.g., 10.10.10.10)
4299 2. CIDR Notation format (e.g., 10.0.0.0/28)
4301 The parameter must not be enumerated in the Heat environment file.
4303 *Example Parameter Definition*
4305 .. code-block:: yaml
4308 {vm-type}_{network-role}_route_prefixes:
4310 description: JSON list of Contrail Interface Route Table route prefixes
4314 .. code-block:: yaml
4319 description: Unique name for this VF instance
4320 fw_int_fw_route_prefixes:
4322 description: prefix for the ServiceInstance InterfaceRouteTable
4323 int_fw_dns_trusted_interface_type:
4325 description: service_interface_type for ServiceInstance
4328 type: OS::ContrailV2::InterfaceRouteTable
4329 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4333 template: VNF_NAME_interface_route_table
4335 VNF_NAME: { get_param: vnf_name }
4336 interface_route_table_routes:
4337 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4338 service_instance_refs:
4339 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4340 service_instance_refs_data:
4341 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4343 Parameter Names in Contrail Resources
4344 -------------------------------------
4346 Contrail Heat resource properties will use, when appropriate, the same
4347 naming convention as OpenStack Heat resources. For example, the resource
4348 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4349 convention is identical to properties in OS::Neutron::Port.
4351 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4352 instance\_ip\_address*
4354 The property instance\_ip\_address uses the same parameter naming
4355 convention as the property fixed\_ips and Map Property ip\_address in
4356 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4357 Address. The {network-role} has been defined as oam\_protected to
4358 represent an oam protected network and the {vm-type} has been defined as
4361 .. code-block:: yaml
4363 CMD_FW_OAM_PROTECTED_RII:
4364 type: OS::ContrailV2::InstanceIp
4366 - FW_OAM_PROTECTED_RVMI
4368 virtual_machine_interface_refs:
4369 - get_resource: FW_OAM_PROTECTED_RVMI
4370 virtual_network_refs:
4371 - get_param: oam_protected_net_fqdn
4372 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4374 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4377 The property instance\_ip\_address uses the same parameter naming
4378 convention as the property fixed\_ips and Map Property subnet\_id in
4379 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4380 Address. The {network-role} has been defined as “oam\_protected” to
4381 represent an oam protected network and the {vm-type} has been defined as
4384 .. code-block:: yaml
4386 CMD_FW_SGI_PROTECTED_RII:
4387 type: OS::ContrailV2::InstanceIp
4389 - FW_OAM_PROTECTED_RVMI
4391 virtual_machine_interface_refs:
4392 - get_resource: FW_OAM_PROTECTED_RVMI
4393 virtual_network_refs:
4394 - get_param: oam_protected_net_fqdn
4395 subnet_uuid: { get_param: oam_protected_subnet_id }
4397 Cinder Volume Templates
4398 -----------------------
4400 ONAP supports the independent deployment of a Cinder volume via separate
4401 Heat Orchestration Templates, the Cinder Volume module. This allows the
4402 volume to persist after VNF deletion so that they can be reused on
4403 another instance (e.g., during a failover activity).
4405 A Base Module or Incremental Module may have a corresponding volume
4406 module. Use of separate volume modules is optional. A Cinder volume may
4407 be embedded within the Base Module or Incremental Module if persistence
4410 If a VNF Base Module or Incremental Module has an independent volume
4411 module, the scope of volume templates must be 1:1 with Base module or
4412 Incremental module. A single volume module must create only the volumes
4413 required by a single Incremental module or Base module.
4415 The following rules apply to independent volume Heat templates:
4417 - Cinder volumes must be created in a separate Heat Orchestration
4418 Template from the Base Module or Incremental Module.
4420 - A single Cinder volume module must include all Cinder volumes
4421 needed by the Base/Incremental module.
4423 - The volume template must define “outputs” for each Cinder volume
4424 resource universally unique identifier (UUID) (i.e. ONAP Volume
4425 Template Output Parameters).
4427 - The VNF Incremental Module or Base Module must define input
4428 parameters that match each Volume output parameter (i.e., ONAP Volume
4429 Template Output Parameters).
4431 - ONAP will supply the volume template outputs automatically to the
4432 bases/incremental template input parameters.
4434 - Volume modules may utilize nested Heat templates.
4436 *Examples: Volume Template*
4438 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4439 creates an independent Cinder volume for a VM in the module
4440 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4441 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4442 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4443 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4444 output statement and provides the value to the incremental module.
4446 Note that the example below is not a complete Heat Orchestration
4447 Template. The {vm-type} has been defined as “lb” for load balancer
4449 incremental\_volume.yaml
4451 .. code-block:: yaml
4462 type: OS::Cinder::Volume
4466 template: VNF_NAME_volume_0
4468 VNF_NAME: { get_param: vnf_name }
4469 size: {get_param: dns_volume_size_0}
4474 value: {get_resource: dns_volume_0}
4480 .. code-block:: yaml
4491 type: OS::Nova::Server
4493 name: {get_param: dns_name_0}
4498 type: OS::Cinder::VolumeAttachment
4500 instance_uuid: { get_resource: lb_0 }
4501 volume_id: { get_param: lb_volume_id_0 }
4503 ONAP Support of Environment Files
4504 ---------------------------------
4506 The use of an environment file in OpenStack is optional. In ONAP, it is
4507 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
4508 corresponding environment file, even if no parameters are required to be
4511 (Note that ONAP, the open source version of ONAP, does not
4512 programmatically enforce the use of an environment file.)
4514 A Base Module Heat Orchestration Template must have a corresponding
4517 An Incremental Module Heat Orchestration Template must have a
4518 corresponding environment file.
4520 A Cinder Volume Module Heat Orchestration Template must have a
4521 corresponding environment file.
4523 A nested heat template must not have an environment file; OpenStack does
4526 The environment file must contain parameter values for the ONAP
4527 Orchestration Constants and VNF Orchestration Constants. These
4528 parameters are identical across all instances of a VNF type, and
4529 expected to change infrequently. The ONAP Orchestration Constants are
4530 associated with OS::Nova::Server image and flavor properties (See
4531 `Property: image`_ and `Property: flavor`_). Examples of VNF Orchestration Constants are the networking
4532 parameters associated with an internal network (e.g., private IP ranges)
4533 and Cinder volume sizes.
4535 The environment file must not contain parameter values for parameters
4536 that are instance specific (ONAP Orchestration Parameters, VNF
4537 Orchestration Parameters). These parameters are supplied to the Heat by
4538 ONAP at orchestration time.
4540 SDC Treatment of Environment Files
4541 ----------------------------------
4543 Parameter values enumerated in the environment file are used by SDC as
4544 the default value. However, the SDC user may use the SDC GUI to
4545 overwrite the default values in the environment file.
4547 SDC generates a new environment file for distribution to MSO based on
4548 the uploaded environment file and the user provided GUI updates. The
4549 user uploaded environment file is discarded when the new file is
4550 created. Note that if the user did not change any values via GUI
4551 updates, the SDC generated environment file will contain the same values
4552 as the uploaded file.
4554 Use of Environment Files when using OpenStack “heat stack-create” CLI
4555 ---------------------------------------------------------------------
4557 When ONAP is instantiating the Heat Orchestration Template, certain
4558 parameter must not be enumerated in the environment file. This document
4559 provides the details of what parameters should not be enumerated.
4561 If the Heat Orchestration Template is to be instantiated from the
4562 OpenStack Command Line Interface (CLI) using the command “heat
4563 stack-create”, all parameters must be enumerated in the environment
4566 Heat Template Constructs
4567 ------------------------
4569 Nested Heat Templates
4570 ---------------------
4572 ONAP supports nested Heat templates per the OpenStack specifications.
4573 Nested templates may be suitable for larger VNFs that contain many
4574 repeated instances of the same VM type(s). A common usage pattern is to
4575 create a nested template for each {vm-type} along with its supporting
4576 resources. The VNF module may then reference these component templates
4577 either statically by repeated definition or dynamically by using the
4578 resource OS::Heat::ResourceGroup.
4580 Nested Heat Template Requirements
4581 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4583 ONAP supports nested Heat Orchestration Templates. A Base Module,
4584 Incremental Module, and Cinder Volume Module may use nested heat.
4586 A Heat Orchestration Template may reference the nested heat statically
4587 by repeated definition.
4589 A Heat Orchestration Template may reference the nested heat dynamically
4590 using the resource OS::Heat::ResourceGroup.
4592 A Heat Orchestration template must have no more than three levels of
4593 nesting. ONAP supports a maximum of three levels.
4595 Nested heat templates must be referenced by file name. The use of
4596 resource\_registry in the environment file is not supported and must not
4599 A nested heat yaml file must have a unique file names within the scope
4602 ONAP does not support a directory hierarchy for nested templates. All
4603 templates must be in a single, flat directory (per VNF)
4605 A nested heat template may be used by any module within a given VNF.
4609 - Constrains must not be defined for any parameter enumerated in a
4610 nested heat template.
4612 - All parameters defined in nested heat must be passed in as properties
4613 of the resource calling the nested yaml file.
4615 - When OS::Nova::Server metadata parameters are past into a nested heat
4616 template, the parameter names must not change
4618 - With nested templates, outputs are required to expose any resource
4619 properties of the child templates to the parent template. Those would
4620 not explicitly be declared as parameters but simply referenced as
4621 get\_attribute targets against the “parent” resource.
4623 Nested Heat Template Example: Static
4624 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4628 .. code-block:: yaml
4634 dns_image_name: { get_param: dns_image_name }
4635 dns_flavor_name: { get_param: dns_flavor_name }
4636 availability_zone: { get_param: availability_zone_0 }
4637 security_group: { get_param: DNS_shared_sec_grp_id }
4638 oam_net_id: { get_param: oam_protected_net_id }
4639 dns_oam_ip: { get_param: dns_oam_ip_0 }
4640 dns_name: { get_param: dns_name_0 }
4641 vnf_name: { get_param: vnf_name }
4642 vnf_id: { get_param: vnf_id }
4643 vf_module_id: {get_param: vf_module_id}
4648 dns_image_name: { get_param: dns_image_name }
4649 dns_flavor_name: { get_param: dns_flavor_name }
4650 availability_zone: { get_param: availability_zone_1 }
4651 security_group: { get_param: DNS_shared_sec_grp_id }
4652 oam_net_id: { get_param: oam_protected_net_id }
4653 dns_oam_ip: { get_param: dns_oam_ip_1 }
4654 dns_name: { get_param: dns_name_1 }
4655 vnf_name: { get_param: vnf_name }
4656 vnf_id: { get_param: vnf_id }
4657 vf_module_id: {get_param: vf_module_id}
4661 .. code-block:: yaml
4664 type: OS::Neutron::Port
4668 template: VNF_NAME_dns_oam_port
4670 VNF_NAME: {get_param: vnf_name}
4671 network: { get_param: oam_net_id }
4672 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4673 security_groups: [{ get_param: security_group }]
4676 type: OS::Nova::Server
4678 name: { get_param: dns_names }
4679 image: { get_param: dns_image_name }
4680 flavor: { get_param: dns_flavor_name }
4681 availability_zone: { get_param: availability_zone }
4683 - port: { get_resource: dns_oam_0_port }
4685 vnf_id: { get_param: vnf_id }
4686 vf_module_id: { get_param: vf_module_id }
4687 vnf_name {get_param: vnf_name }
4689 Use of Heat ResourceGroup
4690 ~~~~~~~~~~~~~~~~~~~~~~~~~
4692 The OS::Heat::ResourceGroup is a useful Heat element for creating
4693 multiple instances of a given resource or collection of resources.
4694 Typically it is used with a nested Heat template, to create, for
4695 example, a set of identical OS::Nova::Server resources plus their
4696 related OS::Neutron::Port resources via a single resource in a master
4699 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4700 template that creates multiple instances of the same VM type.
4702 However, there are important caveats to be aware of:
4704 ResourceGroup does not deal with structured parameters
4705 (comma-delimited-list and json) as one might typically expect. In
4706 particular, when using a list-based parameter, where each list element
4707 corresponds to one instance of the ResourceGroup, it is not possible to
4708 use the intrinsic “loop variable” %index% in the ResourceGroup
4711 For instance, the following is **not** valid Heat for ResourceGroup:
4713 .. code-block:: yaml
4715 type: OS::Heat::ResourceGroup
4717 type: my_nested_vm_template.yaml
4719 name: {get_param: [vm_name_list, %index%]}
4721 Although this appears to use the nth entry of the vm\_name\_list list
4722 for the nth element of the ResourceGroup, it will in fact result in a
4723 Heat exception. When parameters are provided as a list (one for each
4724 element of a ResourceGroup), you must pass the complete parameter to the
4725 nested template along with the current index as separate parameters.
4727 Below is an example of an **acceptable** Heat Syntax for a
4730 .. code-block:: yaml
4732 type: OS::Heat::ResourceGroup
4734 type: my_nested_vm_template.yaml
4736 names: {get_param: vm_name_list}
4739 You can then reference within the nested template as:
4741 { get\_param: [names, {get\_param: index} ] }
4743 ResourceGroup Property count
4744 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4746 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4747 (even if the value is one) and that the value must be enumerated in the
4748 environment file. This is required for ONAP to build the TOSCA model for
4751 .. code-block:: yaml
4753 type: OS::Heat::ResourceGroup
4755 count: { get_param: count }
4758 type: my_nested_vm_template.yaml
4760 names: {get_param: vm_name_list}
4763 Availability Zone and ResourceGroups
4764 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4766 The resource OS::Heat::ResourceGroup and the property availability\_zone
4767 has been an “issue” with a few VNFs since ONAP only supports
4768 availability\_zone as a string parameter and not a
4769 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4770 to create Virtual Machines in more than one availability zone.
4772 There are numerous solutions to this issue. Below are two suggested
4775 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4776 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4777 availability\_zones by using the intrinsic function list\_join.
4779 .. code-block:: yaml
4782 type: OS::Heat::ResourceGroup
4784 count: { get_param: node_count }
4790 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4794 .. code-block:: yaml
4797 avaialability_zones:
4798 type: comma_delimited_list
4803 type: OS::Nova::Server
4805 name: { get_param: [ dns_names, get_param: index ] }
4806 image: { get_param: dns_image_name }
4807 flavor: { get_param: dns_flavor_name }
4808 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
4811 **Option 2:** Create a resource group per availability zone. A separate
4812 OS::Heat::ResourceGroup is created for each availability zone.
4817 Heat templates *should not* reference any HTTP-based resource
4818 definitions, any HTTP-based nested configurations, or any HTTP-based
4821 - During orchestration, ONAP *should not* retrieve any such resources
4822 from external/untrusted/unknown sources.
4824 - VNF images should not contain such references in user-data or other
4825 configuration/operational scripts that are specified via Heat or
4826 encoded into the VNF image itself.
4828 *Note:* HTTP-based references are acceptable if the HTTP-based reference
4829 is accessing information with the VM private/internal network.
4831 Heat Files Support (get\_file)
4832 ------------------------------
4834 Heat Templates may contain the inclusion of text files into Heat
4835 templates via the Heat get\_file directive. This may be used, for
4836 example, to define a common “user-data” script, or to inject files into
4837 a VM on startup via the “personality” property.
4839 Support for Heat Files is subject to the following limitations:
4841 - The get\_files targets must be referenced in Heat templates by file
4842 name, and the corresponding files should be delivered to ONAP along
4843 with the Heat templates.
4845 - URL-based file retrieval must not be used; it is not supported.
4847 - The included files must have unique file names within the scope of
4850 - ONAP does not support a directory hierarchy for included files.
4852 - All files must be in a single, flat directory per VNF.
4854 - Included files may be used by all Modules within a given VNF.
4856 - get\_file directives may be used in both non-nested and nested
4862 When Nova Servers are created via Heat templates, they may be passed a
4863 “keypair” which provides an ssh key to the ‘root’ login on the newly
4864 created VM. This is often done so that an initial root key/password does
4865 not need to be hard-coded into the image.
4867 Key pairs are unusual in OpenStack, because they are the one resource
4868 that is owned by an OpenStack User as opposed to being owned by an
4869 OpenStack Tenant. As a result, they are usable only by the User that
4870 created the keypair. This causes a problem when a Heat template attempts
4871 to reference a keypair by name, because it assumes that the keypair was
4872 previously created by a specific ONAP user ID.
4874 When a keypair is assigned to a server, the SSH public-key is
4875 provisioned on the VMs at instantiation time. They keypair itself is not
4876 referenced further by the VM (i.e. if the keypair is updated with a new
4877 public key, it would only apply to subsequent VMs created with that
4880 Due to this behavior, the recommended usage of keypairs is in a more
4881 generic manner which does not require the pre-requisite creation of a
4882 keypair. The Heat should be structured in such a way as to:
4884 - Pass a public key as a parameter value instead of a keypair name
4886 - Create a new keypair within the VNF Heat templates (in the base
4887 module) for use within that VNF
4889 By following this approach, the end result is the same as pre-creating
4890 the keypair using the public key – i.e., that public key will be
4891 provisioned in the new VM. However, this recommended approach also makes
4892 sure that a known public key is supplied (instead of having OpenStack
4893 generate a public/private pair to be saved and tracked outside of ONAP).
4894 It also removes any access/ownership issues over the created keypair.
4896 The public keys may be enumerated as a VNF Orchestration Constant in the
4897 environment file (since it is public, it is not a secret key), or passed
4898 at run-time as instance-specific parameters. ONAP will never
4899 automatically assign a public/private key pair.
4901 *Example (create keypair with an existing ssh public-key for {vm-type}
4902 of lb (for load balancer)):*
4904 .. code-block:: yaml
4914 type: OS::Nova::Keypair
4918 template: VNF_NAME_key_pair
4920 VNF_NAME: { get_param: vnf_name }
4921 public_key: {get_param: lb_ssh_public_key}
4922 save_private_key: false
4927 OpenStack allows a tenant to create Security groups and define rules
4928 within the security groups.
4930 Security groups, with their rules, may either be created in the Heat
4931 Orchestration Template or they can be pre-created in OpenStack and
4932 referenced within the Heat template via parameter(s). There can be a
4933 different approach for security groups assigned to ports on internal
4934 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
4935 there can be a common security group across all VMs for a specific
4936 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
4939 Anti-Affinity and Affinity Rules
4940 --------------------------------
4942 Anti-affinity or affinity rules are supported using normal OpenStack
4943 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
4944 created for each VM type to prevent them from residing on the same host,
4945 but they can be applied to multiple VM types to extend the
4946 affinity/anti-affinity across related VM types as well.
4950 In this example, the {network-role} has been defined as oam to represent
4951 an oam network and the {vm-type} have been defined as lb for load
4952 balancer and db for database.
4954 .. code-block:: yaml
4958 type: OS::Nova::ServerGroup
4963 $vnf_name: {get_param: vnf_name}
4964 template: $vnf_name-server_group1
4969 type: OS::Nova::ServerGroup
4974 $vnf_name: {get_param: vnf_name}
4975 template: $vnf_name-server_group2
4980 type: OS::Nova::Server
4984 group: {get_resource: db_server_group}
4987 type: OS::Nova::Server
4991 group: {get_resource: db_server_group}
4994 type: OS::Nova::Server
4998 group: {get_resource: lb_server_group}
5000 Resource Data Synchronization
5001 -----------------------------
5003 For cases where synchronization is required in the orchestration of Heat
5004 resources, two approaches are recommended:
5006 - Standard Heat depends\_on property for resources
5008 - Assures that one resource completes before the dependent resource
5011 - Definition of completeness to OpenStack may not be sufficient
5012 (e.g., a VM is considered complete by OpenStack when it is ready
5013 to be booted, not when the application is up and running).
5015 - Use of Heat Notifications
5017 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5020 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5022 - Dependent resource define depends\_on in the
5023 OS::Heat::WaitCondition resource.
5025 *Example: “depends\_on” case*
5027 In this example, the {network-role} has been defined as oam to represent
5028 an oam network and the {vm-type} has been defined as oam to represent an
5031 .. code-block:: yaml
5035 type: OS::Nova::Server
5037 name: {get_param: [oam_ names, 0]}
5038 image: {get_param: oam_image_name}
5039 flavor: {get_param: oam_flavor_name}
5040 availability_zone: {get_param: availability_zone_0}
5042 - port: {get_resource: oam01_port_0}
5043 - port: {get_resource: oam01_port_1}
5045 scheduler_hints: {group: {get_resource: oam_servergroup}}
5046 user_data_format: RAW
5049 type: OS::Neutron::Port
5051 network: {get_resource: oam_net_name}
5052 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5053 security_groups: [{get_resource: oam_security_group}]
5056 type: OS::Neutron::Port
5058 network: {get_param: oam_net_name}
5059 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5060 security_groups: [{get_resource: oam_security_group}]
5062 oam_01_vol_attachment:
5063 type: OS::Cinder::VolumeAttachment
5064 depends_on: oam_server_01
5066 volume_id: {get_param: oam_vol_1}
5067 mountpoint: /dev/vdb
5068 instance_uuid: {get_resource: oam_server_01}
5073 VNF/VM parameters may include availability zone IDs for VNFs that
5074 require high availability.
5076 The Heat must comply with the following requirements to specific
5077 availability zone IDs:
5079 - The Heat template should spread Nova and Cinder resources across the
5080 availability zones as desired
5082 Post Orchestration & VNF Configuration
5083 --------------------------------------
5085 Heat templates should contain a minimum amount of post-orchestration
5086 configuration data. For instance, *do not* embed complex user-data
5087 scripts in the template with large numbers of configuration parameters
5088 to the Heat template.
5090 - VNFs may provide configuration APIs for use after VNF creation. Such
5091 APIs will be invoked via application and/or SDN controllers.
5093 *Note:* It is important to follow this convention to the extent possible
5094 even in the short-term as of the long-term direction.
5096 c. VNFM Driver Develop Steps
5097 ==============================
5099 Aid to help the VNF vendor to fasten the integration with the NFVO via
5100 Special VNFM, the ONAP provides the documents. In this charter, the
5101 develop steps for VNF vendors will be introduced.
5103 First, using the VNF SDK tools to design the VNF with TOSCA model and
5104 output the VNF TOSCA package. The VNF package can be validated, and
5107 Second, the VNF vendor should provide SVNFM Driver in the ONAP, which
5108 is a micro service and in duty of translation interface from NFVO to
5109 SVNFM. The interface of NFVO is aligned to the ETSI IFA interfaces and
5110 can be gotten in the charter 5.5. The interface of SVNFM is provided by
5111 the VNF vendor self.
5113 d. Create SVNFM Adaptor Mircoservice
5114 =======================================
5116 Some vnfs are managed by special VNFM, before add SVNFM to ONAP, a
5117 SVNFM adaptor must be added to ONAP to adapter the interface of NFVO
5120 A SVNFM adaptor is a micro service with unique name and an appointed
5121 port, when started up, it must be auto registered to MSB(Micro server
5122 bus),following describes an example rest of register to MSB:
5124 POST /openoapi/microservices/v1/services
5128 "serviceName": "catalog",
5132 "url": "/openoapi/catalog/v1",
5142 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob