3 **5. VNF Modeling Requirements**
4 =====================================
13 This reference document is the VNF TOSCA Template Requirements for
14 ONAP, which provides recommendations and standards for building VNF
15 TOSCA templates compatible with ONAP initial implementations of
16 Network Cloud. It has the following features:
18 1. VNF TOSCA template designer supports GUI and CLI.
20 2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
21 Draft 04-Revision 06”.
23 3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
24 Threading, SRIOV， etc.
29 This document is intended for persons developing VNF TOSCA templates
30 that will be orchestrated by ONAP.
35 ONAP implementations of Network Cloud supports TOSCA Templates, also
36 referred to as TOSCA in this document.
38 ONAP requires the TOSCA Templates to follow a specific format. This
39 document provides the mandatory, recommended, and optional requirements
40 associated with this format.
45 The document includes three charters to help the VNF providers to use the
46 VNF model design tools and understand the VNF package structure and VNF
49 In the ONAP, VNF Package and VNFD template can be designed by manually
50 or via model designer tools. VNF model designer tools can provide the
51 GUI and CLI tools for the VNF provider to develop the VNF Package and VNFD
54 The VNF package structure is align to the NFV TOSCA protocol, and
57 The VNFD and VNF package are all align to the NFV TOSCA protocol, which
58 supports multiple TOSCA template yaml files, and also supports
59 self-defined node or other extensions.
64 TOSCA templates supported by ONAP must follow the requirements
65 enumerated in this section.
70 TOSCA defines a Meta model for defining IT services. This Meta model
71 defines both the structure of a service as well as how to manage it. A
72 Topology Template (also referred to as the topology model of a service)
73 defines the structure of a service. Plans define the process models that
74 are used to create and terminate a service as well as to manage a
75 service during its whole lifetime.
77 A Topology Template consists of a set of Node Templates and Relationship
78 Templates that together define the topology model of a service as a (not
79 necessarily connected) directed graph. A node in this graph is
80 represented by a *Node Template*. A Node Template specifies the
81 occurrence of a Node Type as a component of a service. A *Node Type*
82 defines the properties of such a component (via *Node Type Properties*)
83 and the operations (via *Interfaces*) available to manipulate the
84 component. Node Types are defined separately for reuse purposes and a
85 Node Template references a Node Type and adds usage constraints, such as
86 how many times the component can occur.
90 Figure 1: Structural Elements of Service Template and their Relations
92 TOSCA Modeling Principles & Data Model
93 --------------------------------------
95 This section describing TOSCA modeling principles and data model for
96 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
97 V1.0], or new type based on ETSI NFV requirements, etc.
99 VNF Descriptor Template
100 -----------------------
102 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
103 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
104 Links, External Connection Points, Scaling Aspects, Instantiation Levels
105 and Deployment Flavours.
107 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
108 represents the contract & interface of a VNF and ensures the
109 interoperability across the NFV functional blocks.
111 The main parts of the VNFD are the following:
113 - VNF topology: it is modeled in a cloud agnostic way using virtualized
114 containers and their connectivity. Virtual Deployment Units (VDU)
115 describe the capabilities of the virtualized containers, such as
116 virtual CPU, RAM, disks; their connectivity is modeled with VDU
117 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
118 and VNF External Connection Point Descriptors (VnfExternalCpd);
120 - VNF deployment aspects: they are described in one or more deployment
121 flavours, including instantiation levels, supported LCM operations,
122 VNF LCM operation configuration parameters, placement constraints
123 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
124 and scaling aspect for horizontal scaling.
126 The following table defines the TOSCA Type “derived from” values that
127 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
128 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
130 +-----------------------------------------+---------------------------------------+-----------------------+
131 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
133 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
134 +=========================================+=======================================+=======================+
135 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
136 +-----------------------------------------+---------------------------------------+-----------------------+
137 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
138 +-----------------------------------------+---------------------------------------+-----------------------+
139 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
140 +-----------------------------------------+---------------------------------------+-----------------------+
141 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
142 +-----------------------------------------+---------------------------------------+-----------------------+
143 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
144 +-----------------------------------------+---------------------------------------+-----------------------+
145 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
146 +-----------------------------------------+---------------------------------------+-----------------------+
147 | Virtual Storage | | |
148 +-----------------------------------------+---------------------------------------+-----------------------+
149 | Virtual Compute | | |
150 +-----------------------------------------+---------------------------------------+-----------------------+
151 | Software Image | | |
152 +-----------------------------------------+---------------------------------------+-----------------------+
153 | Deployment Flavour | | |
154 +-----------------------------------------+---------------------------------------+-----------------------+
155 | Scaling Aspect | | |
156 +-----------------------------------------+---------------------------------------+-----------------------+
157 | Element Group | | |
158 +-----------------------------------------+---------------------------------------+-----------------------+
159 | Instantiation Level | | |
160 +-----------------------------------------+---------------------------------------+-----------------------+
162 +--------------------------------------------------------------------+
163 | +--------------------------------------------------------------+ |
164 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
166 | | description: VNFD TOSCA file demo | |
170 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
172 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
174 | | | **node\_types: | |
175 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
176 | | derived\_from:** tosca.nodes.nfv.VNF | |
177 | | | **requirements: | |
178 | | **- **sriov\_plane: | |
179 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
180 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
181 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
182 | +--------------------------------------------------------------+ |
183 +====================================================================+
184 +--------------------------------------------------------------------+
189 1. SR-IOV Passthrought
191 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
194 +------------------------------------------------+
203 | tosca\_name: SRIOV\_Port |
207 | virtual\_network\_interface\_requirements: |
211 | support\_mandatory: false |
213 | description: sriov |
221 | description: sriov port |
223 | layer\_protocol: ipv4 |
227 | - virtual\_binding: |
229 | capability: virtual\_binding |
235 | type: tosca.relationships.nfv.VirtualBindsTo |
239 | node: tosca.nodes.Root |
241 | type: tosca.nodes.nfv.VduCpd |
243 | substitution\_mappings: |
253 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
254 +------------------------------------------------+
258 Definitions of mem\_page\_size as one property shall be added to
259 Properties and set the value to large if one VDU node supports
260 huagepages. Here is an example.
262 +----------------------------------+
271 | tosca\_name: Huge\_pages\_demo |
275 | mem\_page\_size:large |
276 +==================================+
277 +----------------------------------+
281 Likewise, we shall add definitions of numa to
282 requested\_additional\_capabilities if we wand VUD nodes to support
283 NUMA. Here is an example.
285 +-------------------------------------------------+
286 | topology\_template: |
294 | virtual\_compute: |
300 | numa\_enabled: true |
302 | virtual\_mem\_size: 2 GB |
304 | requested\_additional\_capabilities: |
308 | support\_mandatory: true |
310 | requested\_additional\_capability\_name: numa |
312 | target\_performance\_parameters: |
314 | hw:numa\_nodes: "2" |
316 | hw:numa\_cpus.0: "0,1" |
318 | hw:numa\_mem.0: "1024" |
320 | hw:numa\_cpus.1: "2,3,4,5" |
322 | hw:numa\_mem.1: "1024" |
323 +-------------------------------------------------+
327 Definitions of Hyper-Theading are necessary as one of
328 requested\_additional\_capabilities of one VUD node if that node
329 supports Hyper-Theading. Here is an example.
331 +-------------------------------------------------------------+
332 | topology\_template: |
340 | virtual\_compute: |
346 | numa\_enabled: true |
348 | virtual\_mem\_size: 2 GB |
350 | requested\_additional\_capabilities: |
352 | hyper\_threading: |
354 | support\_mandatory: true |
356 | requested\_additional\_capability\_name: hyper\_threading |
358 | target\_performance\_parameters: |
360 | hw:cpu\_sockets : "2" |
362 | hw:cpu\_threads : "2" |
364 | hw:cpu\_cores : "2" |
366 | hw:cpu\_threads\_policy: "isolate" |
367 +-------------------------------------------------------------+
371 Definitions of ovs\_dpdk are necessary as one of
372 requested\_additional\_capabilities of one VUD node if that node
373 supports dpdk. Here is an example.
375 +------------------------------------------------------+
376 | topology\_template: |
384 | virtual\_compute: |
390 | numa\_enabled: true |
392 | virtual\_mem\_size: 2 GB |
394 | requested\_additional\_capabilities: |
398 | support\_mandatory: true |
400 | requested\_additional\_capability\_name: ovs\_dpdk |
402 | target\_performance\_parameters: |
404 | sw:ovs\_dpdk: "true" |
405 +------------------------------------------------------+
407 NFV TOSCA Type Definition
408 -------------------------
410 tosca.capabilites.nfv.VirtualCompute
411 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
413 +---------------------------+-----------------------------------------+
414 | **Shorthand Name** | VirtualCompute |
415 +===========================+=========================================+
416 | **Type Qualified Name** | tosca: VirtualCompute |
417 +---------------------------+-----------------------------------------+
418 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
419 +---------------------------+-----------------------------------------+
420 | **derived from** | tosca.nodes.Root |
421 +---------------------------+-----------------------------------------+
426 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
427 | Name | Required | Type | Constraints | Description |
428 +=====================================+============+=====================================================+===============+=========================================================+
429 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
430 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
431 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
432 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
433 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
434 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
435 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
437 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
442 +-----------------------------------------------------------+
443 | tosca.capabilities.nfv.VirtualCompute: |
445 | derived\_from: tosca.capabilities.Root |
449 | requested\_additional\_capabilities: |
455 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
461 | type: tosca.datatypes.nfv.VirtualMemory |
467 | type: tosca.datatypes.nfv.VirtualCpu |
470 +-----------------------------------------------------------+
472 tosca.nodes.nfv.VDU.Compute
473 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
475 The NFV Virtualization Deployment Unit (VDU) compute node type
476 represents a VDU entity which it describes the deployment and
477 operational behavior of a VNF component (VNFC), as defined by **[ETSI
480 +-----------------------+-------------------------------+
481 | Shorthand Name | VDU.Compute |
482 +=======================+===============================+
483 | Type Qualified Name | tosca:VDU.Compute |
484 +-----------------------+-------------------------------+
485 | Type URI | tosca.nodes.nfv.VDU.Compute |
486 +-----------------------+-------------------------------+
487 | derived\_from | tosca.nodes.Compute |
488 +-----------------------+-------------------------------+
501 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
502 | Name | Type | Constraints | Description |
503 +=========================+=================================================+===============+=====================================================================================================+
504 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
505 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
506 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
508 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
509 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
510 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
512 | | editor note: need to create a capability type | | |
513 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
518 +-----------------------------------------------------------------------------------------------------+
519 | tosca.nodes.nfv.VDU.Compute: |
521 | derived\_from: tosca.nodes.Compute |
539 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
547 | nfvi\_constraints: |
557 | configurable\_properties: |
563 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
569 | private\_address: |
571 | status: deprecated |
575 | status: deprecated |
579 | status: deprecated |
583 | status: deprecated |
587 | virtual\_compute: |
589 | type: tosca.capabilities.nfv.VirtualCompute |
591 | virtual\_binding: |
593 | type: tosca.capabilities.nfv.VirtualBindable |
595 | #monitoring\_parameter: |
597 | # modeled as ad hoc (named) capabilities in VDU node template |
603 | # cpu\_load: tosca.capabilities.nfv.Metric |
605 | # memory\_usage: tosca.capabilities.nfv.Metric |
607 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
609 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
611 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
613 | occurrences: [0,UNBOUNDED] |
617 | occurrences: [0,0] |
621 | occurrences: [0,0] |
623 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
625 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
629 | occurrences: [0,UNBOUND] |
633 | - virtual\_storage: |
635 | capability: tosca.capabilities.nfv.VirtualStorage |
637 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
639 | node: tosca.nodes.nfv.VDU.VirtualStorage |
641 | occurences: [ 0, UNBOUNDED ] |
643 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
645 | occurrences: [0,0] |
653 | type: tosca.artifacts.nfv.SwImage |
654 +-----------------------------------------------------------------------------------------------------+
658 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
659 | Name | Required | Type | Constraints | Description |
660 +===========+============+===============================+===============+================================================+
661 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
662 | | | | | directly realizing this virtual storage |
663 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
673 The TOSCA Cpd node represents network connectivity to a compute resource
674 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
675 used as parent for the various Cpd types.
677 +-----------------------+-----------------------+
678 | Shorthand Name | Cpd |
679 +=======================+=======================+
680 | Type Qualified Name | tosca:Cpd |
681 +-----------------------+-----------------------+
682 | Type URI | tosca.nodes.nfv.Cpd |
683 +-----------------------+-----------------------+
689 +--------+------------+--------+---------------+---------------+
690 | Name | Required | Type | Constraints | Description |
691 +========+============+========+===============+===============+
692 +--------+------------+--------+---------------+---------------+
707 +----------------------------------------------------------------------+
708 | tosca.nodes.nfv.Cpd: |
710 | derived\_from: tosca.nodes.Root |
720 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
724 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
730 | - valid\_values: [ root, leaf ] |
746 | type: tosca.datatype.nfv.AddressData |
749 +----------------------------------------------------------------------+
751 Additional Requirement
752 ^^^^^^^^^^^^^^^^^^^^^^
756 tosca.nodes.nfv.VduCpd
757 ~~~~~~~~~~~~~~~~~~~~~~
759 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
760 network connectivity between a VNFC instance (based on this VDU) and an
761 internal VL as defined by [ETSI GS NFV-IFA 011].
763 +-----------------------+--------------------------+
764 | Shorthand Name | VduCpd |
765 +=======================+==========================+
766 | Type Qualified Name | tosca: VduCpd |
767 +-----------------------+--------------------------+
768 | Type URI | tosca.nodes.nfv.VduCpd |
769 +-----------------------+--------------------------+
775 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
776 | Name | Required | Type | Constraints | Description |
777 +===============================+============+==========================================+==========================================================================+
778 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
779 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
780 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
781 | requirements | | | | realising the CPs instantiated from this CPD |
782 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
792 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
793 | Name | Required | Type | Constraints | Description |
794 +====================+============+==========================================+===============+==========================================================+
795 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
796 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
797 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
798 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
803 +----------------------------------------------------------------+
804 | tosca.nodes.nfv.VduCpd: |
806 | derived\_from: tosca.nodes.nfv.Cpd |
810 | bitrate\_requirement: |
816 | virtual\_network\_interface\_requirements |
822 | type: VirtualNetworkInterfaceRequirements |
830 | capability: tosca.capabilities.nfv.VirtualLinkable |
832 | relationship: tosca.relationships.nfv.VirtualLinksTo |
834 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
836 | capability: tosca.capabilities.nfv.VirtualBindable |
838 | relationship: tosca.relationships.nfv.VirtualBindsTo |
840 | node: tosca.nodes.nfv.VDU |
841 +----------------------------------------------------------------+
843 tosca.nodes.nfv.VDU.VirtualStorage
844 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
846 The NFV VirtualStorage node type represents a virtual storage entity
847 which it describes the deployment and operational behavior of a virtual
848 storage resources, as defined by **[ETSI NFV IFA011].**
850 **[editor note]** open issue: should NFV profile use the current storage
851 model as described in YAML 1.1. Pending on Shitao proposal (see
852 NFVIFA(17)000110 discussion paper)
854 **[editor note]** new relationship type as suggested in Matt
855 presentation. Slide 8. With specific rules of “valid\_target\_type”
857 +---------------------------+--------------------------------------+
858 | **Shorthand Name** | VirtualStorage |
859 +===========================+======================================+
860 | **Type Qualified Name** | tosca: VirtualStorage |
861 +---------------------------+--------------------------------------+
862 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
863 +---------------------------+--------------------------------------+
864 | **derived\_from** | tosca.nodes.Root |
865 +---------------------------+--------------------------------------+
867 tosca.artifacts.nfv.SwImage
868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
870 +---------------------------+------------------------------------+
871 | **Shorthand Name** | SwImage |
872 +===========================+====================================+
873 | **Type Qualified Name** | tosca:SwImage |
874 +---------------------------+------------------------------------+
875 | **Type URI** | tosca.artifacts.nfv.SwImage |
876 +---------------------------+------------------------------------+
877 | **derived\_from** | tosca.artifacts.Deployment.Image |
878 +---------------------------+------------------------------------+
883 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
884 | Name | Required | Type | Constraints | Description |
885 +==========================================+============+====================+===============+====================================================================================================+
886 | name | yes | string | | Name of this software image |
887 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
888 | version | yes | string | | Version of this software image |
889 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
890 | checksum | yes | string | | Checksum of the software image file |
891 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
892 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
893 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
894 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
895 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
896 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
897 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
898 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
899 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
900 | Size | yes | scalar-unit.size | | The size of this software image |
901 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
902 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
903 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
904 | operating\_system | no | string | | Identifies the operating system used in the software image. |
905 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
906 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
907 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
912 +-----------------------------------------------------+
913 | tosca.artifacts.nfv.SwImage: |
915 | derived\_from: tosca.artifacts.Deployment.Image |
917 | properties or metadata: |
941 | container\_format: |
955 | type: scalar-unit.size # Number |
961 | type: scalar-unit.size # Number |
967 | type: scalar-unit.size # Number |
977 | operating\_system: |
983 | supported\_virtualisation\_environments: |
992 +-----------------------------------------------------+
997 openovnf\_\_vOpenNAT.yaml
998 ~~~~~~~~~~~~~~~~~~~~~~~~~
1000 +-------------------------------------------------------------+
1003 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1005 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1007 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1009 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1011 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1013 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1015 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1017 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1019 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1021 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1023 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1025 | - openonfv\_\_tosca.capabilities.Container.yaml |
1027 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1029 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1031 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1033 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1035 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1037 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1039 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1043 | vnfProductName: openNAT |
1045 | vnfdVersion: 1.0.0 |
1047 | vnfProvider: intel |
1051 | csarVersion: 1.0.0 |
1053 | vnfdId: openNAT-1.0 |
1055 | csarProvider: intel |
1057 | vnfProductInfoDescription: openNAT |
1065 | localizationLanguage: '[english, chinese]' |
1069 | defaultLocalizationLanguage: english |
1071 | vnfProductInfoName: openNAT |
1073 | vnfSoftwareVersion: 1.0.0 |
1075 | topology\_template: |
1077 | node\_templates: |
1085 | file: /swimages/xenial-snat.qcow2 |
1087 | type: tosca.artifacts.nfv.SwImage |
1091 | name: vNatVNFImage |
1095 | checksum: "5000" |
1097 | container\_format: bare |
1099 | disk\_format: qcow2 |
1101 | min\_disk: 10 GB |
1107 | sw\_image: /swimages/xenial-snat.qcow2 |
1109 | operating\_system: unbantu |
1113 | tosca\_name: vdu\_vNat |
1117 | virtual\_compute: |
1121 | virtual\_memory: |
1123 | numa\_enabled: true |
1125 | virtual\_mem\_size: 2 GB |
1127 | requested\_additional\_capabilities: |
1131 | support\_mandatory: true |
1133 | requested\_additional\_capability\_name: numa |
1135 | target\_performance\_parameters: |
1137 | hw:numa\_nodes: "2" |
1139 | hw:numa\_cpus.0: "0,1" |
1141 | hw:numa\_mem.0: "1024" |
1143 | hw:numa\_cpus.1: "2,3,4,5" |
1145 | hw:numa\_mem.1: "1024" |
1147 | hyper\_threading: |
1149 | support\_mandatory: true |
1151 | requested\_additional\_capability\_name: hyper\_threading |
1153 | target\_performance\_parameters: |
1155 | hw:cpu\_sockets : "2" |
1157 | hw:cpu\_threads : "2" |
1159 | hw:cpu\_cores : "2" |
1161 | hw:cpu\_threads\_policy: "isolate" |
1165 | support\_mandatory: true |
1167 | requested\_additional\_capability\_name: ovs\_dpdk |
1169 | target\_performance\_parameters: |
1171 | sw:ovs\_dpdk: "true" |
1175 | cpu\_architecture: X86 |
1177 | num\_virtual\_cpu: 2 |
1181 | configurable\_properties: |
1185 | additional\_vnfc\_configurable\_properties: |
1191 | descrption: the virtual machine of vNat |
1199 | - virtual\_storage: |
1201 | capability: virtual\_storage |
1203 | node: vNAT\_Storage |
1209 | location: /mnt/volume\_0 |
1211 | type: tosca.relationships.nfv.VDU.AttachedTo |
1213 | - local\_storage: |
1215 | node: tosca.nodes.Root |
1217 | type: tosca.nodes.nfv.VDU.Compute |
1223 | tosca\_name: SRIOV\_Port |
1227 | virtual\_network\_interface\_requirements: |
1231 | support\_mandatory: false |
1233 | description: sriov |
1241 | description: sriov port |
1243 | layer\_protocol: ipv4 |
1247 | - virtual\_binding: |
1249 | capability: virtual\_binding |
1255 | type: tosca.relationships.nfv.VirtualBindsTo |
1257 | - virtual\_link: |
1259 | node: tosca.nodes.Root |
1261 | type: tosca.nodes.nfv.VduCpd |
1267 | tosca\_name: vNAT\_Storage |
1271 | id: vNAT\_Storage |
1273 | size\_of\_storage: 10 GB |
1275 | rdma\_enabled: false |
1277 | type\_of\_storage: volume |
1279 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1281 | substitution\_mappings: |
1291 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1293 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1294 +-------------------------------------------------------------+
1296 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1297 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1299 +------------------------------------------------------------+
1302 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1306 | tosca.nodes.nfv.VDU.VirtualStorage: |
1310 | virtual\_storage: |
1312 | type: tosca.capabilities.nfv.VirtualStorage |
1314 | derived\_from: tosca.nodes.Root |
1322 | size\_of\_storage: |
1332 | type\_of\_storage: |
1336 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1337 +------------------------------------------------------------+
1339 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1340 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1342 +-----------------------------------------------------------------+
1345 | tosca.datatypes.nfv.L3AddressData: |
1349 | number\_of\_ip\_address: |
1355 | ip\_address\_assignment: |
1359 | ip\_address\_type: |
1363 | - valid\_values: |
1373 | floating\_ip\_activated: |
1377 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1387 | support\_mandatory: |
1405 | tosca.datatype.nfv.AddressData: |
1413 | - valid\_values: |
1421 | l2\_address\_data: |
1425 | type: tosca.datatypes.nfv.L2AddressData |
1427 | l3\_address\_data: |
1431 | type: tosca.datatypes.nfv.L3AddressData |
1433 | tosca.datatypes.nfv.L2AddressData: {} |
1437 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1439 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1443 | tosca.nodes.nfv.VduCpd: |
1445 | derived\_from: tosca.nodes.Root |
1449 | virtual\_network\_interface\_requirements: |
1453 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1463 | - valid\_values: |
1473 | bitrate\_requirement: |
1485 | layer\_protocol: |
1489 | - valid\_values: |
1509 | type: tosca.datatype.nfv.AddressData |
1517 | - virtual\_binding: |
1519 | capability: tosca.capabilities.nfv.VirtualBindable |
1527 | - virtual\_link: |
1529 | capability: tosca.capabilities.nfv.VirtualBindable |
1537 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1538 +-----------------------------------------------------------------+
1540 .. |image1| image:: Image1.png
1543 .. |image2| image:: Image2.png
1557 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1558 Markup Language) is a human friendly data serialization standard for all
1559 programming languages. See http://www.yaml.org/.
1561 Heat Orchestration Template Format
1562 ----------------------------------
1564 Heat Orchestration templates must be defined in YAML.
1568 - Tabs are NOT allowed, use spaces ONLY.
1570 - You MUST indent your properties and lists with 1 or more spaces.
1572 - All Resource IDs and resource property parameters are case-sensitive.
1573 (e.g., "ThIs", is not the same as "thiS")
1575 Heat Orchestration Template Structure
1576 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1578 Heat Orchestration template structure follows the following format, as
1579 defined by OpenStack at
1580 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1582 .. code-block:: yaml
1584 heat_template_version: <date>
1587 # a description of the template
1590 # a declaration of input parameter groups and order
1593 # declaration of input parameters
1596 # declaration of template resources
1599 # declaration of output parameters
1602 # declaration of conditions
1605 Heat Orchestration templates for ONAP must contain the following
1608 - heat\_template\_version:
1616 Heat Orchestration templates for ONAP may contain the following
1619 - parameter\_groups:
1623 heat\_template\_version
1624 ^^^^^^^^^^^^^^^^^^^^^^^
1626 This section is ONAP mandatory. The heat\_template\_version must be set
1627 to a date that is supported by the OpenStack environment.
1632 This ONAP mandatory section allows for a description of the template.
1637 This ONAP optional section allows for specifying how the input
1638 parameters should be grouped and the order to provide the parameters in.
1643 The parameter section is ONAP mandatory. This section allows for
1644 specifying input parameters that have to be provided when instantiating
1645 the template. Each parameter is specified in a separated nested block
1646 with the name of the parameters defined in the first line and additional
1647 attributes (e.g., type, label) defined as nested elements.
1649 The Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process
1650 requires all parameters declared in a template to be used in a resource
1651 with the exception of the parameters for the OS::Nova::Server property
1652 availability\_zone. See `Property: availability\_zone`_. for more details on
1655 .. code-block:: yaml
1659 type: <string | number | json | comma_delimited_list | boolean>
1660 label: <human-readable name of the parameter>
1661 description: <description of the parameter>
1662 default: <default value for parameter>
1663 hidden: <true | false>
1665 <parameter constraints>
1666 immutable: <true | false>
1670 - The name of the parameter.
1672 - ONAP requires that the param name must contain only alphanumeric
1673 characters and “\_” underscores. Special characters must not be
1678 - The type of the parameter. Supported types are string, number,
1679 comma\_delimited\_list, json and boolean.
1681 - This attribute must be provided per the OpenStack Heat
1682 Orchestration Template standard.
1686 - A human readable name for the parameter.
1688 - This attribute is optional.
1692 - A human readable description for the parameter.
1694 - This attribute is ONAP mandatory; it must be provided. (Note that
1695 this attribute is OpenStack optional.)
1699 - A default value for the parameter.
1701 - ONAP does not support this attribute; it *must not* be provided in
1702 the Heat Orchestration Template. If a parameter has a default
1703 value, it must be provided in the environment file. (Note that
1704 this attribute is OpenStack optional.)
1708 - Defines whether the parameters should be hidden when a user
1709 requests information about a stack created from the template. This
1710 attribute can be used to hide passwords specified as parameters.
1712 - This attribute is optional and defaults to false.
1716 - A list of constraints to apply. The constraints block of a
1717 parameter definition defines additional validation constraints
1718 that apply to the value of the parameter. The parameter values
1719 provided in the Heat Orchestration Template are validated against
1720 the constraints at instantiation time. The constraints are defined
1721 as a list with the following syntax
1725 - <constraint type>: <constraint definition>
1727 description: <constraint description>
1729 - constraint type: Type of constraint to apply.
1731 - constraint definition: The actual constraint, depending on the
1734 - description: A description of the constraint. The text is presented
1735 to the user when the value the user defines violates the constraint.
1736 If omitted, a default validation message is presented to the user.
1737 This attribute is optional.
1739 - When the parameter type is set to number, the Heat Orchestration
1740 Template uploaded into ONAP must have constraints for range or
1743 - range: The range constraint applies to parameters of type number.
1744 It defines a lower and upper limit for the numeric value of the
1745 parameter. The syntax of the range constraint is
1747 range: { min: <lower limit>, max: <upper limit> }
1749 It is possible to define a range constraint with only a lower limit
1752 - allowed\_values: The allowed\_values constraint applies to parameters
1753 of type string or number. It specifies a set of possible values for a
1754 parameter. At deployment time, the user-provided value for the
1755 respective parameter must match one of the elements of the list. The
1756 syntax of the allowed\_values constraint is
1758 allowed\_values: [ <value>, <value>, ... ]
1760 Alternatively, the following YAML list notation can be used
1770 - Other <constraint type> are optional, they may be used (e.g., length,
1771 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1774 - Note that constrains must not be defined for any parameter enumerated
1775 in a nested heat template.
1777 - Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
1781 - Defines whether the parameter is updatable. Stack update fails, if
1782 this is set to true and the parameter value is changed.
1784 - This attribute is optional and defaults to false.
1789 This section is ONAP mandatory; it must be provided. This section
1790 contains the declaration of the single resources of the template. This
1791 section with at least one resource must be defined in the Heat
1792 Orchestration Template, or the template would not create any resources
1793 when being instantiated.
1795 Each resource is defined as a separate block in the resources section
1796 with the following syntax.
1798 .. code-block:: yaml
1802 type: <resource type>
1804 <property name>: <property value>
1806 <resource specific metadata>
1807 depends\_on: <resource ID or list of ID>
1808 update\_policy: <update policy>
1809 deletion\_policy: <deletion policy>
1810 external\_id: <external resource ID>
1811 condition: <condition name or expression or boolean>
1815 - A resource ID that must be unique within the resources section of
1816 the Heat Orchestration Template.
1818 - ONAP requires that the resource ID must be unique across all Heat
1819 Orchestration Templates that compose the VNF. This requirement
1820 also applies when a VNF is composed of more than one Heat
1821 Orchestration Template (see ONAP VNF Modularity Overview).
1823 - The naming convention for a resource ID is provided in `Resource IDs`_.
1827 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1828 Note that the type may specify a nested heat file. This attribute
1833 - A list of resource-specific properties. The property value can be
1834 provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
1836 - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
1840 - Resource-specific metadata. This section is optional, except for
1841 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1845 - Dependencies of the resource on one or more resources of the
1846 template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
1850 - Update policy for the resource, in the form of a nested
1851 dictionary. Whether update policies are supported and what the
1852 exact semantics are depends on the type of the current resource.
1853 This attribute is optional.
1857 - Deletion policy for the resource. The allowed deletion policies
1858 are Delete, Retain, and Snapshot. Beginning with
1859 heat\_template\_version 2016-10-14, the lowercase equivalents
1860 delete, retain, and snapshot are also allowed. This attribute is
1861 optional; the default policy is to delete the physical resource
1862 when deleting a resource from the stack.
1866 - Allows for specifying the resource\_id for an existing external
1867 (to the stack) resource. External resources cannot depend on other
1868 resources, but we allow other resources to depend on external
1869 resource. This attribute is optional. Note: when this is
1870 specified, properties will not be used for building the resource
1871 and the resource is not managed by Heat. This is not possible to
1872 update that attribute. Also, resource won’t be deleted by heat
1873 when stack is deleted.
1877 - Condition for the resource. The condition decides whether to
1878 create the resource or not. This attribute is optional.
1883 This ONAP optional section allows for specifying output parameters
1884 available to users once the template has been instantiated. If the
1885 section is specified, it will need to adhere to specific requirements.
1886 See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
1888 Environment File Format
1889 -----------------------
1891 The environment file is a yaml text file.
1892 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1894 The environment file can contain the following sections:
1896 - parameters: A list of key/value pairs.
1898 - resource\_registry: Definition of custom resources.
1900 - parameter\_defaults: Default parameters passed to all template
1903 - encrypted\_parameters: List of encrypted parameters.
1905 - event\_sinks: List of endpoints that would receive stack events.
1907 - parameter\_merge\_strategies: Merge strategies for merging parameters
1908 and parameter defaults from the environment file.
1910 Environment files for ONAP must contain the following sections:
1914 Environment files for ONAP may contain the following sections:
1916 - resource\_registry:
1918 - parameter\_defaults:
1920 - encrypted\_parameters:
1924 - parameter\_merge\_strategies:
1926 The use of an environment file in OpenStack is optional. In ONAP, it is
1927 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
1928 corresponding environment file, even if no parameters are enumerated in
1929 the mandatory parameter section.
1931 (Note that ONAP, the open source version of ONAP, does not
1932 programmatically enforce the use of an environment file.)
1934 SDC Treatment of Environment Files
1935 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1937 Parameter values enumerated in the environment file are used by SDC as
1938 the default value. However, the SDC user may use the SDC GUI to
1939 overwrite the default values in the environment file.
1941 SDC generates a new environment file for distribution to MSO based on
1942 the uploaded environment file and the user provided GUI updates. The
1943 user uploaded environment file is discarded when the new file is
1946 ONAP has requirements for what parameters must be enumerated in the
1947 environment file and what parameter must not be enumerated in the
1948 environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1950 Nested Heat Orchestration Templates Overview
1951 --------------------------------------------
1953 ONAP supports nested Heat Orchestration Templates per OpenStack
1956 A Base Module may utilize nested templates.
1958 An Incremental Module may utilize nested templates.
1960 A Cinder Volume Module may utilize nested templates.
1962 A nested template must not define parameter constraints in the parameter
1965 Nested templates may be suitable for larger VNFs that contain many
1966 repeated instances of the same VM type(s). A common usage pattern is to
1967 create a nested template for each VM type along with its supporting
1968 resources. The Heat Orchestration Template may then reference these
1969 nested templates either statically (by repeated definition) or
1970 dynamically (via OS::Heat::ResourceGroup).
1972 See `Nested Heat Templates`_ for additional details.
1974 ONAP Heat Orchestration Template Filenames
1975 ------------------------------------------
1977 In order to enable ONAP to understand the relationship between Heat
1978 files, the following Heat file naming convention must be utilized.
1980 In the examples below, <text> represents any alphanumeric string that
1981 must not contain any special characters and must not contain the word
1987 The file name for the base module must include “base” in the filename
1988 and must match one of the following options:
1990 - base\_<text>.y[a]ml
1992 - <text>\_base.y[a]ml
1996 - <text>\_base\_<text>.y[a]ml
1998 The base module’s corresponding environment file must be named identical
1999 to the base module with “.y[a]ml” replaced with “.env”.
2004 There is no explicit naming convention for the incremental modules. As
2005 noted above, <text> represents any alphanumeric string that must not
2006 contain any special characters and must not contain the word “base”.
2010 The incremental module’s corresponding environment file must be named
2011 identical to the incremental module with “.y[a]ml” replaced with “.env”.
2013 To clearly identify the incremental module, it is recommended to use the
2014 following naming options for modules:
2016 - module\_<text>.y[a]ml
2018 - <text>\_module.y[a]ml
2022 Cinder Volume Modules
2023 ~~~~~~~~~~~~~~~~~~~~~
2025 The file name for the Cinder volume module must be named the same as the
2026 corresponding module it is supporting (base module or incremental
2027 module) with “\_volume” appended
2029 - <base module name>\_volume.y[a]ml
2031 - <incremental module name>\_volume.y[a]ml
2033 The volume module’s corresponding environment file must be named
2034 identical to the volume module with “.y[a]ml” replaced with “.env”.
2039 There is no explicit naming convention for nested Heat files with the
2040 following exceptions; the name should contain “nest”. As noted above,
2041 <text> represents any alphanumeric string that must not contain any
2042 special characters and must not contain the word “base”.
2046 Nested Heat files do not have corresponding environment files, per
2047 OpenStack specifications. All parameter values associated with the
2048 nested heat file must be passed in as properties in the resource
2049 definition defined in the parent heat template.
2051 ONAP Parameter Classifications Overview
2052 ---------------------------------------
2054 In order for ONAP to support workflow automation, Heat Orchestration
2055 Template resource property parameters must adhere to specific naming
2056 conventions and requirements.
2058 Broadly, ONAP categorizes parameters into four categories:
2060 1. ONAP metadata parameters
2062 2. Instance specific parameters
2064 3. Constant parameters
2066 4. Output parameters.
2068 ONAP Metadata Parameters
2069 ~~~~~~~~~~~~~~~~~~~~~~~~
2071 There are both mandatory and optional ONAP metadata parameters
2072 associated with the resource OS::Nova::Server.
2074 - ONAP metadata parameters must not have parameter constraints defined.
2076 - Both mandatory and optional (if specified) ONAP metadata parameter
2077 names must follow the ONAP metadata parameter naming convention.
2079 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
2081 Instance specific parameters
2082 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2084 The instance specific parameters are VNF instance specific. The value of
2085 the parameter will be different for every instance of a VNF (e.g., IP
2086 address). The instance specific parameters are subdivided into two
2087 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2090 ONAP Orchestration Parameters
2091 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2093 ONAP Orchestration Parameters are per instance parameters where the
2094 value is assigned via ONAP automation. (Note that in some cases,
2095 automation is currently not available and the value is loaded into ONAP
2096 prior to instantiation.)
2098 - ONAP orchestration parameters must not be enumerated in the
2101 - When the ONAP orchestration parameter type is set to number, the
2102 parameter must have constraints for range and/or allowed\_values.
2104 - Parameter constraints for ONAP orchestration parameters are optional
2105 for all parameter types other than number. If constraints are
2106 specified, they must adhere to the OpenStack specifications.
2108 - The ONAP orchestration parameter names must follow the ONAP
2109 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2112 VNF Orchestration Parameters
2113 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2115 VNF Orchestration Parameters are per instance parameters where the
2116 values are assigned manually. They are not supported by ONAP automation.
2117 The per instance values are loaded into ONAP prior to VNF instantiation.
2119 - VNF orchestration parameters must not be enumerated in the
2122 - When the VNF orchestration parameter type is set to number, the
2123 parameter must have constraints for range or allowed\_values.
2125 - Parameter constraints for VNF orchestration parameters are optional
2126 for all parameter types other than number. If constraints are
2127 specified, they must adhere to the OpenStack specifications.
2129 - The VNF orchestration parameter names should follow the VNF
2130 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2136 The constant parameters are parameters that remain constant across many
2137 VNF instances (e.g., image, flavor). The constant parameters are
2138 subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
2140 ONAP Constant Parameters
2141 ^^^^^^^^^^^^^^^^^^^^^^^^
2143 - ONAP Constant Parameters must be enumerated in the environment file.
2144 These parameter values are not assigned by ONAP.
2146 - When the ONAP Constant Parameter type is set to number, the parameter
2147 must have constraints for range and/or allowed\_values.
2149 - Parameter constraints for ONAP constant parameters are optional for
2150 all parameter types other than number. If constraints are specified,
2151 they must adhere to the OpenStack specifications.
2153 - The ONAP Constant Parameter names must follow the ONAP orchestration
2154 parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2156 VNF Constant Parameters
2157 ^^^^^^^^^^^^^^^^^^^^^^^
2159 - VNF Constant Parameters must be enumerated in the environment file.
2160 These parameter values are not assigned by ONAP.
2162 - When the VNF Constant Parameters type is set to number, the parameter
2163 must have constraints for range and/or allowed\_values.
2165 - Parameter constraints for ONAP constant parameters are optional for
2166 all parameter types other than number. If constraints are specified,
2167 they must adhere to the OpenStack specifications.
2169 - The VNF Constant Parameters names should follow the ONAP
2170 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2176 The output parameters are parameters defined in the output section of a
2177 Heat Orchestration Template. The ONAP output parameters are subdivided
2178 into three categories:
2180 1. ONAP Base Module Output Parameters
2182 2. ONAP Volume Module Output Parameters
2184 3. ONAP Predefined Output Parameters.
2186 ONAP Base Module Output Parameters
2187 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2189 ONAP Base Module Output Parameters are declared in the outputs: section
2190 of the base module Heat Orchestration Template. A Base Module Output
2191 Parameter is available as an input parameter (i.e., declared in the
2192 “parameters:” section) to all incremental modules in the VNF.
2194 - A Base Module Output Parameter may be used as an input parameter in
2195 an incremental module.
2197 - The Output parameter name and type must match the input parameter
2198 name and type unless the Output parameter is of the type
2199 comma\_delimited\_list.
2201 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2202 a collection of UUIDs from a Resource Group), then the
2203 corresponding input parameter must be declared as type json and
2204 not a comma\_delimited\_list, which is actually a string value
2205 with embedded commas.
2207 - When a Base Module Output Parameter is declared as an input parameter
2208 in an incremental module Heat Orchestration Template, parameter
2209 constraints must not be declared.
2211 Additional details on ONAP Base Module Output Parameters are provided in
2212 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2214 ONAP Volume Module Output Parameters
2215 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2217 The volume template output parameters are only available for the module
2218 (base or add on) that the volume is associated with.
2220 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2221 section of the Cinder volume module Heat Orchestration Template
2223 - An ONAP Volume Module Output Parameter is available as an input
2224 parameter (i.e., declared in the parameters: section) only for the
2225 module (base or incremental) that the Cinder volume module is
2226 associated with. The Output parameter name and type must match the
2227 input parameter name and type unless the Output parameter is of the
2228 type comma\_delimited\_list.
2230 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2231 collection of UUIDs from a Resource Group), then the corresponding
2232 input parameter must be declared as type json and not a
2233 comma\_delimited\_list, which is actually a string value with
2236 - When an ONAP Volume Module Output Parameter is declared as an input
2237 parameter in a base module or incremental module, parameter
2238 constraints must not be declared.
2240 Additional details on ONAP Base Module Output Parameters are provided in
2241 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2243 ONAP Predefined Output Parameters
2244 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2246 ONAP will look for a small set of pre-defined Heat output parameters to
2247 capture resource attributes for inventory in ONAP. These output
2248 parameters are optional and are specified in `OAM Management IP Addresses`_.
2250 Support of heat stack update
2251 ----------------------------
2253 VNF Heat Orchestration Templates must not be designed to utilize the
2254 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2255 does not support the use of heat stack-update command for scaling.
2257 It is important to note that ONAP only supports heat stack-update for
2263 ONAP defines two types of networks: External Networks and Internal
2266 ONAP defines an external network in relation to the VNF and not with
2267 regard to the Network Cloud site. External networks may also be referred
2268 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2270 - VMs in another VNF or
2272 - an external gateway or router
2274 ONAP defines an internal network in relation to the VNF and not with
2275 regard to the Network Cloud site. Internal networks may also be referred
2276 to as “intra-VNF” networks or “private” networks. An internal network
2277 only connects VMs in a single VNF. It must not connect to other VNFs or
2278 an external gateway or router.
2283 VNF Heat Orchestration Templates must not include any resources for
2284 external networks connected to the VNF. External networks must be
2285 orchestrated separately, as independent, stand-alone VNF Heat
2286 Orchestration Templates, so they can be shared by multiple VNFs and
2287 managed independently.
2289 When the external network is created, it must be assigned a unique
2290 {network-role}. The {network-role} should describe the network (e.g.,
2291 oam). The {network-role} while unique to the LCP, can repeat across
2294 An External Network may be a Neutron Network or a Contrail Network
2296 External networks must be passed into the VNF Heat Orchestration
2297 Templates as parameters.
2299 - Neutron Network-id (UUID)
2301 - Neutron Network subnet ID (UUID)
2303 - Contrail Network Fully Qualified Domain Name (FQDN)
2305 ONAP enforces a naming convention for parameters associated with
2306 external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2308 Parameter values associated with an external network will be generated
2309 and/or assigned by ONAP at orchestration time. Parameter values
2310 associated with an external network must not be enumerated in the
2311 environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2313 VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
2314 when attaching VMs to an external network
2316 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2318 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2321 - Note that Neutron Floating IPs must not be used. ONAP does not
2322 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2324 - ONAP supports the property allowed\_address\_pairs in the resource
2325 OS::Neutron:Port and the property
2326 virtual\_machine\_interface\_allowed\_address\_pairs in
2327 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2328 of a virtual IP (VIP) address to a set of VMs.
2330 VNF Heat Orchestration Templates must pass the appropriate external
2331 network IDs into nested VM templates when nested Heat is used.
2336 The VNF Heat Orchestration Templates must include the resource(s) to
2337 create the internal network. The internal network must be either a
2338 Neutron Network or a Contrail Network.
2340 In the modular approach, internal networks must be created in the Base
2341 Module, with their resource IDs exposed as outputs (i.e., ONAP Base
2342 Module Output Parameters) for use by all incremental modules. If the
2343 Network resource ID is required in the base template, then a
2344 get\_resource must be used.
2346 When the internal network is created, it should be assigned a unique
2347 {network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
2350 VNFs may use **Cloud assigned IP addresses** or
2351 **predetermined static IPs** when attaching VMs to an internal network.
2353 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2355 - A predetermined static IP address is enumerated in the Heat
2356 environment file. Since an internal network is local to the VNF, IP
2357 addresses can be re-used at every VNF instance.
2359 - Note that Neutron Floating IPs must not be used. ONAP does not
2360 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2362 - ONAP supports the property allowed\_address\_pairs in the resource
2363 OS::Neutron:Port and the property
2364 virtual\_machine\_interface\_allowed\_address\_pairs in
2365 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2366 of a virtual IP (VIP) address to a set of VMs.
2368 ONAP does not programmatically enforce a naming convention for
2369 parameters for internal network. However, a naming convention is
2370 provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2372 ONAP Resource ID and Parameter Naming Convention
2373 ------------------------------------------------
2375 This section provides the ONAP naming requirements for
2379 2. Resource Property Parameters
2384 The Heat Orchestration Templates for a VNF must assign a VNF unique
2385 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2386 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2387 it does not have to be globally unique across all VNFs that ONAP
2390 Any parameter that is associated with a unique Virtual Machine type in
2391 the VNF must include {vm-type} as part of the parameter name.
2393 Any resource ID that is associated with a unique Virtual Machine type in
2394 the VNF must include {vm-type} as part of the resource ID.
2396 Note that {vm-type} must not be a substring of {network-role}. A
2397 substring of a string is another string that occurs "in". For example,
2398 "oam" is a substring of "oam\_protected". It will cause the
2399 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2400 produce erroneous error messages.
2402 The {vm-type} should not contain the string “\_int” or “int\_” or
2403 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2404 ICE Project) process to produce erroneous error messages.
2406 The {vm-type} must be the same case in all parameter names in the VNF.
2408 The {vm-type} must be the same case in all Resource IDs in the VNF.
2410 It is recommended that the {vm-type} case in the parameter names matches
2411 the {vm-type} case in the Resource IDs.
2413 There are two exceptions to the above rules:
2415 1. The six ONAP Metadata parameters must not be prefixed with a common
2416 {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
2417 *vf\_module\_id*, *vf\_module\_name, vm\_role*. The ONAP Metadata
2418 parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
2420 2. The parameter referring to the OS::Nova::Server property
2421 availability\_zone must not be prefixed with a common {vm-type}
2422 identifier. availability\_zone is described in `Property: availability_zone`_.
2427 The assignment of a {network-role} is discussed in `Networking`_.
2429 Any parameter that is associated with an external network must include
2430 the {network-role} as part of the parameter name.
2432 Any resource ID that is associated with an external network must include
2433 the {network-role} as part of the resource ID.
2435 Any parameter that is associated with an internal network must include
2436 int\_{network-role} as part of the parameter name.
2438 Any resource ID that is associated with an internal network must include
2439 int\_{network-role} as part of the resource ID.
2441 Note that {network-role} must not be a substring of {vm-type}. A
2442 substring of a string is another string that occurs "in". For example,
2443 "oam" is a substring of "oam\_protected". It will cause the
2444 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2445 produce erroneous error messages.
2447 The {network-role} should not contain the string “\_int” or “int\_” or
2448 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2449 ICE Project) process to produce erroneous error messages.
2451 The {network-role} must be the same case in all parameter names in the
2454 The {network-role} must be the same case in all Resource IDs in the VNF.
2456 It is recommended that the {network-role} case in the parameter names
2457 matches the {network-role} case in the Resource IDs.
2462 Heat Orchestration Template resources are described in `resources`_
2464 A resource ID that must be unique within the resources section of a Heat
2465 Orchestration Template. This is an OpenStack Requirement.
2467 When a VNF is composed of more than one Heat Orchestration Template
2468 (i.e., modules), ONAP requires that the resource ID must be unique
2469 across all modules that compose the VNF.
2471 When a resource is associated with a single {vm-type}, the resource ID
2472 must contain {vm-type}.
2474 When a resource is associated with a single external network, the
2475 resource ID must contain {network-role}.
2477 When a resource is associated with a single internal network, the
2478 resource ID must contain int\_{network-role}.
2480 When a resource is associated with a single {vm-type} and a single
2481 external network, the resource ID must contain both the {vm-type} and
2484 - The {vm-type} must appear before the {network-role} and must be
2485 separated by an underscore (i.e., {vm-type}\_{network-role}).
2487 - Note that an {index} value may separate the {vm-type} and the
2488 {network-role}. An underscore will separate the three values (i.e.,
2489 {vm-type}\_{index}\_{network-role}).
2491 When a resource is associated with a single {vm-type} and a single
2492 internal network, the resource ID must contain both the {vm-type} and
2493 int\_{network-role}.
2495 - The {vm-type} must appear before the int\_{network-role} and must be
2496 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2498 - Note that an {index} value may separate the {vm-type} and the
2499 int\_{network-role}. An underscore will separate the three values
2500 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2502 When a resource is associated with more than one {vm-type} and/or more
2503 than one network, the resource ID
2505 - must not contain the {vm-type} and/or
2506 {network-role}/int\_{network-role}
2508 - should contain the term “shared” and/or contain text that identifies
2511 Only alphanumeric characters and “\_” underscores must be used in the
2512 resource ID. Special characters must not be used.
2514 All {index} values must be zero based. That is, the {index} must start
2515 at zero and increment by one.
2517 The table below provides example OpenStack Heat resource ID for
2518 resources only associated with one {vm-type} and/or one network.
2520 +--------------------------------+------------------------------------------------------------+
2521 | Resource Type | Resource ID Format |
2522 +================================+============================================================+
2523 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2524 +--------------------------------+------------------------------------------------------------+
2525 | OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
2526 +--------------------------------+------------------------------------------------------------+
2527 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2528 +--------------------------------+------------------------------------------------------------+
2529 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2530 +--------------------------------+------------------------------------------------------------+
2531 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2532 +--------------------------------+------------------------------------------------------------+
2533 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2534 +--------------------------------+------------------------------------------------------------+
2535 | OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
2536 +--------------------------------+------------------------------------------------------------+
2537 | | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
2538 +--------------------------------+------------------------------------------------------------+
2539 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2540 +--------------------------------+------------------------------------------------------------+
2541 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2542 +--------------------------------+------------------------------------------------------------+
2543 | OS::Nova::Server | {vm\_type}\_{index} |
2544 +--------------------------------+------------------------------------------------------------+
2545 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2546 +--------------------------------+------------------------------------------------------------+
2547 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2548 +--------------------------------+------------------------------------------------------------+
2550 Table 1: Example OpenStack Heat Resource ID
2552 The table below provides example Contrail Heat resource ID for resources
2553 only associated with one {vm-type} and/or one network.
2555 +-------------------------------------------+---------------------------------------------+
2556 | Resource Type | Resource ID Format |
2557 +===========================================+=============================================+
2558 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
2559 +-------------------------------------------+---------------------------------------------+
2560 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2561 +-------------------------------------------+---------------------------------------------+
2562 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2563 +-------------------------------------------+---------------------------------------------+
2564 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2565 +-------------------------------------------+---------------------------------------------+
2566 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2567 +-------------------------------------------+---------------------------------------------+
2568 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2569 +-------------------------------------------+---------------------------------------------+
2570 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2571 +-------------------------------------------+---------------------------------------------+
2572 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2573 +-------------------------------------------+---------------------------------------------+
2575 Table 2: Example Contrail Heat resource ID
2577 Resource: OS::Nova::Server - Parameters
2578 ---------------------------------------
2580 The resource OS::Nova::Server manages the running virtual machine (VM)
2581 instance within an OpenStack cloud. (See
2582 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2584 Four properties of this resource must follow the ONAP parameter naming
2585 convention. The four properties are:
2593 4. availability\_zone
2595 The table below provides a summary. The sections that follow provides
2598 Note that the {vm\_type} must be identical across all four property
2599 parameter for a given OS::Nova::Server resource.
2601 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2602 | Resource OS::Nova::Server |
2603 +=============================+===============================+==================+==============================+=================================+
2604 | Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
2605 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2606 | image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
2607 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2608 | flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
2609 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2610 | name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
2611 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2612 | | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
2613 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2614 | availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
2615 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2617 Table 3 Resource Property Parameter Names
2622 The parameter associated with the property image is an ONAP Constant
2625 The parameters must be named {vm-type}\_image\_name in the Heat
2626 Orchestration Template.
2628 The parameter must be declared as type: string
2630 The parameter must be enumerated in the Heat Orchestration Template
2633 Each VM type (i.e., {vm-type}) must have a separate parameter for image,
2634 even if more than one {vm-type} shares the same image. This provides
2635 maximum clarity and flexibility.
2637 *Example Parameter Definition*
2639 .. code-block:: yaml
2642 {vm-type}_image_name:
2644 description: {vm-type} server image
2649 The parameter associated with the property flavor is an ONAP Constant
2652 The parameters must be named {vm-type}\_flavor\_name in the Heat
2653 Orchestration Template.
2655 The parameter must be declared as type: string
2657 The parameter must be enumerated in the Heat Orchestration Template
2660 Each VM type (i.e., {vm-type}) must have a separate parameter for
2661 flavors, even if more than one {vm-type} shares the same flavor. This
2662 provides maximum clarity and flexibility.
2664 *Example Parameter Definition*
2666 .. code-block:: yaml
2669 {vm-type}_flavor_name:
2671 description: {vm-type} flavor
2676 The parameter associated with the property name is an ONAP Orchestration
2679 The parameter value is provided to the Heat template by ONAP. The
2680 parameter must not be enumerated in the environment file.
2682 The parameter must be declared as type: string or type:
2683 comma\_delimited\_list
2685 If the parameter is declared as type:string, the parameter must be named
2686 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2687 at zero and increments by one.
2689 If the parameter is declared as type:comma\_delimited\_list, the
2690 parameter must be named as {vm-type}\_names
2692 Each element in the VM Name list should be assigned to successive
2693 instances of that VM type.
2695 If a VNF contains more than three instances of a given {vm-type}, the
2696 comma\_delimited\_list form of the parameter name (i.e.,
2697 {vm-type}\_names) should be used to minimize the number of unique
2698 parameters defined in the Heat.
2700 *Example: Parameter Definition*
2702 .. code-block:: yaml
2706 type: comma_delimited_list
2707 description: VM Names for {vm-type} VMs
2708 {vm-type}_name_{index}:
2710 description: VM Name for {vm-type} VM {index}
2712 *Example: comma\_delimited\_list*
2714 In this example, the {vm-type} has been defined as “lb” for load
2717 .. code-block:: yaml
2721 type: comma_delimited_list
2722 description: VM Names for lb VMs
2726 type: OS::Nova::Server
2728 name: { get_param: [lb_names, 0] }
2732 type: OS::Nova::Server
2734 name: { get_param: [lb_names, 1] }
2737 *Example: fixed-index*
2739 In this example, the {vm-type} has been defined as “lb” for load
2742 .. code-block:: yaml
2747 description: VM Name for lb VM 0
2751 description: VM Name for lb VM 1
2755 type: OS::Nova::Server
2757 name: { get_param: lb_name_0 }
2761 type: OS::Nova::Server
2763 name: { get_param: lb_name_1 }
2766 Contrail Issue with Values for OS::Nova::Server Property Name
2767 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2769 The Contrail GUI has a limitation displaying special characters. The
2770 issue is documented in
2771 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2772 recommended that special characters be avoided. However, if special
2773 characters must be used, the only special characters supported are:
2775 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2777 Property: availability\_zone
2778 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2780 The parameter associated with the property availability\_zone is an ONAP
2781 Orchestration parameter.
2783 The parameter value is provided to the Heat template by ONAP. The
2784 parameter must not be enumerated in the environment file.
2786 The parameter must be named availability\_zone\_{index} in the Heat
2787 Orchestration Template. The {index} must start at zero. The {index} must
2788 increment by one. The parameter name must not include the {vm-type}.
2790 The parameter must be declared as type: string
2792 The parameter must not be declared as type: comma\_delimited\_list
2797 The example below depicts part of a Heat Orchestration Template that
2798 uses the four OS::Nova::Server properties discussed in this section.
2800 In the Heat Orchestration Template below, four Virtual Machines
2801 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2802 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2803 parameter associated with the property name is a comma\_delimited\_list
2804 for dns and a string for oam.
2806 .. code-block:: yaml
2811 description: dns server image
2814 description: dns server flavor
2816 type: comma_delimited_list
2817 description: dns server names
2820 description: oam server image
2823 description: oam server flavor
2826 description: oam server name 0
2829 description: oam server name 1
2830 availability_zone_0:
2832 description: availability zone ID or Name
2833 availability_zone_1:
2835 description: availability zone ID or Name
2839 type: OS::Nova::Server
2841 name: { get_param: [ dns_names, 0 ] }
2842 image: { get_param: dns_image_name }
2843 flavor: { get_param: dns_flavor_name }
2844 availability_zone: { get_param: availability_zone_0 }
2848 type: OS::Nova::Server
2850 name: { get_param: [ dns_names, 1 ] }
2851 image: { get_param: dns_image_name }
2852 flavor: { get_param: dns_flavor_name }
2853 availability_zone: { get_param: availability_zone_1 }
2857 type: OS::Nova::Server
2859 name: { get_param: oam_name_0 }
2860 image: { get_param: oam_image_name }
2861 flavor: { get_param: oam_flavor_name }
2862 availability_zone: { get_param: availability_zone_0 }
2866 type: OS::Nova::Server
2868 name: { get_param: oam_name_1 }
2869 image: { get_param: oam_image_name }
2870 flavor: { get_param: oam_flavor_name }
2871 availability_zone: { get_param: availability_zone_1 }
2874 Resource: OS::Nova::Server – Metadata Parameters
2875 ------------------------------------------------
2877 The resource OS::Nova::Server has an OpenStack optional property
2878 metadata. The metadata property is mandatory for ONAP Heat Orchestration
2879 Templates; it must be included.
2881 ONAP requires the following three mandatory metadata parameters for an
2882 OS::Nova::Server resource:
2890 ONAP allows the following three optional metadata parameters for an
2891 OS::Nova::Server resource. They may be included
2897 Note that the metadata parameters do not and must not contain {vm-type}
2900 When Metadata parameters are past into a nested heat template, the
2901 parameter names must not change.
2903 The table below provides a summary. The sections that follow provides
2906 +---------------------------+------------------+----------------------+------------------------------+
2907 | Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
2908 +===========================+==================+======================+==============================+
2909 | vnf\_id | string | Mandatory | ONAP |
2910 +---------------------------+------------------+----------------------+------------------------------+
2911 | vf\_module\_id | string | Mandatory | ONAP |
2912 +---------------------------+------------------+----------------------+------------------------------+
2913 | vnf\_name | string | Mandatory | ONAP |
2914 +---------------------------+------------------+----------------------+------------------------------+
2915 | vf\_module\_name | string | Optional | ONAP |
2916 +---------------------------+------------------+----------------------+------------------------------+
2917 | vm\_role | string | Optional | YAML or Environment File |
2918 +---------------------------+------------------+----------------------+------------------------------+
2919 +---------------------------+------------------+----------------------+------------------------------+
2921 Table 4: ONAP Metadata
2926 The vnf\_id parameter is mandatory; it must be included in the Heat
2927 Orchestration Template.
2929 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
2930 UUID that is the vnf\_id and supplies it to the Heat Orchestration
2931 Template at orchestration time.
2933 The parameter must be declared as type: string
2935 Parameter constraints must not be defined.
2937 The parameter must not be enumerated in the Heat environment file.
2939 *Example Parameter Definition*
2941 .. code-block:: yaml
2946 description: Unique ID for this VNF instance
2951 The vf\_module\_id parameter is mandatory; it must be included in the
2952 Heat Orchestration Template.
2954 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
2955 generates the UUID that is the vf\_module\_id and supplies it to the
2956 Heat Orchestration Template at orchestration time.
2958 The parameter must be declared as type: string
2960 Parameter constraints must not be defined.
2962 The parameter must not be enumerated in the Heat environment file.
2964 *Example Parameter Definition*
2966 .. code-block:: yaml
2971 description: Unique ID for this VNF module instance
2976 The vnf\_name parameter is mandatory; it must be included in the Heat
2977 Orchestration Template.
2979 The vnf\_name parameter value will be generated and/or assigned by ONAP
2980 and supplied to the Heat Orchestration Template by ONAP at orchestration
2983 The parameter must be declared as type: string
2985 Parameter constraints must not be defined.
2987 The parameter must not be enumerated in the Heat environment file.
2989 *Example Parameter Definition*
2991 .. code-block:: yaml
2996 description: Unique name for this VNF instance
3001 The vf\_module\_name parameter is optional; it may be included in the
3002 Heat Orchestration Template.
3004 The vf\_module\_name parameter is the name of the name of the Heat stack
3005 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3006 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3007 needs to be specified as part of the orchestration process.
3009 The parameter must be declared as type: string
3011 Parameter constraints must not be defined.
3013 The parameter must not be enumerated in the Heat environment file.
3015 *Example Parameter Definition*
3017 .. code-block:: yaml
3022 description: Unique name for this VNF Module instance
3027 The vm\_role parameter is optional; it may be included in the Heat
3028 Orchestration Template.
3030 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3031 system and available for use by other ONAP components and/or north bound
3034 The vm\_role values must be either
3036 - hard-coded into the Heat Orchestration Template or
3038 - enumerated in the environment file.
3040 Defining the vm\_role as the {vm-type} is a recommended convention
3042 The parameter must be declared as type: string
3044 Parameter constraints must not be defined.
3046 *Example Parameter Definition*
3048 .. code-block:: yaml
3053 description: Unique role for this VM
3055 *Example Resource Definition: Hard Coded*
3057 In this example, the {vm-role} is hard coded in the Heat Orchestration
3060 .. code-block:: yaml
3064 type: OS::Nova::Server
3070 *Example Resource Definition: get\_param*
3072 In this example, the {vm-role} is enumerated in the environment file.
3074 .. code-block:: yaml
3078 type: OS::Nova::Server
3082 vm_role: { get_param: vm_role }
3087 The example below depicts part of a Heat Orchestration Template that
3088 uses the five of the OS::Nova::Server metadata parameter discussed in
3089 this section. The {vm-type} has been defined as lb for load balancer.
3091 .. code-block:: yaml
3096 description: VM Name for lb VM 0
3099 description: Unique name for this VNF instance
3102 description: Unique ID for this VNF instance
3105 description: Unique name for this VNF Module instance
3108 description: Unique ID for this VNF Module instance
3111 description: Unique role for this VM
3116 type: OS::Nova::Server
3118 name: { get_param: lb_name_0 }
3121 vnf_name: { get_param: vnf_name }
3122 vnf_id: { get_param: vnf_id }
3123 vf_module_name: { get_param: vf_module_name }
3124 vf_module_id: { get_param: vf_module_id }
3127 Resource: OS::Neutron::Port - Parameters
3128 ----------------------------------------
3130 The resource OS::Neutron::Port is for managing Neutron ports (See
3131 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3136 Four properties of the resource OS::Neutron::Port that must follow the
3137 ONAP parameter naming convention. The four properties are:
3141 2. fixed\_ips, ip\_address
3143 3. fixed\_ips, subnet\_id
3145 4. allowed\_address\_pairs, ip\_address
3147 The parameters associated with these properties may reference an
3148 external network or internal network. External networks and internal
3149 networks are defined in `Networking`_.
3154 When the parameter references an external network
3156 - the parameter name must contain {network-role}
3158 - the parameter must not be enumerated in the Heat environment file
3160 - the parameter is classified as an ONAP Orchestration Parameter
3162 +----------------------------------------+-----------------------------------------------+--------------------------+
3163 | Property Name | ONAP Parameter Name | Parameter Type |
3164 +========================================+===============================================+==========================+
3165 | network | {network-role}\_net\_id | string |
3166 +----------------------------------------+-----------------------------------------------+--------------------------+
3167 | | {network-role}\_net\_name | string |
3168 +----------------------------------------+-----------------------------------------------+--------------------------+
3169 | fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
3170 +----------------------------------------+-----------------------------------------------+--------------------------+
3171 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3172 +----------------------------------------+-----------------------------------------------+--------------------------+
3173 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3174 +----------------------------------------+-----------------------------------------------+--------------------------+
3175 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3176 +----------------------------------------+-----------------------------------------------+--------------------------+
3177 | fixed\_ips, subnet | {network-role}\_subnet\_id | string |
3178 +----------------------------------------+-----------------------------------------------+--------------------------+
3179 | | {network-role}\_v6\_subnet\_id | string |
3180 +----------------------------------------+-----------------------------------------------+--------------------------+
3181 | allowed\_address\_pairs, ip\_address | {vm-type}\_{network-role}\_floating\_ip | string |
3182 +----------------------------------------+-----------------------------------------------+--------------------------+
3183 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
3184 +----------------------------------------+-----------------------------------------------+--------------------------+
3185 | | {vm-type}\_{network-role}\_ip\_{index} | string |
3186 +----------------------------------------+-----------------------------------------------+--------------------------+
3187 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3188 +----------------------------------------+-----------------------------------------------+--------------------------+
3189 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3190 +----------------------------------------+-----------------------------------------------+--------------------------+
3191 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3192 +----------------------------------------+-----------------------------------------------+--------------------------+
3194 Table 5: OS::Neutron::Port Resource Property Parameters (External
3200 When the parameter references an internal network
3202 - the parameter name must contain int\_{network-role}
3204 - the parameter may be enumerated in the environment file.
3206 +----------------------------------------+----------------------------------------------------+--------------------------+
3207 | Property | Parameter Name for Internal Networks | Parameter Type |
3208 +========================================+====================================================+==========================+
3209 | network | int\_{network-role}\_net\_id | string |
3210 +----------------------------------------+----------------------------------------------------+--------------------------+
3211 | | int\_{network-role}\_net\_name | string |
3212 +----------------------------------------+----------------------------------------------------+--------------------------+
3213 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3214 +----------------------------------------+----------------------------------------------------+--------------------------+
3215 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3216 +----------------------------------------+----------------------------------------------------+--------------------------+
3217 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3218 +----------------------------------------+----------------------------------------------------+--------------------------+
3219 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3220 +----------------------------------------+----------------------------------------------------+--------------------------+
3221 | fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
3222 +----------------------------------------+----------------------------------------------------+--------------------------+
3223 | | int\_{network-role}\_v6\_subnet\_id | string |
3224 +----------------------------------------+----------------------------------------------------+--------------------------+
3225 | allowed\_address\_pairs, ip\_address | {vm-type}\_int\_{network-role}\_floating\_ip | string |
3226 +----------------------------------------+----------------------------------------------------+--------------------------+
3227 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
3228 +----------------------------------------+----------------------------------------------------+--------------------------+
3229 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3230 +----------------------------------------+----------------------------------------------------+--------------------------+
3231 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3232 +----------------------------------------+----------------------------------------------------+--------------------------+
3233 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3234 +----------------------------------------+----------------------------------------------------+--------------------------+
3235 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3236 +----------------------------------------+----------------------------------------------------+--------------------------+
3238 Table 6: Port Resource Property Parameters (Internal Networks)
3243 The property networks in the resource OS::Neutron::Port must be
3244 referenced by Neutron Network ID, a UUID value, or by the network name
3245 defined in OpenStack.
3250 When the parameter associated with the property network is referencing
3251 an “external” network, the parameter must adhere to the following naming
3252 convention in the Heat Orchestration Template
3254 - {network-role}\_net\_id for the Neutron network ID
3256 - {network-role}\_net\_name for the network name in OpenStack
3258 The parameter must be declared as type: string
3260 The parameter must not be enumerated in the Heat environment file.
3262 *Example Parameter Definition*
3264 .. code-block:: yaml
3267 {network-role}_net_id:
3269 description: Neutron UUID for the {network-role} network
3270 {network-role}_net_name:
3272 description: Neutron name for the {network-role} network
3274 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3275 that has only one subnet*
3277 In this example, the {network-role} has been defined as oam to represent
3278 an oam network and the {vm-type} has been defined as lb for load
3279 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3280 to assign IP addresses.
3282 .. code-block:: yaml
3287 description: Neutron UUID for the oam network
3291 type: OS::Neutron::Port
3292 network: { get_param: oam_net_id }
3297 When the parameter associated with the property network is referencing
3298 an “internal” network, the parameter must adhere to the following naming
3301 - int\_{network-role}\_net\_id for the Neutron network ID
3303 - int\_{network-role}\_net\_name for the network name in OpenStack
3305 The parameter must be declared as type: string
3307 The assumption is that internal networks are created in the base module.
3308 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3309 Base Module Output Parameter) to the incremental modules. In the
3310 incremental modules, it will be defined as input parameter.
3312 *Example Parameter Definition*
3314 .. code-block:: yaml
3317 int_{network-role}_net_id:
3319 description: Neutron UUID for the {network-role} network
3320 int_{network-role}_net_name:
3322 description: Neutron name for the {network-role} network
3324 Property: fixed\_ips, Map Property: subnet\_id
3325 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3327 The property fixed\_ips is used to assign IPs to a port. The Map
3328 Property subnet\_id specifies the subnet the IP is assigned from.
3330 The property fixed\_ips and Map Property subnet\_id must be used if a
3331 Cloud (i.e., DHCP) IP address assignment is being requested and the
3332 Cloud IP address assignment is targeted at a specific subnet when two or
3335 The property fixed\_ips and Map Property subnet\_id should not be used
3336 if all IP assignments are fixed, or if the Cloud IP address assignment
3337 does not target a specific subnet or there is only one subnet.
3339 Note that DHCP assignment of IP addresses is also referred to as cloud
3340 assigned IP addresses.
3342 Subnet of an External Networks
3343 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3345 When the parameter is referencing a subnet of an “external” network, the
3346 property fixed\_ips and Map Property subnet\_id parameter must adhere to
3347 the following naming convention.
3349 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3351 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3353 The parameter must be declared as type: string
3355 The parameter must not be enumerated in the Heat environment file.
3357 *Example Parameter Definition*
3359 .. code-block:: yaml
3362 {network-role}_subnet_id:
3364 description: Neutron subnet UUID for the {network-role} network
3366 {network-role}_v6_subnet_id:
3368 description: Neutron subnet UUID for the {network-role} network
3370 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3371 that has two or more subnets subnet:*
3373 In this example, the {network-role} has been defined as oam to represent
3374 an oam network and the {vm-type} has been defined as lb for load
3375 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3376 to assign IP addresses.
3378 .. code-block:: yaml
3383 description: Neutron UUID for the oam network
3387 description: Neutron subnet UUID for the oam network
3391 type: OS::Neutron::Port
3392 network: { get_param: oam_net_id }
3394 - subnet_id: { get_param: oam_subnet_id }
3396 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3397 address assigned to a network that has at least one IPv4 subnet and one
3400 In this example, the {network-role} has been defined as oam to represent
3401 an oam network and the {vm-type} has been defined as lb for load
3404 .. code-block:: yaml
3409 description: Neutron UUID for the oam network
3413 description: Neutron subnet UUID for the oam network
3417 description: Neutron subnet UUID for the oam network
3421 type: OS::Neutron::Port
3423 network: { get_param: oam_net_id }
3425 - subnet_id: { get_param: oam_subnet_id }
3426 - subnet_id: { get_param: oam_v6_subnet_id }
3431 When the parameter is referencing the subnet of an “internal” network,
3432 the property fixed\_ips and Map Property subnet\_id parameter must
3433 adhere to the following naming convention.
3435 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3437 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3439 The parameter must be declared as type: string
3441 The assumption is that internal networks are created in the base module.
3442 The Neutron subnet network ID will be passed as an output parameter
3443 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3444 the incremental modules, it will be defined as input parameter.
3446 *Example Parameter Definition*
3448 .. code-block:: yaml
3451 int_{network-role}_subnet_id:
3453 description: Neutron subnet UUID for the {network-role} network
3455 int_{network-role}_v6_subnet_id:
3457 description: Neutron subnet UUID for the {network-role} network
3459 Property: fixed\_ips, Map Property: ip\_address
3460 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3462 The property fixed\_ips is used to assign IPs to a port. The Map
3463 Property ip\_address specifies the IP address to be assigned to the
3466 The property fixed\_ips and Map Property ip\_address must be used when
3467 statically assigning one or more IP addresses to a port. This is also
3468 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3469 the IP address assignment.
3471 An IP address is assigned to a port on a VM (referenced by {vm-type})
3472 that is connected to an external network (referenced by {network-role})
3473 or internal network (referenced by int\_{network-role}).
3475 When a SDN-C IP assignment is made to a port connected to an external
3476 network, the parameter name must contain {vm-type} and {network-role}.
3478 When a SDN-C IP assignment is made to a port connected to an internal
3479 network, the parameter name must contain {vm-type} and
3480 int\_{network-role}.
3482 IP Address Assignments on External Networks
3483 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3485 When the property fixed\_ips and Map Property ip\_address is used to
3486 assign IP addresses to an external network, the parameter name is
3487 dependent on the parameter type (comma\_delimited\_list or string) and
3488 IP address type (IPv4 or IPv6).
3490 When the parameter for property fixed\_ips and Map Property ip\_address
3491 is declared type: comma\_delimited\_list, the parameter must adhere to
3492 the following naming convention
3494 - {vm-type}\_{network-role}\_ips for IPv4 address
3496 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3498 Each element in the IP list should be assigned to successive instances
3499 of {vm-type} on {network-role}.
3501 The parameter must not be enumerated in the Heat environment file.
3503 *Example Parameter Definition*
3505 .. code-block:: yaml
3509 {vm-type}_{network-role}_ips:
3510 type: comma_delimited_list
3511 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3513 {vm-type}_{network-role}_v6_ips:
3514 type: comma_delimited_list
3515 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3517 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3518 Assignments to an external network*
3520 In this example, the {network-role} has been defined as oam to represent
3521 an oam network and the {vm-type} has been defined as db for database.
3523 .. code-block:: yaml
3528 description: Neutron UUID for a oam network
3531 type: comma_delimited_list
3532 description: Fixed IPv4 assignments for db VMs on the oam network
3535 type: comma_delimited_list
3536 description: Fixed IPv6 assignments for db VMs on the oam network
3540 type: OS::Neutron::Port
3541 network: { get_param: oam_net_id }
3542 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3545 type: OS::Neutron::Port
3547 network: { get_param: oam_net_id }
3549 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3550 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3552 When the parameter for property fixed\_ips and Map Property ip\_address
3553 is declared type: string, the parameter must adhere to the following
3556 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3558 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3560 The value for {index} must start at zero (0) and increment by one.
3562 The parameter must not be enumerated in the Heat environment file.
3564 *Example Parameter Definition*
3566 .. code-block:: yaml
3569 {vm-type}_{network-role}_ip_{index}:
3571 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3573 {vm-type}_{network-role}_v6_ip_{index}:
3575 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3577 *Example: string parameters for IPv4 and IPv6 Address Assignments to an external network*
3579 In this example, the {network-role} has been defined as “oam” to
3580 represent an oam network and the {vm-type} has been defined as “db” for
3583 .. code-block:: yaml
3588 description: Neutron UUID for an OAM network
3592 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3596 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3600 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3604 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3608 type: OS::Neutron::Port
3610 network: { get_param: oam_net_id }
3611 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3614 type: OS::Neutron::Port
3616 network: { get_param: oam_net_id }
3618 - “ip_address”: {get_param: db_oam_ip_1}}]
3619 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3621 IP Address Assignment on Internal Networks
3622 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3624 When the property fixed\_ips and Map Property ip\_address is used to
3625 assign IP addresses to an internal network, the parameter name is
3626 dependent on the parameter type (comma\_delimited\_list or string) and
3627 IP address type (IPv4 or IPv6).
3629 When the parameter for property fixed\_ips and Map Property ip\_address
3630 is declared type: comma\_delimited\_list, the parameter must adhere to
3631 the following naming convention
3633 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3635 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3637 Each element in the IP list should be assigned to successive instances
3638 of {vm-type} on {network-role}.
3640 The parameter must be enumerated in the Heat environment file. Since an
3641 internal network is local to the VNF, IP addresses can be re-used at
3644 *Example Parameter Definition*
3646 .. code-block:: yaml
3650 {vm-type}_int_{network-role}_ips:
3651 type: comma_delimited_list
3652 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3654 {vm-type}_int_{network-role}_v6_ips:
3655 type: comma_delimited_list
3656 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3658 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3659 Assignments to an internal network*
3661 In this example, the {network-role} has been defined as oam\_int to
3662 represent an oam network internal to the vnf. The role oam\_int was
3663 picked to differentiate from an external oam network with a
3664 {network-role} of oam. The {vm-type} has been defined as db for
3667 .. code-block:: yaml
3672 description: Neutron UUID for the oam internal network
3675 type: comma_delimited_list
3676 description: Fixed IPv4 assignments for db VMs on the oam internal network
3678 db_int_oam_int_v6_ips:
3679 type: comma_delimited_list
3680 description: Fixed IPv6 assignments for db VMs on the oam internal network
3684 type: OS::Neutron::Port
3686 network: { get_param: int_oam_int_net_id }
3687 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3690 type: OS::Neutron::Port
3692 network: { get_param: int_oam_int_net_id }
3694 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3695 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3697 When the parameter for property fixed\_ips and Map Property ip\_address
3698 is declared type: string, the parameter must adhere to the following
3701 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3703 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3705 The value for {index} must start at zero (0) and increment by one.
3707 The parameter must be enumerated in the Heat environment file. Since an
3708 internal network is local to the VNF, IP addresses can be re-used at
3711 *Example Parameter Definition*
3713 .. code-block:: yaml
3717 {vm-type}_int_{network-role}_ip_{index}:
3719 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3721 {vm-type}_int_{network-role}_v6_ip_{index}:
3723 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3725 *Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
3727 In this example, the {network-role} has been defined as oam\_int to
3728 represent an oam network internal to the vnf. The role oam\_int was
3729 picked to differentiate from an external oam network with a
3730 {network-role} of oam. The {vm-type} has been defined as db for
3733 .. code-block:: yaml
3738 description: Neutron UUID for an OAM internal network
3742 description: Fixed IPv4 assignment for db VM on the oam_int network
3746 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3750 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3754 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3758 type: OS::Neutron::Port
3760 network: { get_param: int_oam_int_net_id }
3761 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3764 type: OS::Neutron::Port
3766 network: { get_param: int_oam_int_net_id }
3768 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3769 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3771 Property: allowed\_address\_pairs, Map Property: ip\_address
3772 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3774 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3775 allows the user to specify a mac\_address and/or ip\_address that will
3776 pass through a port regardless of subnet. This enables the use of
3777 protocols such as VRRP, which floats an IP address between two instances
3778 to enable fast data plane failover. The map property ip\_address
3779 specifies the IP address.
3781 The allowed\_address\_pairs is an optional property. It is not required.
3783 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3784 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3785 and {network-role}/int\_{network-role} combination.
3787 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3788 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3789 and {network-role}/int\_{network-role} combination.
3791 Note that the management of these IP addresses (i.e. transferring
3792 ownership between active and standby VMs) is the responsibility of the
3795 Note that these parameters are **not** intended to represent Neutron
3796 “Floating IP” resources, for which OpenStack manages a pool of public IP
3797 addresses that are mapped to specific VM ports. In that case, the
3798 individual VMs are not even aware of the public IPs, and all assignment
3799 of public IPs to VMs is via OpenStack commands. ONAP does not support
3800 Neutron-style Floating IPs.
3805 When the parameter is referencing an “external” network, the property
3806 allowed\_address\_pairs and Map Property ip\_address parameter must
3807 adhere to the following naming convention.
3809 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3811 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3813 The parameter must be declared as type: string
3815 The parameter must not be enumerated in the Heat environment file.
3817 *Example Parameter Definition*
3819 .. code-block:: yaml
3823 {vm-type}_{network-role}_floating_ip:
3825 description: VIP for {vm-type} VMs on the {network-role} network
3827 {vm-type}_{network-role}_floating_v6_ip:
3829 description: VIP for {vm-type} VMs on the {network-role} network
3833 In this example, the {network-role} has been defined as oam to represent
3834 an oam network and the {vm-type} has been defined as db for database.
3836 .. code-block:: yaml
3841 description: Neutron UUID for the oam network
3844 type: comma_delimited_list
3845 description: Fixed IPs for db VMs on the oam network
3849 description: VIP IP for db VMs on the oam network
3853 type: OS::Neutron::Port
3855 network: { get_param: oam_net_id }
3856 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
3857 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3860 type: OS::Neutron::Port
3862 network: { get_param: oam_net_id }
3863 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
3864 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3869 When the parameter is referencing an “internal” network, the property
3870 allowed\_address\_pairs and Map Property ip\_address parameter must
3871 adhere to the following naming convention.
3873 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
3875 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
3877 The parameter must be declared as type: string
3879 The parameter must be enumerated in the Heat environment file.
3881 *Example Parameter Definition*
3883 .. code-block:: yaml
3887 {vm-type}_int_{network-role}_floating_ip:
3889 description: VIP for {vm-type} VMs on the int_{network-role} network
3891 {vm-type}_int_{network-role}_floating_v6_ip:
3893 description: VIP for {vm-type} VMs on the int_{network-role} network
3895 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
3896 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3898 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
3899 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
3901 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
3902 one allowed address pair IPv6 address per {vm-type} and {network-role}
3905 If there is a need for multiple allowed address pair IPs for a given
3906 {vm-type} and {network-role} combination within a VNF, then the
3907 parameter names defined for the property fixed\_ips and Map Property
3908 ip\_address should be used with the allowed\_address\_pairs property.
3909 The examples below illustrate this.
3911 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
3913 In this example, there are two administrative VM pairs. Each pair has
3914 one VIP. The {network-role} has been defined as oam to represent an oam
3915 network and the {vm-type} has been defined as admin for an
3918 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
3919 VIP, [admin\_oam\_ips,2]
3921 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
3922 VIP, [admin\_oam\_ips,5]
3924 .. code-block:: yaml
3929 description: Neutron UUID for the oam network
3931 type: comma_delimited_list
3932 description: Fixed IP assignments for admin VMs on the oam network
3937 type: OS::Neutron::Port
3939 network: { get_param: oam_net_id }
3940 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
3941 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3944 type: OS::Neutron::Port
3946 network: { get_param: oam_net_id }
3947 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
3948 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3951 type: OS::Neutron::Port
3953 network: { get_param: oam_net_id }
3954 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
3955 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3958 type: OS::Neutron::Port
3960 network: { get_param: oam_net_id }
3961 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
3962 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3964 *Example: A VNF has two load balancers. The pair of load balancers share
3967 In this example, there is one load balancer pairs. The pair has two
3968 VIPs. The {network-role} has been defined as oam to represent an oam
3969 network and the {vm-type} has been defined as lb for a load balancer VM.
3971 .. code-block:: yaml
3975 type: OS::Neutron::Port
3977 network: { get_param: oam_net_id }
3978 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
3979 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3982 type: OS::Neutron::Port
3984 network: { get_param: oam_net_id }
3985 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
3986 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3988 As a general rule, provide the fixed IPs for the VMs indexed first in
3989 the CDL and then the VIPs as shown in the examples above.
3991 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
3992 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3994 The following items must be taken into consideration when designing Heat
3995 Orchestration Templates that expect ONAP’s SDN-C to assign
3996 allowed\_address\_pair IP addresses via automation.
3998 The VMs must be of the same {vm-type}.
4000 The VMs must be created in the same module (base or incremental).
4002 Resource Property “name”
4003 ------------------------
4005 The parameter naming convention of the property name for the resource
4006 OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
4008 This section provides the requirements how the property name for non
4009 OS::Nova::Server resources must be defined when the property is used.
4010 Not all resources require the property name (e.g., it is optional) and
4011 some resources do not support the property.
4013 When the property name for a non OS::Nova::Server resources is defined
4014 in a Heat Orchestration Template, the intrinsic function str\_replace
4015 must be used in conjunction with the ONAP supplied metadata parameter
4016 vnf\_name to generate a unique value. This prevents the enumeration of a
4017 unique value for the property name in a per instance environment file.
4021 - In most cases, only the use of the metadata value vnf\_name is
4022 required to create a unique property name
4024 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4025 may also be used in the str\_replace construct to generate a unique
4026 name when the vnf\_name does not provide uniqueness
4028 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4030 .. code-block:: yaml
4034 type: OS::Neutron::SecurityGroup
4036 description: vDNS security group
4039 template: VNF_NAME_sec_grp_DNS
4041 VNF_NAME: {get_param: vnf_name}
4045 *Example: Property name for resource* OS::Cinder::Volume
4047 .. code-block:: yaml
4051 type: OS::Cinder::Volume
4053 description: Cinder Volume
4056 template: VNF_NAME_STACK_NAME_dns_volume
4058 VNF_NAME: {get_param: vnf_name}
4059 STACK_NAME: { get_param: 'OS::stack_name' }
4062 Contrail Issue with Values for the Property Name
4063 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4065 The Contrail GUI has a limitation displaying special characters. The
4066 issue is documented in
4067 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4068 recommended that special characters be avoided. However, if special
4069 characters must be used, note that for the following resources:
4083 the only special characters supported are:
4085 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4087 ONAP Output Parameter Names
4088 ---------------------------
4090 ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
4092 ONAP Base Module Output Parameters:
4093 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4095 ONAP Base Module Output Parameters do not have an explicit naming
4096 convention. The parameter name must contain {vm-type} and {network-role}
4099 ONAP Volume Template Output Parameters:
4100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4102 ONAP Base Module Output Parameters do not have an explicit naming
4103 convention. The parameter name must contain {vm-type} when appropriate.
4105 Predefined Output Parameters
4106 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4108 ONAP currently defines one predefined output parameter the OAM
4109 Management IP Addresses.
4111 OAM Management IP Addresses
4112 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
4114 A VNF may have a management interface for application controllers to
4115 interact with and configure the VNF. Typically, this will be via a
4116 specific VM that performs a VNF administration function. The IP address
4117 of this interface must be captured and inventoried by ONAP. The IP
4118 address might be a VIP if the VNF contains an HA pair of management VMs,
4119 or may be a single IP address assigned to one VM.
4121 The Heat template may define either (or both) of the following Output
4122 parameters to identify the management IP address.
4124 - oam\_management\_v4\_address
4126 - oam\_management\_v6\_address
4130 - The use of this output parameters are optional.
4132 - The Management IP Address should be defined only once per VNF, so it
4133 must only appear in one Module template
4135 - If a fixed IP for the admin VM is passed as an input parameter, it
4136 may be echoed in the output parameters. In this case, a IPv4 and/or
4137 IPv6 parameter must be defined in the parameter section of the YAML
4138 Heat template. The parameter maybe named oam\_management\_v4\_address
4139 and/or oam\_management\_v6\_address or may be named differently.
4141 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4142 from the resource attributes. In this case,
4143 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4144 not be defined in the parameter section of the YAML Heat template.
4146 *Example: SDN-C Assigned IP Address echoed as*
4147 oam\_management\_v4\_address
4149 .. code-block:: yaml
4154 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4158 admin_oam_net_0_port:
4159 type: OS::Neutron::Port
4163 template: VNF_NAME_admin_oam_net_0_port
4165 VNF_NAME: {get_param: vnf_name}
4166 network: { get_param: oam_net_id }
4167 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4168 security_groups: [{ get_param: security_group }]
4171 type: OS::Nova::Server
4173 name: { get_param: admin_names }
4174 image: { get_param: admin_image_name }
4175 flavor: { get_param: admin_flavor_name }
4176 availability_zone: { get_param: availability_zone_0 }
4178 - port: { get_resource: admin_oam_net_0_port }
4180 vnf_id: { get_param: vnf_id }
4181 vf_module_id: { get_param: vf_module_id }
4182 vnf_name: {get_param: vnf_name }
4184 oam_management_v4_address:
4185 value: {get_param: admin_oam_ip_0 }
4187 *Example: Cloud Assigned IP Address output as*
4188 oam\_management\_v4\_address
4190 .. code-block:: yaml
4195 admin_oam_net_0_port:
4196 type: OS::Neutron::Port
4200 template: VNF_NAME_admin_oam_net_0_port
4202 VNF_NAME: {get_param: vnf_name}
4203 network: { get_param: oam_net_id }
4204 security_groups: [{ get_param: security_group }]
4207 type: OS::Nova::Server
4209 name: { get_param: admin_names }
4210 image: { get_param: admin_image_name }
4211 flavor: { get_param: admin_flavor_name }
4212 availability_zone: { get_param: availability_zone_0 }
4214 - port: { get_resource: admin_oam_net_0_port }
4216 vnf_id: { get_param: vnf_id }
4217 vf_module_id: { get_param: vf_module_id }
4218 vnf_name: {get_param: vnf_name }
4221 oam_management_v4_address:
4222 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4224 Contrail Resource Parameters
4225 ----------------------------
4227 ONAP requires the parameter names of certain Contrail Resources to
4228 follow specific naming conventions. This section provides these
4231 Contrail Network Parameters
4232 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4234 Contrail based resources may require references to a Contrail network
4235 using the network FQDN.
4240 When the parameter associated with the Contrail Network is referencing
4241 an “external” network, the parameter must adhere to the following naming
4242 convention in the Heat Orchestration Template
4244 - {network-role}\_net\_fqdn
4246 The parameter must be declared as type: string
4248 The parameter must not be enumerated in the Heat environment file.
4250 *Example: Parameter declaration*
4252 .. code-block:: yaml
4255 {network-role}_net_fqdn:
4257 description: Contrail FQDN for the {network-role} network
4259 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4260 Reference to a Network FQDN.*
4262 In this example, the {network-role} has been defined as oam to represent
4263 an oam network and the {vm-type} has been defined as fw for firewall.
4264 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4265 virtual\_network\_refs references a contrail network FQDN.
4267 .. code-block:: yaml
4270 type: OS::ContrailV2::VirtualMachineInterface
4274 template: VM_NAME_virtual_machine_interface_1
4276 VM_NAME: { get_param: fw_name_0 }
4277 virtual_machine_interface_properties:
4278 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4279 virtual_network_refs:
4280 - get_param: oam_net_fqdn
4281 security_group_refs:
4282 - get_param: fw_sec_grp_id
4284 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4285 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4287 The parameter associated with the resource
4288 OS::ContrailV2::InterfaceRouteTable property
4289 interface\_route\_table\_routes, map property
4290 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4293 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4294 in the Heat Orchestration Template.
4296 The parameter must be declared as type: json
4298 The parameter supports IP addresses in the format:
4300 1. Host IP Address (e.g., 10.10.10.10)
4302 2. CIDR Notation format (e.g., 10.0.0.0/28)
4304 The parameter must not be enumerated in the Heat environment file.
4306 *Example Parameter Definition*
4308 .. code-block:: yaml
4311 {vm-type}_{network-role}_route_prefixes:
4313 description: JSON list of Contrail Interface Route Table route prefixes
4317 .. code-block:: yaml
4322 description: Unique name for this VF instance
4323 fw_int_fw_route_prefixes:
4325 description: prefix for the ServiceInstance InterfaceRouteTable
4326 int_fw_dns_trusted_interface_type:
4328 description: service_interface_type for ServiceInstance
4331 type: OS::ContrailV2::InterfaceRouteTable
4332 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4336 template: VNF_NAME_interface_route_table
4338 VNF_NAME: { get_param: vnf_name }
4339 interface_route_table_routes:
4340 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4341 service_instance_refs:
4342 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4343 service_instance_refs_data:
4344 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4346 Parameter Names in Contrail Resources
4347 -------------------------------------
4349 Contrail Heat resource properties will use, when appropriate, the same
4350 naming convention as OpenStack Heat resources. For example, the resource
4351 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4352 convention is identical to properties in OS::Neutron::Port.
4354 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4355 instance\_ip\_address*
4357 The property instance\_ip\_address uses the same parameter naming
4358 convention as the property fixed\_ips and Map Property ip\_address in
4359 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4360 Address. The {network-role} has been defined as oam\_protected to
4361 represent an oam protected network and the {vm-type} has been defined as
4364 .. code-block:: yaml
4366 CMD_FW_OAM_PROTECTED_RII:
4367 type: OS::ContrailV2::InstanceIp
4369 - FW_OAM_PROTECTED_RVMI
4371 virtual_machine_interface_refs:
4372 - get_resource: FW_OAM_PROTECTED_RVMI
4373 virtual_network_refs:
4374 - get_param: oam_protected_net_fqdn
4375 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4377 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4380 The property instance\_ip\_address uses the same parameter naming
4381 convention as the property fixed\_ips and Map Property subnet\_id in
4382 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4383 Address. The {network-role} has been defined as “oam\_protected” to
4384 represent an oam protected network and the {vm-type} has been defined as
4387 .. code-block:: yaml
4389 CMD_FW_SGI_PROTECTED_RII:
4390 type: OS::ContrailV2::InstanceIp
4392 - FW_OAM_PROTECTED_RVMI
4394 virtual_machine_interface_refs:
4395 - get_resource: FW_OAM_PROTECTED_RVMI
4396 virtual_network_refs:
4397 - get_param: oam_protected_net_fqdn
4398 subnet_uuid: { get_param: oam_protected_subnet_id }
4400 Cinder Volume Templates
4401 -----------------------
4403 ONAP supports the independent deployment of a Cinder volume via separate
4404 Heat Orchestration Templates, the Cinder Volume module. This allows the
4405 volume to persist after VNF deletion so that they can be reused on
4406 another instance (e.g., during a failover activity).
4408 A Base Module or Incremental Module may have a corresponding volume
4409 module. Use of separate volume modules is optional. A Cinder volume may
4410 be embedded within the Base Module or Incremental Module if persistence
4413 If a VNF Base Module or Incremental Module has an independent volume
4414 module, the scope of volume templates must be 1:1 with Base module or
4415 Incremental module. A single volume module must create only the volumes
4416 required by a single Incremental module or Base module.
4418 The following rules apply to independent volume Heat templates:
4420 - Cinder volumes must be created in a separate Heat Orchestration
4421 Template from the Base Module or Incremental Module.
4423 - A single Cinder volume module must include all Cinder volumes
4424 needed by the Base/Incremental module.
4426 - The volume template must define “outputs” for each Cinder volume
4427 resource universally unique identifier (UUID) (i.e. ONAP Volume
4428 Template Output Parameters).
4430 - The VNF Incremental Module or Base Module must define input
4431 parameters that match each Volume output parameter (i.e., ONAP Volume
4432 Template Output Parameters).
4434 - ONAP will supply the volume template outputs automatically to the
4435 bases/incremental template input parameters.
4437 - Volume modules may utilize nested Heat templates.
4439 *Examples: Volume Template*
4441 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4442 creates an independent Cinder volume for a VM in the module
4443 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4444 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4445 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4446 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4447 output statement and provides the value to the incremental module.
4449 Note that the example below is not a complete Heat Orchestration
4450 Template. The {vm-type} has been defined as “lb” for load balancer
4452 incremental\_volume.yaml
4454 .. code-block:: yaml
4465 type: OS::Cinder::Volume
4469 template: VNF_NAME_volume_0
4471 VNF_NAME: { get_param: vnf_name }
4472 size: {get_param: dns_volume_size_0}
4477 value: {get_resource: dns_volume_0}
4483 .. code-block:: yaml
4494 type: OS::Nova::Server
4496 name: {get_param: dns_name_0}
4501 type: OS::Cinder::VolumeAttachment
4503 instance_uuid: { get_resource: lb_0 }
4504 volume_id: { get_param: lb_volume_id_0 }
4506 ONAP Support of Environment Files
4507 ---------------------------------
4509 The use of an environment file in OpenStack is optional. In ONAP, it is
4510 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
4511 corresponding environment file, even if no parameters are required to be
4514 (Note that ONAP, the open source version of ONAP, does not
4515 programmatically enforce the use of an environment file.)
4517 A Base Module Heat Orchestration Template must have a corresponding
4520 An Incremental Module Heat Orchestration Template must have a
4521 corresponding environment file.
4523 A Cinder Volume Module Heat Orchestration Template must have a
4524 corresponding environment file.
4526 A nested heat template must not have an environment file; OpenStack does
4529 The environment file must contain parameter values for the ONAP
4530 Orchestration Constants and VNF Orchestration Constants. These
4531 parameters are identical across all instances of a VNF type, and
4532 expected to change infrequently. The ONAP Orchestration Constants are
4533 associated with OS::Nova::Server image and flavor properties (See
4534 `Property: image`_ and `Property: flavor`_). Examples of VNF Orchestration Constants are the networking
4535 parameters associated with an internal network (e.g., private IP ranges)
4536 and Cinder volume sizes.
4538 The environment file must not contain parameter values for parameters
4539 that are instance specific (ONAP Orchestration Parameters, VNF
4540 Orchestration Parameters). These parameters are supplied to the Heat by
4541 ONAP at orchestration time.
4543 SDC Treatment of Environment Files
4544 ----------------------------------
4546 Parameter values enumerated in the environment file are used by SDC as
4547 the default value. However, the SDC user may use the SDC GUI to
4548 overwrite the default values in the environment file.
4550 SDC generates a new environment file for distribution to MSO based on
4551 the uploaded environment file and the user provided GUI updates. The
4552 user uploaded environment file is discarded when the new file is
4553 created. Note that if the user did not change any values via GUI
4554 updates, the SDC generated environment file will contain the same values
4555 as the uploaded file.
4557 Use of Environment Files when using OpenStack “heat stack-create” CLI
4558 ---------------------------------------------------------------------
4560 When ONAP is instantiating the Heat Orchestration Template, certain
4561 parameter must not be enumerated in the environment file. This document
4562 provides the details of what parameters should not be enumerated.
4564 If the Heat Orchestration Template is to be instantiated from the
4565 OpenStack Command Line Interface (CLI) using the command “heat
4566 stack-create”, all parameters must be enumerated in the environment
4569 Heat Template Constructs
4570 ------------------------
4572 Nested Heat Templates
4573 ---------------------
4575 ONAP supports nested Heat templates per the OpenStack specifications.
4576 Nested templates may be suitable for larger VNFs that contain many
4577 repeated instances of the same VM type(s). A common usage pattern is to
4578 create a nested template for each {vm-type} along with its supporting
4579 resources. The VNF module may then reference these component templates
4580 either statically by repeated definition or dynamically by using the
4581 resource OS::Heat::ResourceGroup.
4583 Nested Heat Template Requirements
4584 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4586 ONAP supports nested Heat Orchestration Templates. A Base Module,
4587 Incremental Module, and Cinder Volume Module may use nested heat.
4589 A Heat Orchestration Template may reference the nested heat statically
4590 by repeated definition.
4592 A Heat Orchestration Template may reference the nested heat dynamically
4593 using the resource OS::Heat::ResourceGroup.
4595 A Heat Orchestration template must have no more than three levels of
4596 nesting. ONAP supports a maximum of three levels.
4598 Nested heat templates must be referenced by file name. The use of
4599 resource\_registry in the environment file is not supported and must not
4602 A nested heat yaml file must have a unique file names within the scope
4605 ONAP does not support a directory hierarchy for nested templates. All
4606 templates must be in a single, flat directory (per VNF)
4608 A nested heat template may be used by any module within a given VNF.
4612 - Constrains must not be defined for any parameter enumerated in a
4613 nested heat template.
4615 - All parameters defined in nested heat must be passed in as properties
4616 of the resource calling the nested yaml file.
4618 - When OS::Nova::Server metadata parameters are past into a nested heat
4619 template, the parameter names must not change
4621 - With nested templates, outputs are required to expose any resource
4622 properties of the child templates to the parent template. Those would
4623 not explicitly be declared as parameters but simply referenced as
4624 get\_attribute targets against the “parent” resource.
4626 Nested Heat Template Example: Static
4627 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4631 .. code-block:: yaml
4637 dns_image_name: { get_param: dns_image_name }
4638 dns_flavor_name: { get_param: dns_flavor_name }
4639 availability_zone: { get_param: availability_zone_0 }
4640 security_group: { get_param: DNS_shared_sec_grp_id }
4641 oam_net_id: { get_param: oam_protected_net_id }
4642 dns_oam_ip: { get_param: dns_oam_ip_0 }
4643 dns_name: { get_param: dns_name_0 }
4644 vnf_name: { get_param: vnf_name }
4645 vnf_id: { get_param: vnf_id }
4646 vf_module_id: {get_param: vf_module_id}
4651 dns_image_name: { get_param: dns_image_name }
4652 dns_flavor_name: { get_param: dns_flavor_name }
4653 availability_zone: { get_param: availability_zone_1 }
4654 security_group: { get_param: DNS_shared_sec_grp_id }
4655 oam_net_id: { get_param: oam_protected_net_id }
4656 dns_oam_ip: { get_param: dns_oam_ip_1 }
4657 dns_name: { get_param: dns_name_1 }
4658 vnf_name: { get_param: vnf_name }
4659 vnf_id: { get_param: vnf_id }
4660 vf_module_id: {get_param: vf_module_id}
4664 .. code-block:: yaml
4667 type: OS::Neutron::Port
4671 template: VNF_NAME_dns_oam_port
4673 VNF_NAME: {get_param: vnf_name}
4674 network: { get_param: oam_net_id }
4675 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4676 security_groups: [{ get_param: security_group }]
4679 type: OS::Nova::Server
4681 name: { get_param: dns_names }
4682 image: { get_param: dns_image_name }
4683 flavor: { get_param: dns_flavor_name }
4684 availability_zone: { get_param: availability_zone }
4686 - port: { get_resource: dns_oam_0_port }
4688 vnf_id: { get_param: vnf_id }
4689 vf_module_id: { get_param: vf_module_id }
4690 vnf_name {get_param: vnf_name }
4692 Use of Heat ResourceGroup
4693 ~~~~~~~~~~~~~~~~~~~~~~~~~
4695 The OS::Heat::ResourceGroup is a useful Heat element for creating
4696 multiple instances of a given resource or collection of resources.
4697 Typically it is used with a nested Heat template, to create, for
4698 example, a set of identical OS::Nova::Server resources plus their
4699 related OS::Neutron::Port resources via a single resource in a master
4702 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4703 template that creates multiple instances of the same VM type.
4705 However, there are important caveats to be aware of:
4707 ResourceGroup does not deal with structured parameters
4708 (comma-delimited-list and json) as one might typically expect. In
4709 particular, when using a list-based parameter, where each list element
4710 corresponds to one instance of the ResourceGroup, it is not possible to
4711 use the intrinsic “loop variable” %index% in the ResourceGroup
4714 For instance, the following is **not** valid Heat for ResourceGroup:
4716 .. code-block:: yaml
4718 type: OS::Heat::ResourceGroup
4720 type: my_nested_vm_template.yaml
4722 name: {get_param: [vm_name_list, %index%]}
4724 Although this appears to use the nth entry of the vm\_name\_list list
4725 for the nth element of the ResourceGroup, it will in fact result in a
4726 Heat exception. When parameters are provided as a list (one for each
4727 element of a ResourceGroup), you must pass the complete parameter to the
4728 nested template along with the current index as separate parameters.
4730 Below is an example of an **acceptable** Heat Syntax for a
4733 .. code-block:: yaml
4735 type: OS::Heat::ResourceGroup
4737 type: my_nested_vm_template.yaml
4739 names: {get_param: vm_name_list}
4742 You can then reference within the nested template as:
4744 { get\_param: [names, {get\_param: index} ] }
4746 ResourceGroup Property count
4747 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4749 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4750 (even if the value is one) and that the value must be enumerated in the
4751 environment file. This is required for ONAP to build the TOSCA model for
4754 .. code-block:: yaml
4756 type: OS::Heat::ResourceGroup
4758 count: { get_param: count }
4761 type: my_nested_vm_template.yaml
4763 names: {get_param: vm_name_list}
4766 Availability Zone and ResourceGroups
4767 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4769 The resource OS::Heat::ResourceGroup and the property availability\_zone
4770 has been an “issue” with a few VNFs since ONAP only supports
4771 availability\_zone as a string parameter and not a
4772 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4773 to create Virtual Machines in more than one availability zone.
4775 There are numerous solutions to this issue. Below are two suggested
4778 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4779 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4780 availability\_zones by using the intrinsic function list\_join.
4782 .. code-block:: yaml
4785 type: OS::Heat::ResourceGroup
4787 count: { get_param: node_count }
4793 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4797 .. code-block:: yaml
4800 avaialability_zones:
4801 type: comma_delimited_list
4806 type: OS::Nova::Server
4808 name: { get_param: [ dns_names, get_param: index ] }
4809 image: { get_param: dns_image_name }
4810 flavor: { get_param: dns_flavor_name }
4811 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
4814 **Option 2:** Create a resource group per availability zone. A separate
4815 OS::Heat::ResourceGroup is created for each availability zone.
4820 Heat templates *should not* reference any HTTP-based resource
4821 definitions, any HTTP-based nested configurations, or any HTTP-based
4824 - During orchestration, ONAP *should not* retrieve any such resources
4825 from external/untrusted/unknown sources.
4827 - VNF images should not contain such references in user-data or other
4828 configuration/operational scripts that are specified via Heat or
4829 encoded into the VNF image itself.
4831 *Note:* HTTP-based references are acceptable if the HTTP-based reference
4832 is accessing information with the VM private/internal network.
4834 Heat Files Support (get\_file)
4835 ------------------------------
4837 Heat Templates may contain the inclusion of text files into Heat
4838 templates via the Heat get\_file directive. This may be used, for
4839 example, to define a common “user-data” script, or to inject files into
4840 a VM on startup via the “personality” property.
4842 Support for Heat Files is subject to the following limitations:
4844 - The get\_files targets must be referenced in Heat templates by file
4845 name, and the corresponding files should be delivered to ONAP along
4846 with the Heat templates.
4848 - URL-based file retrieval must not be used; it is not supported.
4850 - The included files must have unique file names within the scope of
4853 - ONAP does not support a directory hierarchy for included files.
4855 - All files must be in a single, flat directory per VNF.
4857 - Included files may be used by all Modules within a given VNF.
4859 - get\_file directives may be used in both non-nested and nested
4865 When Nova Servers are created via Heat templates, they may be passed a
4866 “keypair” which provides an ssh key to the ‘root’ login on the newly
4867 created VM. This is often done so that an initial root key/password does
4868 not need to be hard-coded into the image.
4870 Key pairs are unusual in OpenStack, because they are the one resource
4871 that is owned by an OpenStack User as opposed to being owned by an
4872 OpenStack Tenant. As a result, they are usable only by the User that
4873 created the keypair. This causes a problem when a Heat template attempts
4874 to reference a keypair by name, because it assumes that the keypair was
4875 previously created by a specific ONAP user ID.
4877 When a keypair is assigned to a server, the SSH public-key is
4878 provisioned on the VMs at instantiation time. They keypair itself is not
4879 referenced further by the VM (i.e. if the keypair is updated with a new
4880 public key, it would only apply to subsequent VMs created with that
4883 Due to this behavior, the recommended usage of keypairs is in a more
4884 generic manner which does not require the pre-requisite creation of a
4885 keypair. The Heat should be structured in such a way as to:
4887 - Pass a public key as a parameter value instead of a keypair name
4889 - Create a new keypair within the VNF Heat templates (in the base
4890 module) for use within that VNF
4892 By following this approach, the end result is the same as pre-creating
4893 the keypair using the public key – i.e., that public key will be
4894 provisioned in the new VM. However, this recommended approach also makes
4895 sure that a known public key is supplied (instead of having OpenStack
4896 generate a public/private pair to be saved and tracked outside of ONAP).
4897 It also removes any access/ownership issues over the created keypair.
4899 The public keys may be enumerated as a VNF Orchestration Constant in the
4900 environment file (since it is public, it is not a secret key), or passed
4901 at run-time as instance-specific parameters. ONAP will never
4902 automatically assign a public/private key pair.
4904 *Example (create keypair with an existing ssh public-key for {vm-type}
4905 of lb (for load balancer)):*
4907 .. code-block:: yaml
4917 type: OS::Nova::Keypair
4921 template: VNF_NAME_key_pair
4923 VNF_NAME: { get_param: vnf_name }
4924 public_key: {get_param: lb_ssh_public_key}
4925 save_private_key: false
4930 OpenStack allows a tenant to create Security groups and define rules
4931 within the security groups.
4933 Security groups, with their rules, may either be created in the Heat
4934 Orchestration Template or they can be pre-created in OpenStack and
4935 referenced within the Heat template via parameter(s). There can be a
4936 different approach for security groups assigned to ports on internal
4937 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
4938 there can be a common security group across all VMs for a specific
4939 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
4942 Anti-Affinity and Affinity Rules
4943 --------------------------------
4945 Anti-affinity or affinity rules are supported using normal OpenStack
4946 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
4947 created for each VM type to prevent them from residing on the same host,
4948 but they can be applied to multiple VM types to extend the
4949 affinity/anti-affinity across related VM types as well.
4953 In this example, the {network-role} has been defined as oam to represent
4954 an oam network and the {vm-type} have been defined as lb for load
4955 balancer and db for database.
4957 .. code-block:: yaml
4961 type: OS::Nova::ServerGroup
4966 $vnf_name: {get_param: vnf_name}
4967 template: $vnf_name-server_group1
4972 type: OS::Nova::ServerGroup
4977 $vnf_name: {get_param: vnf_name}
4978 template: $vnf_name-server_group2
4983 type: OS::Nova::Server
4987 group: {get_resource: db_server_group}
4990 type: OS::Nova::Server
4994 group: {get_resource: db_server_group}
4997 type: OS::Nova::Server
5001 group: {get_resource: lb_server_group}
5003 Resource Data Synchronization
5004 -----------------------------
5006 For cases where synchronization is required in the orchestration of Heat
5007 resources, two approaches are recommended:
5009 - Standard Heat depends\_on property for resources
5011 - Assures that one resource completes before the dependent resource
5014 - Definition of completeness to OpenStack may not be sufficient
5015 (e.g., a VM is considered complete by OpenStack when it is ready
5016 to be booted, not when the application is up and running).
5018 - Use of Heat Notifications
5020 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5023 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5025 - Dependent resource define depends\_on in the
5026 OS::Heat::WaitCondition resource.
5028 *Example: “depends\_on” case*
5030 In this example, the {network-role} has been defined as oam to represent
5031 an oam network and the {vm-type} has been defined as oam to represent an
5034 .. code-block:: yaml
5038 type: OS::Nova::Server
5040 name: {get_param: [oam_ names, 0]}
5041 image: {get_param: oam_image_name}
5042 flavor: {get_param: oam_flavor_name}
5043 availability_zone: {get_param: availability_zone_0}
5045 - port: {get_resource: oam01_port_0}
5046 - port: {get_resource: oam01_port_1}
5048 scheduler_hints: {group: {get_resource: oam_servergroup}}
5049 user_data_format: RAW
5052 type: OS::Neutron::Port
5054 network: {get_resource: oam_net_name}
5055 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5056 security_groups: [{get_resource: oam_security_group}]
5059 type: OS::Neutron::Port
5061 network: {get_param: oam_net_name}
5062 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5063 security_groups: [{get_resource: oam_security_group}]
5065 oam_01_vol_attachment:
5066 type: OS::Cinder::VolumeAttachment
5067 depends_on: oam_server_01
5069 volume_id: {get_param: oam_vol_1}
5070 mountpoint: /dev/vdb
5071 instance_uuid: {get_resource: oam_server_01}
5076 VNF/VM parameters may include availability zone IDs for VNFs that
5077 require high availability.
5079 The Heat must comply with the following requirements to specific
5080 availability zone IDs:
5082 - The Heat template should spread Nova and Cinder resources across the
5083 availability zones as desired
5085 Post Orchestration & VNF Configuration
5086 --------------------------------------
5088 Heat templates should contain a minimum amount of post-orchestration
5089 configuration data. For instance, *do not* embed complex user-data
5090 scripts in the template with large numbers of configuration parameters
5091 to the Heat template.
5093 - VNFs may provide configuration APIs for use after VNF creation. Such
5094 APIs will be invoked via application and/or SDN controllers.
5096 *Note:* It is important to follow this convention to the extent possible
5097 even in the short-term as of the long-term direction.
5099 c. VNFM Driver Development Steps
5100 ================================
5102 Refer to the ONAP documentation for VNF provider instructions on integrating
5103 special VNFM adaptors with VF-C. The VNF driver development steps are
5106 1. Use the VNF SDK tools to design the VNF with TOSCA models to output
5107 the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
5108 validated and tested.
5110 2. The VNF provider can provide a special VNFM driver in ONAP, which
5111 is a microservice providing a translation interface from VF-C to
5112 the special VNFM. The interface definitions of special VNFM adaptors are provided by
5113 the VNF providers themselves.
5115 d. Creating Special VNFM Adaptor Microservices
5116 ==============================================
5118 VNFs can be managed by special VNFMs. To add a special VNFM to ONAP, a
5119 special VNFM adaptor is added to ONAP implementing the interface of the special VNFM.
5121 A special VNFM adaptor is a microservice with a unique name and an appointed
5122 port. When started up, the special VNFM adaptor microservice is automatically registered to the
5123 Microservices Bus (MSB). The following RESTful example describes the scenario of
5124 registering a special VNFM adaptor to MSB:
5126 .. code-block:: java
5128 POST /api/microservices/v1/services
5130 "serviceName": "catalog",
5132 "url": "/api/catalog/v1",
5137 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob