2 **5. VNF Modeling Requirements**
3 =====================================
12 This reference document is the VNF TOSCA Template Requirements for
13 ONAP, which provides recommendations and standards for building VNF
14 TOSCA templates compatible with ONAP initial implementations of
15 Network Cloud. It has the following features:
17 1. VNF TOSCA template designer supports GUI and CLI.
19 2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
20 Draft 04-Revision 06”.
22 3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
23 Threading, SRIOV， etc.
28 This document is intended for persons developing VNF TOSCA templates
29 that will be orchestrated by ONAP.
34 ONAP implementations of Network Cloud supports TOSCA Templates, also
35 referred to as TOSCA in this document.
37 ONAP requires the TOSCA Templates to follow a specific format. This
38 document provides the mandatory, recommended, and optional requirements
39 associated with this format.
44 The document includes three charters to help the VNF vendors to use the
45 VNF model design tools and understand the VNF package structure and VNF
48 In the ONAP, VNF Package and VNFD template can be designed by manually
49 or via model designer tools. VNF model designer tools can provide the
50 GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD
53 The VNF package structure is align to the NFV TOSCA protocol, and
56 The VNFD and VNF package are all align to the NFV TOSCA protocol, which
57 supports multiple TOSCA template yaml files, and also supports
58 self-defined node or other extensions.
63 TOSCA templates supported by ONAP must follow the requirements
64 enumerated in this section.
69 TOSCA defines a Meta model for defining IT services. This Meta model
70 defines both the structure of a service as well as how to manage it. A
71 Topology Template (also referred to as the topology model of a service)
72 defines the structure of a service. Plans define the process models that
73 are used to create and terminate a service as well as to manage a
74 service during its whole lifetime.
76 A Topology Template consists of a set of Node Templates and Relationship
77 Templates that together define the topology model of a service as a (not
78 necessarily connected) directed graph. A node in this graph is
79 represented by a *Node Template*. A Node Template specifies the
80 occurrence of a Node Type as a component of a service. A *Node Type*
81 defines the properties of such a component (via *Node Type Properties*)
82 and the operations (via *Interfaces*) available to manipulate the
83 component. Node Types are defined separately for reuse purposes and a
84 Node Template references a Node Type and adds usage constraints, such as
85 how many times the component can occur.
89 Figure 1: Structural Elements of Service Template and their Relations
91 TOSCA Modeling Principles & Data Model
92 --------------------------------------
94 This section describing TOSCA modeling principles and data model for
95 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
96 V1.0], or new type based on ETSI NFV requirements, etc.
98 VNF Descriptor Template
99 -----------------------
101 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
102 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
103 Links, External Connection Points, Scaling Aspects, Instantiation Levels
104 and Deployment Flavours.
106 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
107 represents the contract & interface of a VNF and ensures the
108 interoperability across the NFV functional blocks.
110 The main parts of the VNFD are the following:
112 - VNF topology: it is modeled in a cloud agnostic way using virtualized
113 containers and their connectivity. Virtual Deployment Units (VDU)
114 describe the capabilities of the virtualized containers, such as
115 virtual CPU, RAM, disks; their connectivity is modeled with VDU
116 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
117 and VNF External Connection Point Descriptors (VnfExternalCpd);
119 - VNF deployment aspects: they are described in one or more deployment
120 flavours, including instantiation levels, supported LCM operations,
121 VNF LCM operation configuration parameters, placement constraints
122 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
123 and scaling aspect for horizontal scaling.
125 The following table defines the TOSCA Type “derived from” values that
126 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
127 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
129 +-----------------------------------------+---------------------------------------+-----------------------+
130 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
132 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
133 +=========================================+=======================================+=======================+
134 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
135 +-----------------------------------------+---------------------------------------+-----------------------+
136 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
137 +-----------------------------------------+---------------------------------------+-----------------------+
138 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
139 +-----------------------------------------+---------------------------------------+-----------------------+
140 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
141 +-----------------------------------------+---------------------------------------+-----------------------+
142 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
143 +-----------------------------------------+---------------------------------------+-----------------------+
144 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
145 +-----------------------------------------+---------------------------------------+-----------------------+
146 | Virtual Storage | | |
147 +-----------------------------------------+---------------------------------------+-----------------------+
148 | Virtual Compute | | |
149 +-----------------------------------------+---------------------------------------+-----------------------+
150 | Software Image | | |
151 +-----------------------------------------+---------------------------------------+-----------------------+
152 | Deployment Flavour | | |
153 +-----------------------------------------+---------------------------------------+-----------------------+
154 | Scaling Aspect | | |
155 +-----------------------------------------+---------------------------------------+-----------------------+
156 | Element Group | | |
157 +-----------------------------------------+---------------------------------------+-----------------------+
158 | Instantiation Level | | |
159 +-----------------------------------------+---------------------------------------+-----------------------+
161 +--------------------------------------------------------------------+
162 | +--------------------------------------------------------------+ |
163 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
165 | | description: VNFD TOSCA file demo | |
169 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
171 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
173 | | | **node\_types: | |
174 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
175 | | derived\_from:** tosca.nodes.nfv.VNF | |
176 | | | **requirements: | |
177 | | **- **sriov\_plane: | |
178 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
179 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
180 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
181 | +--------------------------------------------------------------+ |
182 +====================================================================+
183 +--------------------------------------------------------------------+
188 1. SR-IOV Passthrought
190 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
193 +------------------------------------------------+
202 | tosca\_name: SRIOV\_Port |
206 | virtual\_network\_interface\_requirements: |
210 | support\_mandatory: false |
212 | description: sriov |
220 | description: sriov port |
222 | layer\_protocol: ipv4 |
226 | - virtual\_binding: |
228 | capability: virtual\_binding |
234 | type: tosca.relationships.nfv.VirtualBindsTo |
238 | node: tosca.nodes.Root |
240 | type: tosca.nodes.nfv.VduCpd |
242 | substitution\_mappings: |
252 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
253 +------------------------------------------------+
257 Definitions of mem\_page\_size as one property shall be added to
258 Properties and set the value to large if one VDU node supports
259 huagepages. Here is an example.
261 +----------------------------------+
270 | tosca\_name: Huge\_pages\_demo |
274 | mem\_page\_size:large |
275 +==================================+
276 +----------------------------------+
280 Likewise, we shall add definitions of numa to
281 requested\_additional\_capabilities if we wand VUD nodes to support
282 NUMA. Here is an example.
284 +-------------------------------------------------+
285 | topology\_template: |
293 | virtual\_compute: |
299 | numa\_enabled: true |
301 | virtual\_mem\_size: 2 GB |
303 | requested\_additional\_capabilities: |
307 | support\_mandatory: true |
309 | requested\_additional\_capability\_name: numa |
311 | target\_performance\_parameters: |
313 | hw:numa\_nodes: "2" |
315 | hw:numa\_cpus.0: "0,1" |
317 | hw:numa\_mem.0: "1024" |
319 | hw:numa\_cpus.1: "2,3,4,5" |
321 | hw:numa\_mem.1: "1024" |
322 +-------------------------------------------------+
326 Definitions of Hyper-Theading are necessary as one of
327 requested\_additional\_capabilities of one VUD node if that node
328 supports Hyper-Theading. Here is an example.
330 +-------------------------------------------------------------+
331 | topology\_template: |
339 | virtual\_compute: |
345 | numa\_enabled: true |
347 | virtual\_mem\_size: 2 GB |
349 | requested\_additional\_capabilities: |
351 | hyper\_threading: |
353 | support\_mandatory: true |
355 | requested\_additional\_capability\_name: hyper\_threading |
357 | target\_performance\_parameters: |
359 | hw:cpu\_sockets : "2" |
361 | hw:cpu\_threads : "2" |
363 | hw:cpu\_cores : "2" |
365 | hw:cpu\_threads\_policy: "isolate" |
366 +-------------------------------------------------------------+
370 Definitions of ovs\_dpdk are necessary as one of
371 requested\_additional\_capabilities of one VUD node if that node
372 supports dpdk. Here is an example.
374 +------------------------------------------------------+
375 | topology\_template: |
383 | virtual\_compute: |
389 | numa\_enabled: true |
391 | virtual\_mem\_size: 2 GB |
393 | requested\_additional\_capabilities: |
397 | support\_mandatory: true |
399 | requested\_additional\_capability\_name: ovs\_dpdk |
401 | target\_performance\_parameters: |
403 | sw:ovs\_dpdk: "true" |
404 +------------------------------------------------------+
406 NFV TOSCA Type Definition
407 -------------------------
409 tosca.capabilites.nfv.VirtualCompute
410 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
412 +---------------------------+-----------------------------------------+
413 | **Shorthand Name** | VirtualCompute |
414 +===========================+=========================================+
415 | **Type Qualified Name** | tosca: VirtualCompute |
416 +---------------------------+-----------------------------------------+
417 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
418 +---------------------------+-----------------------------------------+
419 | **derived from** | tosca.nodes.Root |
420 +---------------------------+-----------------------------------------+
425 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
426 | Name | Required | Type | Constraints | Description |
427 +=====================================+============+=====================================================+===============+=========================================================+
428 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
429 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
430 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
431 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
432 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
433 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
434 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
436 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
441 +-----------------------------------------------------------+
442 | tosca.capabilities.nfv.VirtualCompute: |
444 | derived\_from: tosca.capabilities.Root |
448 | requested\_additional\_capabilities: |
454 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
460 | type: tosca.datatypes.nfv.VirtualMemory |
466 | type: tosca.datatypes.nfv.VirtualCpu |
469 +-----------------------------------------------------------+
471 tosca.nodes.nfv.VDU.Compute
472 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
474 The NFV Virtualization Deployment Unit (VDU) compute node type
475 represents a VDU entity which it describes the deployment and
476 operational behavior of a VNF component (VNFC), as defined by **[ETSI
479 +-----------------------+-------------------------------+
480 | Shorthand Name | VDU.Compute |
481 +=======================+===============================+
482 | Type Qualified Name | tosca:VDU.Compute |
483 +-----------------------+-------------------------------+
484 | Type URI | tosca.nodes.nfv.VDU.Compute |
485 +-----------------------+-------------------------------+
486 | derived\_from | tosca.nodes.Compute |
487 +-----------------------+-------------------------------+
500 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
501 | Name | Type | Constraints | Description |
502 +=========================+=================================================+===============+=====================================================================================================+
503 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
504 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
505 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
507 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
508 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
509 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
511 | | editor note: need to create a capability type | | |
512 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
517 +-----------------------------------------------------------------------------------------------------+
518 | tosca.nodes.nfv.VDU.Compute: |
520 | derived\_from: tosca.nodes.Compute |
538 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
546 | nfvi\_constraints: |
556 | configurable\_properties: |
562 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
568 | private\_address: |
570 | status: deprecated |
574 | status: deprecated |
578 | status: deprecated |
582 | status: deprecated |
586 | virtual\_compute: |
588 | type: tosca.capabilities.nfv.VirtualCompute |
590 | virtual\_binding: |
592 | type: tosca.capabilities.nfv.VirtualBindable |
594 | #monitoring\_parameter: |
596 | # modeled as ad hoc (named) capabilities in VDU node template |
602 | # cpu\_load: tosca.capabilities.nfv.Metric |
604 | # memory\_usage: tosca.capabilities.nfv.Metric |
606 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
608 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
610 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
612 | occurrences: [0,UNBOUNDED] |
616 | occurrences: [0,0] |
620 | occurrences: [0,0] |
622 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
624 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
628 | occurrences: [0,UNBOUND] |
632 | - virtual\_storage: |
634 | capability: tosca.capabilities.nfv.VirtualStorage |
636 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
638 | node: tosca.nodes.nfv.VDU.VirtualStorage |
640 | occurences: [ 0, UNBOUNDED ] |
642 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
644 | occurrences: [0,0] |
652 | type: tosca.artifacts.nfv.SwImage |
653 +-----------------------------------------------------------------------------------------------------+
657 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
658 | Name | Required | Type | Constraints | Description |
659 +===========+============+===============================+===============+================================================+
660 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
661 | | | | | directly realizing this virtual storage |
662 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
672 The TOSCA Cpd node represents network connectivity to a compute resource
673 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
674 used as parent for the various Cpd types.
676 +-----------------------+-----------------------+
677 | Shorthand Name | Cpd |
678 +=======================+=======================+
679 | Type Qualified Name | tosca:Cpd |
680 +-----------------------+-----------------------+
681 | Type URI | tosca.nodes.nfv.Cpd |
682 +-----------------------+-----------------------+
688 +--------+------------+--------+---------------+---------------+
689 | Name | Required | Type | Constraints | Description |
690 +========+============+========+===============+===============+
691 +--------+------------+--------+---------------+---------------+
706 +----------------------------------------------------------------------+
707 | tosca.nodes.nfv.Cpd: |
709 | derived\_from: tosca.nodes.Root |
719 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
723 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
729 | - valid\_values: [ root, leaf ] |
745 | type: tosca.datatype.nfv.AddressData |
748 +----------------------------------------------------------------------+
750 Additional Requirement
751 ^^^^^^^^^^^^^^^^^^^^^^
755 tosca.nodes.nfv.VduCpd
756 ~~~~~~~~~~~~~~~~~~~~~~
758 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
759 network connectivity between a VNFC instance (based on this VDU) and an
760 internal VL as defined by [ETSI GS NFV-IFA 011].
762 +-----------------------+--------------------------+
763 | Shorthand Name | VduCpd |
764 +=======================+==========================+
765 | Type Qualified Name | tosca: VduCpd |
766 +-----------------------+--------------------------+
767 | Type URI | tosca.nodes.nfv.VduCpd |
768 +-----------------------+--------------------------+
774 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
775 | Name | Required | Type | Constraints | Description |
776 +===============================+============+==========================================+==========================================================================+
777 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
778 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
779 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
780 | requirements | | | | realising the CPs instantiated from this CPD |
781 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
791 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
792 | Name | Required | Type | Constraints | Description |
793 +====================+============+==========================================+===============+==========================================================+
794 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
795 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
796 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
797 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
802 +----------------------------------------------------------------+
803 | tosca.nodes.nfv.VduCpd: |
805 | derived\_from: tosca.nodes.nfv.Cpd |
809 | bitrate\_requirement: |
815 | virtual\_network\_interface\_requirements |
821 | type: VirtualNetworkInterfaceRequirements |
829 | capability: tosca.capabilities.nfv.VirtualLinkable |
831 | relationship: tosca.relationships.nfv.VirtualLinksTo |
833 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
835 | capability: tosca.capabilities.nfv.VirtualBindable |
837 | relationship: tosca.relationships.nfv.VirtualBindsTo |
839 | node: tosca.nodes.nfv.VDU |
840 +----------------------------------------------------------------+
842 tosca.nodes.nfv.VDU.VirtualStorage
843 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
845 The NFV VirtualStorage node type represents a virtual storage entity
846 which it describes the deployment and operational behavior of a virtual
847 storage resources, as defined by **[ETSI NFV IFA011].**
849 **[editor note]** open issue: should NFV profile use the current storage
850 model as described in YAML 1.1. Pending on Shitao proposal (see
851 NFVIFA(17)000110 discussion paper)
853 **[editor note]** new relationship type as suggested in Matt
854 presentation. Slide 8. With specific rules of “valid\_target\_type”
856 +---------------------------+--------------------------------------+
857 | **Shorthand Name** | VirtualStorage |
858 +===========================+======================================+
859 | **Type Qualified Name** | tosca: VirtualStorage |
860 +---------------------------+--------------------------------------+
861 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
862 +---------------------------+--------------------------------------+
863 | **derived\_from** | tosca.nodes.Root |
864 +---------------------------+--------------------------------------+
866 tosca.artifacts.nfv.SwImage
867 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
869 +---------------------------+------------------------------------+
870 | **Shorthand Name** | SwImage |
871 +===========================+====================================+
872 | **Type Qualified Name** | tosca:SwImage |
873 +---------------------------+------------------------------------+
874 | **Type URI** | tosca.artifacts.nfv.SwImage |
875 +---------------------------+------------------------------------+
876 | **derived\_from** | tosca.artifacts.Deployment.Image |
877 +---------------------------+------------------------------------+
882 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
883 | Name | Required | Type | Constraints | Description |
884 +==========================================+============+====================+===============+====================================================================================================+
885 | name | yes | string | | Name of this software image |
886 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
887 | version | yes | string | | Version of this software image |
888 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
889 | checksum | yes | string | | Checksum of the software image file |
890 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
891 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
892 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
893 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
894 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
895 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
896 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
897 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
898 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
899 | Size | yes | scalar-unit.size | | The size of this software image |
900 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
901 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
902 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
903 | operating\_system | no | string | | Identifies the operating system used in the software image. |
904 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
905 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
906 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
911 +-----------------------------------------------------+
912 | tosca.artifacts.nfv.SwImage: |
914 | derived\_from: tosca.artifacts.Deployment.Image |
916 | properties or metadata: |
940 | container\_format: |
954 | type: scalar-unit.size # Number |
960 | type: scalar-unit.size # Number |
966 | type: scalar-unit.size # Number |
976 | operating\_system: |
982 | supported\_virtualisation\_environments: |
991 +-----------------------------------------------------+
996 openovnf\_\_vOpenNAT.yaml
997 ~~~~~~~~~~~~~~~~~~~~~~~~~
999 +-------------------------------------------------------------+
1002 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1004 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1006 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1008 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1010 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1012 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1014 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1016 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1018 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1020 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1022 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1024 | - openonfv\_\_tosca.capabilities.Container.yaml |
1026 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1028 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1030 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1032 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1034 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1036 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1038 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1042 | vnfProductName: openNAT |
1044 | vnfdVersion: 1.0.0 |
1046 | vnfProvider: intel |
1050 | csarVersion: 1.0.0 |
1052 | vnfdId: openNAT-1.0 |
1054 | csarProvider: intel |
1056 | vnfProductInfoDescription: openNAT |
1064 | localizationLanguage: '[english, chinese]' |
1068 | defaultLocalizationLanguage: english |
1070 | vnfProductInfoName: openNAT |
1072 | vnfSoftwareVersion: 1.0.0 |
1074 | topology\_template: |
1076 | node\_templates: |
1084 | file: /swimages/xenial-snat.qcow2 |
1086 | type: tosca.artifacts.nfv.SwImage |
1090 | name: vNatVNFImage |
1094 | checksum: "5000" |
1096 | container\_format: bare |
1098 | disk\_format: qcow2 |
1100 | min\_disk: 10 GB |
1106 | sw\_image: /swimages/xenial-snat.qcow2 |
1108 | operating\_system: unbantu |
1112 | tosca\_name: vdu\_vNat |
1116 | virtual\_compute: |
1120 | virtual\_memory: |
1122 | numa\_enabled: true |
1124 | virtual\_mem\_size: 2 GB |
1126 | requested\_additional\_capabilities: |
1130 | support\_mandatory: true |
1132 | requested\_additional\_capability\_name: numa |
1134 | target\_performance\_parameters: |
1136 | hw:numa\_nodes: "2" |
1138 | hw:numa\_cpus.0: "0,1" |
1140 | hw:numa\_mem.0: "1024" |
1142 | hw:numa\_cpus.1: "2,3,4,5" |
1144 | hw:numa\_mem.1: "1024" |
1146 | hyper\_threading: |
1148 | support\_mandatory: true |
1150 | requested\_additional\_capability\_name: hyper\_threading |
1152 | target\_performance\_parameters: |
1154 | hw:cpu\_sockets : "2" |
1156 | hw:cpu\_threads : "2" |
1158 | hw:cpu\_cores : "2" |
1160 | hw:cpu\_threads\_policy: "isolate" |
1164 | support\_mandatory: true |
1166 | requested\_additional\_capability\_name: ovs\_dpdk |
1168 | target\_performance\_parameters: |
1170 | sw:ovs\_dpdk: "true" |
1174 | cpu\_architecture: X86 |
1176 | num\_virtual\_cpu: 2 |
1180 | configurable\_properties: |
1184 | additional\_vnfc\_configurable\_properties: |
1190 | descrption: the virtual machine of vNat |
1198 | - virtual\_storage: |
1200 | capability: virtual\_storage |
1202 | node: vNAT\_Storage |
1208 | location: /mnt/volume\_0 |
1210 | type: tosca.relationships.nfv.VDU.AttachedTo |
1212 | - local\_storage: |
1214 | node: tosca.nodes.Root |
1216 | type: tosca.nodes.nfv.VDU.Compute |
1222 | tosca\_name: SRIOV\_Port |
1226 | virtual\_network\_interface\_requirements: |
1230 | support\_mandatory: false |
1232 | description: sriov |
1240 | description: sriov port |
1242 | layer\_protocol: ipv4 |
1246 | - virtual\_binding: |
1248 | capability: virtual\_binding |
1254 | type: tosca.relationships.nfv.VirtualBindsTo |
1256 | - virtual\_link: |
1258 | node: tosca.nodes.Root |
1260 | type: tosca.nodes.nfv.VduCpd |
1266 | tosca\_name: vNAT\_Storage |
1270 | id: vNAT\_Storage |
1272 | size\_of\_storage: 10 GB |
1274 | rdma\_enabled: false |
1276 | type\_of\_storage: volume |
1278 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1280 | substitution\_mappings: |
1290 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1292 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1293 +-------------------------------------------------------------+
1295 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1296 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1298 +------------------------------------------------------------+
1301 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1305 | tosca.nodes.nfv.VDU.VirtualStorage: |
1309 | virtual\_storage: |
1311 | type: tosca.capabilities.nfv.VirtualStorage |
1313 | derived\_from: tosca.nodes.Root |
1321 | size\_of\_storage: |
1331 | type\_of\_storage: |
1335 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1336 +------------------------------------------------------------+
1338 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1339 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1341 +-----------------------------------------------------------------+
1344 | tosca.datatypes.nfv.L3AddressData: |
1348 | number\_of\_ip\_address: |
1354 | ip\_address\_assignment: |
1358 | ip\_address\_type: |
1362 | - valid\_values: |
1372 | floating\_ip\_activated: |
1376 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1386 | support\_mandatory: |
1404 | tosca.datatype.nfv.AddressData: |
1412 | - valid\_values: |
1420 | l2\_address\_data: |
1424 | type: tosca.datatypes.nfv.L2AddressData |
1426 | l3\_address\_data: |
1430 | type: tosca.datatypes.nfv.L3AddressData |
1432 | tosca.datatypes.nfv.L2AddressData: {} |
1436 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1438 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1442 | tosca.nodes.nfv.VduCpd: |
1444 | derived\_from: tosca.nodes.Root |
1448 | virtual\_network\_interface\_requirements: |
1452 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1462 | - valid\_values: |
1472 | bitrate\_requirement: |
1484 | layer\_protocol: |
1488 | - valid\_values: |
1508 | type: tosca.datatype.nfv.AddressData |
1516 | - virtual\_binding: |
1518 | capability: tosca.capabilities.nfv.VirtualBindable |
1526 | - virtual\_link: |
1528 | capability: tosca.capabilities.nfv.VirtualBindable |
1536 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1537 +-----------------------------------------------------------------+
1539 .. |image1| image:: Image1.png
1542 .. |image2| image:: Image2.png
1556 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1557 Markup Language) is a human friendly data serialization standard for all
1558 programming languages. See http://www.yaml.org/.
1560 Heat Orchestration Template Format
1561 ----------------------------------
1563 Heat Orchestration templates must be defined in YAML.
1567 - Tabs are NOT allowed, use spaces ONLY.
1569 - You MUST indent your properties and lists with 1 or more spaces.
1571 - All Resource IDs and resource property parameters are case-sensitive.
1572 (e.g., "ThIs", is not the same as "thiS")
1574 Heat Orchestration Template Structure
1575 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1577 Heat Orchestration template structure follows the following format, as
1578 defined by OpenStack at
1579 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1581 .. code-block:: yaml
1583 heat_template_version: <date>
1586 # a description of the template
1589 # a declaration of input parameter groups and order
1592 # declaration of input parameters
1595 # declaration of template resources
1598 # declaration of output parameters
1601 # declaration of conditions
1604 Heat Orchestration templates for ONAP must contain the following
1607 - heat\_template\_version:
1615 Heat Orchestration templates for ONAP may contain the following
1618 - parameter\_groups:
1622 heat\_template\_version
1623 ^^^^^^^^^^^^^^^^^^^^^^^
1625 This section is ONAP mandatory. The heat\_template\_version must be set
1626 to a date that is supported by the OpenStack environment.
1631 This ONAP mandatory section allows for a description of the template.
1636 This ONAP optional section allows for specifying how the input
1637 parameters should be grouped and the order to provide the parameters in.
1642 The parameter section is ONAP mandatory. This section allows for
1643 specifying input parameters that have to be provided when instantiating
1644 the template. Each parameter is specified in a separated nested block
1645 with the name of the parameters defined in the first line and additional
1646 attributes (e.g., type, label) defined as nested elements.
1648 The Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process
1649 requires all parameters declared in a template to be used in a resource
1650 with the exception of the parameters for the OS::Nova::Server property
1651 availability\_zone. See `Property: availability\_zone`_. for more details on
1654 .. code-block:: yaml
1658 type: <string | number | json | comma_delimited_list | boolean>
1659 label: <human-readable name of the parameter>
1660 description: <description of the parameter>
1661 default: <default value for parameter>
1662 hidden: <true | false>
1664 <parameter constraints>
1665 immutable: <true | false>
1669 - The name of the parameter.
1671 - ONAP requires that the param name must contain only alphanumeric
1672 characters and “\_” underscores. Special characters must not be
1677 - The type of the parameter. Supported types are string, number,
1678 comma\_delimited\_list, json and boolean.
1680 - This attribute must be provided per the OpenStack Heat
1681 Orchestration Template standard.
1685 - A human readable name for the parameter.
1687 - This attribute is optional.
1691 - A human readable description for the parameter.
1693 - This attribute is ONAP mandatory; it must be provided. (Note that
1694 this attribute is OpenStack optional.)
1698 - A default value for the parameter.
1700 - ONAP does not support this attribute; it *must not* be provided in
1701 the Heat Orchestration Template. If a parameter has a default
1702 value, it must be provided in the environment file. (Note that
1703 this attribute is OpenStack optional.)
1707 - Defines whether the parameters should be hidden when a user
1708 requests information about a stack created from the template. This
1709 attribute can be used to hide passwords specified as parameters.
1711 - This attribute is optional and defaults to false.
1715 - A list of constraints to apply. The constraints block of a
1716 parameter definition defines additional validation constraints
1717 that apply to the value of the parameter. The parameter values
1718 provided in the Heat Orchestration Template are validated against
1719 the constraints at instantiation time. The constraints are defined
1720 as a list with the following syntax
1724 - <constraint type>: <constraint definition>
1726 description: <constraint description>
1728 - constraint type: Type of constraint to apply.
1730 - constraint definition: The actual constraint, depending on the
1733 - description: A description of the constraint. The text is presented
1734 to the user when the value the user defines violates the constraint.
1735 If omitted, a default validation message is presented to the user.
1736 This attribute is optional.
1738 - When the parameter type is set to number, the Heat Orchestration
1739 Template uploaded into ONAP must have constraints for range or
1742 - range: The range constraint applies to parameters of type number.
1743 It defines a lower and upper limit for the numeric value of the
1744 parameter. The syntax of the range constraint is
1746 range: { min: <lower limit>, max: <upper limit> }
1748 It is possible to define a range constraint with only a lower limit
1751 - allowed\_values: The allowed\_values constraint applies to parameters
1752 of type string or number. It specifies a set of possible values for a
1753 parameter. At deployment time, the user-provided value for the
1754 respective parameter must match one of the elements of the list. The
1755 syntax of the allowed\_values constraint is
1757 allowed\_values: [ <value>, <value>, ... ]
1759 Alternatively, the following YAML list notation can be used
1769 - Other <constraint type> are optional, they may be used (e.g., length,
1770 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1773 - Note that constrains must not be defined for any parameter enumerated
1774 in a nested heat template.
1776 - Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
1780 - Defines whether the parameter is updatable. Stack update fails, if
1781 this is set to true and the parameter value is changed.
1783 - This attribute is optional and defaults to false.
1788 This section is ONAP mandatory; it must be provided. This section
1789 contains the declaration of the single resources of the template. This
1790 section with at least one resource must be defined in the Heat
1791 Orchestration Template, or the template would not create any resources
1792 when being instantiated.
1794 Each resource is defined as a separate block in the resources section
1795 with the following syntax.
1797 .. code-block:: yaml
1801 type: <resource type>
1803 <property name>: <property value>
1805 <resource specific metadata>
1806 depends\_on: <resource ID or list of ID>
1807 update\_policy: <update policy>
1808 deletion\_policy: <deletion policy>
1809 external\_id: <external resource ID>
1810 condition: <condition name or expression or boolean>
1814 - A resource ID that must be unique within the resources section of
1815 the Heat Orchestration Template.
1817 - ONAP requires that the resource ID must be unique across all Heat
1818 Orchestration Templates that compose the VNF. This requirement
1819 also applies when a VNF is composed of more than one Heat
1820 Orchestration Template (see ONAP VNF Modularity Overview).
1822 - The naming convention for a resource ID is provided in `Resource IDs`_.
1826 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1827 Note that the type may specify a nested heat file. This attribute
1832 - A list of resource-specific properties. The property value can be
1833 provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
1835 - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
1839 - Resource-specific metadata. This section is optional, except for
1840 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1844 - Dependencies of the resource on one or more resources of the
1845 template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
1849 - Update policy for the resource, in the form of a nested
1850 dictionary. Whether update policies are supported and what the
1851 exact semantics are depends on the type of the current resource.
1852 This attribute is optional.
1856 - Deletion policy for the resource. The allowed deletion policies
1857 are Delete, Retain, and Snapshot. Beginning with
1858 heat\_template\_version 2016-10-14, the lowercase equivalents
1859 delete, retain, and snapshot are also allowed. This attribute is
1860 optional; the default policy is to delete the physical resource
1861 when deleting a resource from the stack.
1865 - Allows for specifying the resource\_id for an existing external
1866 (to the stack) resource. External resources cannot depend on other
1867 resources, but we allow other resources to depend on external
1868 resource. This attribute is optional. Note: when this is
1869 specified, properties will not be used for building the resource
1870 and the resource is not managed by Heat. This is not possible to
1871 update that attribute. Also, resource won’t be deleted by heat
1872 when stack is deleted.
1876 - Condition for the resource. The condition decides whether to
1877 create the resource or not. This attribute is optional.
1882 This ONAP optional section allows for specifying output parameters
1883 available to users once the template has been instantiated. If the
1884 section is specified, it will need to adhere to specific requirements.
1885 See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
1887 Environment File Format
1888 -----------------------
1890 The environment file is a yaml text file.
1891 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1893 The environment file can contain the following sections:
1895 - parameters: A list of key/value pairs.
1897 - resource\_registry: Definition of custom resources.
1899 - parameter\_defaults: Default parameters passed to all template
1902 - encrypted\_parameters: List of encrypted parameters.
1904 - event\_sinks: List of endpoints that would receive stack events.
1906 - parameter\_merge\_strategies: Merge strategies for merging parameters
1907 and parameter defaults from the environment file.
1909 Environment files for ONAP must contain the following sections:
1913 Environment files for ONAP may contain the following sections:
1915 - resource\_registry:
1917 - parameter\_defaults:
1919 - encrypted\_parameters:
1923 - parameter\_merge\_strategies:
1925 The use of an environment file in OpenStack is optional. In ONAP, it is
1926 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
1927 corresponding environment file, even if no parameters are enumerated in
1928 the mandatory parameter section.
1930 (Note that ONAP, the open source version of ONAP, does not
1931 programmatically enforce the use of an environment file.)
1933 SDC Treatment of Environment Files
1934 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1936 Parameter values enumerated in the environment file are used by SDC as
1937 the default value. However, the SDC user may use the SDC GUI to
1938 overwrite the default values in the environment file.
1940 SDC generates a new environment file for distribution to MSO based on
1941 the uploaded environment file and the user provided GUI updates. The
1942 user uploaded environment file is discarded when the new file is
1945 ONAP has requirements for what parameters must be enumerated in the
1946 environment file and what parameter must not be enumerated in the
1947 environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1949 Nested Heat Orchestration Templates Overview
1950 --------------------------------------------
1952 ONAP supports nested Heat Orchestration Templates per OpenStack
1955 A Base Module may utilize nested templates.
1957 An Incremental Module may utilize nested templates.
1959 A Cinder Volume Module may utilize nested templates.
1961 A nested template must not define parameter constraints in the parameter
1964 Nested templates may be suitable for larger VNFs that contain many
1965 repeated instances of the same VM type(s). A common usage pattern is to
1966 create a nested template for each VM type along with its supporting
1967 resources. The Heat Orchestration Template may then reference these
1968 nested templates either statically (by repeated definition) or
1969 dynamically (via OS::Heat::ResourceGroup).
1971 See `Nested Heat Templates`_ for additional details.
1973 ONAP Heat Orchestration Template Filenames
1974 ------------------------------------------
1976 In order to enable ONAP to understand the relationship between Heat
1977 files, the following Heat file naming convention must be utilized.
1979 In the examples below, <text> represents any alphanumeric string that
1980 must not contain any special characters and must not contain the word
1986 The file name for the base module must include “base” in the filename
1987 and must match one of the following options:
1989 - base\_<text>.y[a]ml
1991 - <text>\_base.y[a]ml
1995 - <text>\_base\_<text>.y[a]ml
1997 The base module’s corresponding environment file must be named identical
1998 to the base module with “.y[a]ml” replaced with “.env”.
2003 There is no explicit naming convention for the incremental modules. As
2004 noted above, <text> represents any alphanumeric string that must not
2005 contain any special characters and must not contain the word “base”.
2009 The incremental module’s corresponding environment file must be named
2010 identical to the incremental module with “.y[a]ml” replaced with “.env”.
2012 To clearly identify the incremental module, it is recommended to use the
2013 following naming options for modules:
2015 - module\_<text>.y[a]ml
2017 - <text>\_module.y[a]ml
2021 Cinder Volume Modules
2022 ~~~~~~~~~~~~~~~~~~~~~
2024 The file name for the Cinder volume module must be named the same as the
2025 corresponding module it is supporting (base module or incremental
2026 module) with “\_volume” appended
2028 - <base module name>\_volume.y[a]ml
2030 - <incremental module name>\_volume.y[a]ml
2032 The volume module’s corresponding environment file must be named
2033 identical to the volume module with “.y[a]ml” replaced with “.env”.
2038 There is no explicit naming convention for nested Heat files with the
2039 following exceptions; the name should contain “nest”. As noted above,
2040 <text> represents any alphanumeric string that must not contain any
2041 special characters and must not contain the word “base”.
2045 Nested Heat files do not have corresponding environment files, per
2046 OpenStack specifications. All parameter values associated with the
2047 nested heat file must be passed in as properties in the resource
2048 definition defined in the parent heat template.
2050 ONAP Parameter Classifications Overview
2051 ---------------------------------------
2053 In order for ONAP to support workflow automation, Heat Orchestration
2054 Template resource property parameters must adhere to specific naming
2055 conventions and requirements.
2057 Broadly, ONAP categorizes parameters into four categories:
2059 1. ONAP metadata parameters
2061 2. Instance specific parameters
2063 3. Constant parameters
2065 4. Output parameters.
2067 ONAP Metadata Parameters
2068 ~~~~~~~~~~~~~~~~~~~~~~~~
2070 There are both mandatory and optional ONAP metadata parameters
2071 associated with the resource OS::Nova::Server.
2073 - ONAP metadata parameters must not have parameter constraints defined.
2075 - Both mandatory and optional (if specified) ONAP metadata parameter
2076 names must follow the ONAP metadata parameter naming convention.
2078 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
2080 Instance specific parameters
2081 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2083 The instance specific parameters are VNF instance specific. The value of
2084 the parameter will be different for every instance of a VNF (e.g., IP
2085 address). The instance specific parameters are subdivided into two
2086 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2089 ONAP Orchestration Parameters
2090 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2092 ONAP Orchestration Parameters are per instance parameters where the
2093 value is assigned via ONAP automation. (Note that in some cases,
2094 automation is currently not available and the value is loaded into ONAP
2095 prior to instantiation.)
2097 - ONAP orchestration parameters must not be enumerated in the
2100 - When the ONAP orchestration parameter type is set to number, the
2101 parameter must have constraints for range and/or allowed\_values.
2103 - Parameter constraints for ONAP orchestration parameters are optional
2104 for all parameter types other than number. If constraints are
2105 specified, they must adhere to the OpenStack specifications.
2107 - The ONAP orchestration parameter names must follow the ONAP
2108 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2111 VNF Orchestration Parameters
2112 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2114 VNF Orchestration Parameters are per instance parameters where the
2115 values are assigned manually. They are not supported by ONAP automation.
2116 The per instance values are loaded into ONAP prior to VNF instantiation.
2118 - VNF orchestration parameters must not be enumerated in the
2121 - When the VNF orchestration parameter type is set to number, the
2122 parameter must have constraints for range or allowed\_values.
2124 - Parameter constraints for VNF orchestration parameters are optional
2125 for all parameter types other than number. If constraints are
2126 specified, they must adhere to the OpenStack specifications.
2128 - The VNF orchestration parameter names should follow the VNF
2129 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2135 The constant parameters are parameters that remain constant across many
2136 VNF instances (e.g., image, flavor). The constant parameters are
2137 subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
2139 ONAP Constant Parameters
2140 ^^^^^^^^^^^^^^^^^^^^^^^^
2142 - ONAP Constant Parameters must be enumerated in the environment file.
2143 These parameter values are not assigned by ONAP.
2145 - When the ONAP Constant Parameter type is set to number, the parameter
2146 must have constraints for range and/or allowed\_values.
2148 - Parameter constraints for ONAP constant parameters are optional for
2149 all parameter types other than number. If constraints are specified,
2150 they must adhere to the OpenStack specifications.
2152 - The ONAP Constant Parameter names must follow the ONAP orchestration
2153 parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2155 VNF Constant Parameters
2156 ^^^^^^^^^^^^^^^^^^^^^^^
2158 - VNF Constant Parameters must be enumerated in the environment file.
2159 These parameter values are not assigned by ONAP.
2161 - When the VNF Constant Parameters type is set to number, the parameter
2162 must have constraints for range and/or allowed\_values.
2164 - Parameter constraints for ONAP constant parameters are optional for
2165 all parameter types other than number. If constraints are specified,
2166 they must adhere to the OpenStack specifications.
2168 - The VNF Constant Parameters names should follow the ONAP
2169 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2175 The output parameters are parameters defined in the output section of a
2176 Heat Orchestration Template. The ONAP output parameters are subdivided
2177 into three categories:
2179 1. ONAP Base Module Output Parameters
2181 2. ONAP Volume Module Output Parameters
2183 3. ONAP Predefined Output Parameters.
2185 ONAP Base Module Output Parameters
2186 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2188 ONAP Base Module Output Parameters are declared in the outputs: section
2189 of the base module Heat Orchestration Template. A Base Module Output
2190 Parameter is available as an input parameter (i.e., declared in the
2191 “parameters:” section) to all incremental modules in the VNF.
2193 - A Base Module Output Parameter may be used as an input parameter in
2194 an incremental module.
2196 - The Output parameter name and type must match the input parameter
2197 name and type unless the Output parameter is of the type
2198 comma\_delimited\_list.
2200 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2201 a collection of UUIDs from a Resource Group), then the
2202 corresponding input parameter must be declared as type json and
2203 not a comma\_delimited\_list, which is actually a string value
2204 with embedded commas.
2206 - When a Base Module Output Parameter is declared as an input parameter
2207 in an incremental module Heat Orchestration Template, parameter
2208 constraints must not be declared.
2210 Additional details on ONAP Base Module Output Parameters are provided in
2211 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2213 ONAP Volume Module Output Parameters
2214 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2216 The volume template output parameters are only available for the module
2217 (base or add on) that the volume is associated with.
2219 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2220 section of the Cinder volume module Heat Orchestration Template
2222 - An ONAP Volume Module Output Parameter is available as an input
2223 parameter (i.e., declared in the parameters: section) only for the
2224 module (base or incremental) that the Cinder volume module is
2225 associated with. The Output parameter name and type must match the
2226 input parameter name and type unless the Output parameter is of the
2227 type comma\_delimited\_list.
2229 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2230 collection of UUIDs from a Resource Group), then the corresponding
2231 input parameter must be declared as type json and not a
2232 comma\_delimited\_list, which is actually a string value with
2235 - When an ONAP Volume Module Output Parameter is declared as an input
2236 parameter in a base module or incremental module, parameter
2237 constraints must not be declared.
2239 Additional details on ONAP Base Module Output Parameters are provided in
2240 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2242 ONAP Predefined Output Parameters
2243 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2245 ONAP will look for a small set of pre-defined Heat output parameters to
2246 capture resource attributes for inventory in ONAP. These output
2247 parameters are optional and are specified in `OAM Management IP Addresses`_.
2249 Support of heat stack update
2250 ----------------------------
2252 VNF Heat Orchestration Templates must not be designed to utilize the
2253 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2254 does not support the use of heat stack-update command for scaling.
2256 It is important to note that ONAP only supports heat stack-update for
2262 ONAP defines two types of networks: External Networks and Internal
2265 ONAP defines an external network in relation to the VNF and not with
2266 regard to the Network Cloud site. External networks may also be referred
2267 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2269 - VMs in another VNF or
2271 - an external gateway or router
2273 ONAP defines an internal network in relation to the VNF and not with
2274 regard to the Network Cloud site. Internal networks may also be referred
2275 to as “intra-VNF” networks or “private” networks. An internal network
2276 only connects VMs in a single VNF. It must not connect to other VNFs or
2277 an external gateway or router.
2282 VNF Heat Orchestration Templates must not include any resources for
2283 external networks connected to the VNF. External networks must be
2284 orchestrated separately, as independent, stand-alone VNF Heat
2285 Orchestration Templates, so they can be shared by multiple VNFs and
2286 managed independently.
2288 When the external network is created, it must be assigned a unique
2289 {network-role}. The {network-role} should describe the network (e.g.,
2290 oam). The {network-role} while unique to the LCP, can repeat across
2293 An External Network may be a Neutron Network or a Contrail Network
2295 External networks must be passed into the VNF Heat Orchestration
2296 Templates as parameters.
2298 - Neutron Network-id (UUID)
2300 - Neutron Network subnet ID (UUID)
2302 - Contrail Network Fully Qualified Domain Name (FQDN)
2304 ONAP enforces a naming convention for parameters associated with
2305 external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2307 Parameter values associated with an external network will be generated
2308 and/or assigned by ONAP at orchestration time. Parameter values
2309 associated with an external network must not be enumerated in the
2310 environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2312 VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
2313 when attaching VMs to an external network
2315 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2317 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2320 - Note that Neutron Floating IPs must not be used. ONAP does not
2321 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2323 - ONAP supports the property allowed\_address\_pairs in the resource
2324 OS::Neutron:Port and the property
2325 virtual\_machine\_interface\_allowed\_address\_pairs in
2326 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2327 of a virtual IP (VIP) address to a set of VMs.
2329 VNF Heat Orchestration Templates must pass the appropriate external
2330 network IDs into nested VM templates when nested Heat is used.
2335 The VNF Heat Orchestration Templates must include the resource(s) to
2336 create the internal network. The internal network must be either a
2337 Neutron Network or a Contrail Network.
2339 In the modular approach, internal networks must be created in the Base
2340 Module, with their resource IDs exposed as outputs (i.e., ONAP Base
2341 Module Output Parameters) for use by all incremental modules. If the
2342 Network resource ID is required in the base template, then a
2343 get\_resource must be used.
2345 When the internal network is created, it should be assigned a unique
2346 {network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
2349 VNFs may use **Cloud assigned IP addresses** or
2350 **predetermined static IPs** when attaching VMs to an internal network.
2352 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2354 - A predetermined static IP address is enumerated in the Heat
2355 environment file. Since an internal network is local to the VNF, IP
2356 addresses can be re-used at every VNF instance.
2358 - Note that Neutron Floating IPs must not be used. ONAP does not
2359 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2361 - ONAP supports the property allowed\_address\_pairs in the resource
2362 OS::Neutron:Port and the property
2363 virtual\_machine\_interface\_allowed\_address\_pairs in
2364 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2365 of a virtual IP (VIP) address to a set of VMs.
2367 ONAP does not programmatically enforce a naming convention for
2368 parameters for internal network. However, a naming convention is
2369 provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2371 ONAP Resource ID and Parameter Naming Convention
2372 ------------------------------------------------
2374 This section provides the ONAP naming requirements for
2378 2. Resource Property Parameters
2383 The Heat Orchestration Templates for a VNF must assign a VNF unique
2384 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2385 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2386 it does not have to be globally unique across all VNFs that ONAP
2389 Any parameter that is associated with a unique Virtual Machine type in
2390 the VNF must include {vm-type} as part of the parameter name.
2392 Any resource ID that is associated with a unique Virtual Machine type in
2393 the VNF must include {vm-type} as part of the resource ID.
2395 Note that {vm-type} must not be a substring of {network-role}. A
2396 substring of a string is another string that occurs "in". For example,
2397 "oam" is a substring of "oam\_protected". It will cause the
2398 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2399 produce erroneous error messages.
2401 The {vm-type} should not contain the string “\_int” or “int\_” or
2402 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2403 ICE Project) process to produce erroneous error messages.
2405 The {vm-type} must be the same case in all parameter names in the VNF.
2407 The {vm-type} must be the same case in all Resource IDs in the VNF.
2409 It is recommended that the {vm-type} case in the parameter names matches
2410 the {vm-type} case in the Resource IDs.
2412 There are two exceptions to the above rules:
2414 1. The six ONAP Metadata parameters must not be prefixed with a common
2415 {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
2416 *vf\_module\_id*, *vf\_module\_name, vm\_role*. The ONAP Metadata
2417 parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
2419 2. The parameter referring to the OS::Nova::Server property
2420 availability\_zone must not be prefixed with a common {vm-type}
2421 identifier. availability\_zone is described in `Property: availability_zone`_.
2426 The assignment of a {network-role} is discussed in `Networking`_.
2428 Any parameter that is associated with an external network must include
2429 the {network-role} as part of the parameter name.
2431 Any resource ID that is associated with an external network must include
2432 the {network-role} as part of the resource ID.
2434 Any parameter that is associated with an internal network must include
2435 int\_{network-role} as part of the parameter name.
2437 Any resource ID that is associated with an internal network must include
2438 int\_{network-role} as part of the resource ID.
2440 Note that {network-role} must not be a substring of {vm-type}. A
2441 substring of a string is another string that occurs "in". For example,
2442 "oam" is a substring of "oam\_protected". It will cause the
2443 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2444 produce erroneous error messages.
2446 The {network-role} should not contain the string “\_int” or “int\_” or
2447 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2448 ICE Project) process to produce erroneous error messages.
2450 The {network-role} must be the same case in all parameter names in the
2453 The {network-role} must be the same case in all Resource IDs in the VNF.
2455 It is recommended that the {network-role} case in the parameter names
2456 matches the {network-role} case in the Resource IDs.
2461 Heat Orchestration Template resources are described in `resources`_
2463 A resource ID that must be unique within the resources section of a Heat
2464 Orchestration Template. This is an OpenStack Requirement.
2466 When a VNF is composed of more than one Heat Orchestration Template
2467 (i.e., modules), ONAP requires that the resource ID must be unique
2468 across all modules that compose the VNF.
2470 When a resource is associated with a single {vm-type}, the resource ID
2471 must contain {vm-type}.
2473 When a resource is associated with a single external network, the
2474 resource ID must contain {network-role}.
2476 When a resource is associated with a single internal network, the
2477 resource ID must contain int\_{network-role}.
2479 When a resource is associated with a single {vm-type} and a single
2480 external network, the resource ID must contain both the {vm-type} and
2483 - The {vm-type} must appear before the {network-role} and must be
2484 separated by an underscore (i.e., {vm-type}\_{network-role}).
2486 - Note that an {index} value may separate the {vm-type} and the
2487 {network-role}. An underscore will separate the three values (i.e.,
2488 {vm-type}\_{index}\_{network-role}).
2490 When a resource is associated with a single {vm-type} and a single
2491 internal network, the resource ID must contain both the {vm-type} and
2492 int\_{network-role}.
2494 - The {vm-type} must appear before the int\_{network-role} and must be
2495 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2497 - Note that an {index} value may separate the {vm-type} and the
2498 int\_{network-role}. An underscore will separate the three values
2499 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2501 When a resource is associated with more than one {vm-type} and/or more
2502 than one network, the resource ID
2504 - must not contain the {vm-type} and/or
2505 {network-role}/int\_{network-role}
2507 - should contain the term “shared” and/or contain text that identifies
2510 Only alphanumeric characters and “\_” underscores must be used in the
2511 resource ID. Special characters must not be used.
2513 All {index} values must be zero based. That is, the {index} must start
2514 at zero and increment by one.
2516 The table below provides example OpenStack Heat resource ID for
2517 resources only associated with one {vm-type} and/or one network.
2519 +--------------------------------+------------------------------------------------------------+
2520 | Resource Type | Resource ID Format |
2521 +================================+============================================================+
2522 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2523 +--------------------------------+------------------------------------------------------------+
2524 | OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
2525 +--------------------------------+------------------------------------------------------------+
2526 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2527 +--------------------------------+------------------------------------------------------------+
2528 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2529 +--------------------------------+------------------------------------------------------------+
2530 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2531 +--------------------------------+------------------------------------------------------------+
2532 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2533 +--------------------------------+------------------------------------------------------------+
2534 | OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
2535 +--------------------------------+------------------------------------------------------------+
2536 | | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
2537 +--------------------------------+------------------------------------------------------------+
2538 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2539 +--------------------------------+------------------------------------------------------------+
2540 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2541 +--------------------------------+------------------------------------------------------------+
2542 | OS::Nova::Server | {vm\_type}\_{index} |
2543 +--------------------------------+------------------------------------------------------------+
2544 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2545 +--------------------------------+------------------------------------------------------------+
2546 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2547 +--------------------------------+------------------------------------------------------------+
2549 Table 1: Example OpenStack Heat Resource ID
2551 The table below provides example Contrail Heat resource ID for resources
2552 only associated with one {vm-type} and/or one network.
2554 +-------------------------------------------+---------------------------------------------+
2555 | Resource Type | Resource ID Format |
2556 +===========================================+=============================================+
2557 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
2558 +-------------------------------------------+---------------------------------------------+
2559 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2560 +-------------------------------------------+---------------------------------------------+
2561 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2562 +-------------------------------------------+---------------------------------------------+
2563 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2564 +-------------------------------------------+---------------------------------------------+
2565 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2566 +-------------------------------------------+---------------------------------------------+
2567 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2568 +-------------------------------------------+---------------------------------------------+
2569 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2570 +-------------------------------------------+---------------------------------------------+
2571 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2572 +-------------------------------------------+---------------------------------------------+
2574 Table 2: Example Contrail Heat resource ID
2576 Resource: OS::Nova::Server - Parameters
2577 ---------------------------------------
2579 The resource OS::Nova::Server manages the running virtual machine (VM)
2580 instance within an OpenStack cloud. (See
2581 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2583 Four properties of this resource must follow the ONAP parameter naming
2584 convention. The four properties are:
2592 4. availability\_zone
2594 The table below provides a summary. The sections that follow provides
2597 Note that the {vm\_type} must be identical across all four property
2598 parameter for a given OS::Nova::Server resource.
2600 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2601 | Resource OS::Nova::Server |
2602 +=============================+===============================+==================+==============================+=================================+
2603 | Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
2604 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2605 | image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
2606 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2607 | flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
2608 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2609 | name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
2610 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2611 | | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
2612 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2613 | availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
2614 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2616 Table 3 Resource Property Parameter Names
2621 The parameter associated with the property image is an ONAP Constant
2624 The parameters must be named {vm-type}\_image\_name in the Heat
2625 Orchestration Template.
2627 The parameter must be declared as type: string
2629 The parameter must be enumerated in the Heat Orchestration Template
2632 Each VM type (i.e., {vm-type}) must have a separate parameter for image,
2633 even if more than one {vm-type} shares the same image. This provides
2634 maximum clarity and flexibility.
2636 *Example Parameter Definition*
2638 .. code-block:: yaml
2641 {vm-type}_image_name:
2643 description: {vm-type} server image
2648 The parameter associated with the property flavor is an ONAP Constant
2651 The parameters must be named {vm-type}\_flavor\_name in the Heat
2652 Orchestration Template.
2654 The parameter must be declared as type: string
2656 The parameter must be enumerated in the Heat Orchestration Template
2659 Each VM type (i.e., {vm-type}) must have a separate parameter for
2660 flavors, even if more than one {vm-type} shares the same flavor. This
2661 provides maximum clarity and flexibility.
2663 *Example Parameter Definition*
2665 .. code-block:: yaml
2668 {vm-type}_flavor_name:
2670 description: {vm-type} flavor
2675 The parameter associated with the property name is an ONAP Orchestration
2678 The parameter value is provided to the Heat template by ONAP. The
2679 parameter must not be enumerated in the environment file.
2681 The parameter must be declared as type: string or type:
2682 comma\_delimited\_list
2684 If the parameter is declared as type:string, the parameter must be named
2685 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2686 at zero and increments by one.
2688 If the parameter is declared as type:comma\_delimited\_list, the
2689 parameter must be named as {vm-type}\_names
2691 Each element in the VM Name list should be assigned to successive
2692 instances of that VM type.
2694 If a VNF contains more than three instances of a given {vm-type}, the
2695 comma\_delimited\_list form of the parameter name (i.e.,
2696 {vm-type}\_names) should be used to minimize the number of unique
2697 parameters defined in the Heat.
2699 *Example: Parameter Definition*
2701 .. code-block:: yaml
2705 type: comma_delimited_list
2706 description: VM Names for {vm-type} VMs
2707 {vm-type}_name_{index}:
2709 description: VM Name for {vm-type} VM {index}
2711 *Example: comma\_delimited\_list*
2713 In this example, the {vm-type} has been defined as “lb” for load
2716 .. code-block:: yaml
2720 type: comma_delimited_list
2721 description: VM Names for lb VMs
2725 type: OS::Nova::Server
2727 name: { get_param: [lb_names, 0] }
2731 type: OS::Nova::Server
2733 name: { get_param: [lb_names, 1] }
2736 *Example: fixed-index*
2738 In this example, the {vm-type} has been defined as “lb” for load
2741 .. code-block:: yaml
2746 description: VM Name for lb VM 0
2750 description: VM Name for lb VM 1
2754 type: OS::Nova::Server
2756 name: { get_param: lb_name_0 }
2760 type: OS::Nova::Server
2762 name: { get_param: lb_name_1 }
2765 Contrail Issue with Values for OS::Nova::Server Property Name
2766 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2768 The Contrail GUI has a limitation displaying special characters. The
2769 issue is documented in
2770 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2771 recommended that special characters be avoided. However, if special
2772 characters must be used, the only special characters supported are:
2774 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2776 Property: availability\_zone
2777 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2779 The parameter associated with the property availability\_zone is an ONAP
2780 Orchestration parameter.
2782 The parameter value is provided to the Heat template by ONAP. The
2783 parameter must not be enumerated in the environment file.
2785 The parameter must be named availability\_zone\_{index} in the Heat
2786 Orchestration Template. The {index} must start at zero. The {index} must
2787 increment by one. The parameter name must not include the {vm-type}.
2789 The parameter must be declared as type: string
2791 The parameter must not be declared as type: comma\_delimited\_list
2796 The example below depicts part of a Heat Orchestration Template that
2797 uses the four OS::Nova::Server properties discussed in this section.
2799 In the Heat Orchestration Template below, four Virtual Machines
2800 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2801 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2802 parameter associated with the property name is a comma\_delimited\_list
2803 for dns and a string for oam.
2805 .. code-block:: yaml
2810 description: dns server image
2813 description: dns server flavor
2815 type: comma_delimited_list
2816 description: dns server names
2819 description: oam server image
2822 description: oam server flavor
2825 description: oam server name 0
2828 description: oam server name 1
2829 availability_zone_0:
2831 description: availability zone ID or Name
2832 availability_zone_1:
2834 description: availability zone ID or Name
2838 type: OS::Nova::Server
2840 name: { get_param: [ dns_names, 0 ] }
2841 image: { get_param: dns_image_name }
2842 flavor: { get_param: dns_flavor_name }
2843 availability_zone: { get_param: availability_zone_0 }
2847 type: OS::Nova::Server
2849 name: { get_param: [ dns_names, 1 ] }
2850 image: { get_param: dns_image_name }
2851 flavor: { get_param: dns_flavor_name }
2852 availability_zone: { get_param: availability_zone_1 }
2856 type: OS::Nova::Server
2858 name: { get_param: oam_name_0 }
2859 image: { get_param: oam_image_name }
2860 flavor: { get_param: oam_flavor_name }
2861 availability_zone: { get_param: availability_zone_0 }
2865 type: OS::Nova::Server
2867 name: { get_param: oam_name_1 }
2868 image: { get_param: oam_image_name }
2869 flavor: { get_param: oam_flavor_name }
2870 availability_zone: { get_param: availability_zone_1 }
2873 Resource: OS::Nova::Server – Metadata Parameters
2874 ------------------------------------------------
2876 The resource OS::Nova::Server has an OpenStack optional property
2877 metadata. The metadata property is mandatory for ONAP Heat Orchestration
2878 Templates; it must be included.
2880 ONAP requires the following three mandatory metadata parameters for an
2881 OS::Nova::Server resource:
2889 ONAP allows the following three optional metadata parameters for an
2890 OS::Nova::Server resource. They may be included
2896 Note that the metadata parameters do not and must not contain {vm-type}
2899 When Metadata parameters are past into a nested heat template, the
2900 parameter names must not change.
2902 The table below provides a summary. The sections that follow provides
2905 +---------------------------+------------------+----------------------+------------------------------+
2906 | Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
2907 +===========================+==================+======================+==============================+
2908 | vnf\_id | string | Mandatory | ONAP |
2909 +---------------------------+------------------+----------------------+------------------------------+
2910 | vf\_module\_id | string | Mandatory | ONAP |
2911 +---------------------------+------------------+----------------------+------------------------------+
2912 | vnf\_name | string | Mandatory | ONAP |
2913 +---------------------------+------------------+----------------------+------------------------------+
2914 | vf\_module\_name | string | Optional | ONAP |
2915 +---------------------------+------------------+----------------------+------------------------------+
2916 | vm\_role | string | Optional | YAML or Environment File |
2917 +---------------------------+------------------+----------------------+------------------------------+
2918 +---------------------------+------------------+----------------------+------------------------------+
2920 Table 4: ONAP Metadata
2925 The vnf\_id parameter is mandatory; it must be included in the Heat
2926 Orchestration Template.
2928 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
2929 UUID that is the vnf\_id and supplies it to the Heat Orchestration
2930 Template at orchestration time.
2932 The parameter must be declared as type: string
2934 Parameter constraints must not be defined.
2936 The parameter must not be enumerated in the Heat environment file.
2938 *Example Parameter Definition*
2940 .. code-block:: yaml
2945 description: Unique ID for this VNF instance
2950 The vf\_module\_id parameter is mandatory; it must be included in the
2951 Heat Orchestration Template.
2953 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
2954 generates the UUID that is the vf\_module\_id and supplies it to the
2955 Heat Orchestration Template at orchestration time.
2957 The parameter must be declared as type: string
2959 Parameter constraints must not be defined.
2961 The parameter must not be enumerated in the Heat environment file.
2963 *Example Parameter Definition*
2965 .. code-block:: yaml
2970 description: Unique ID for this VNF module instance
2975 The vnf\_name parameter is mandatory; it must be included in the Heat
2976 Orchestration Template.
2978 The vnf\_name parameter value will be generated and/or assigned by ONAP
2979 and supplied to the Heat Orchestration Template by ONAP at orchestration
2982 The parameter must be declared as type: string
2984 Parameter constraints must not be defined.
2986 The parameter must not be enumerated in the Heat environment file.
2988 *Example Parameter Definition*
2990 .. code-block:: yaml
2995 description: Unique name for this VNF instance
3000 The vf\_module\_name parameter is optional; it may be included in the
3001 Heat Orchestration Template.
3003 The vf\_module\_name parameter is the name of the name of the Heat stack
3004 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3005 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3006 needs to be specified as part of the orchestration process.
3008 The parameter must be declared as type: string
3010 Parameter constraints must not be defined.
3012 The parameter must not be enumerated in the Heat environment file.
3014 *Example Parameter Definition*
3016 .. code-block:: yaml
3021 description: Unique name for this VNF Module instance
3026 The vm\_role parameter is optional; it may be included in the Heat
3027 Orchestration Template.
3029 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3030 system and available for use by other ONAP components and/or north bound
3033 The vm\_role values must be either
3035 - hard-coded into the Heat Orchestration Template or
3037 - enumerated in the environment file.
3039 Defining the vm\_role as the {vm-type} is a recommended convention
3041 The parameter must be declared as type: string
3043 Parameter constraints must not be defined.
3045 *Example Parameter Definition*
3047 .. code-block:: yaml
3052 description: Unique role for this VM
3054 *Example Resource Definition: Hard Coded*
3056 In this example, the {vm-role} is hard coded in the Heat Orchestration
3059 .. code-block:: yaml
3063 type: OS::Nova::Server
3069 *Example Resource Definition: get\_param*
3071 In this example, the {vm-role} is enumerated in the environment file.
3073 .. code-block:: yaml
3077 type: OS::Nova::Server
3081 vm_role: { get_param: vm_role }
3086 The example below depicts part of a Heat Orchestration Template that
3087 uses the five of the OS::Nova::Server metadata parameter discussed in
3088 this section. The {vm-type} has been defined as lb for load balancer.
3090 .. code-block:: yaml
3095 description: VM Name for lb VM 0
3098 description: Unique name for this VNF instance
3101 description: Unique ID for this VNF instance
3104 description: Unique name for this VNF Module instance
3107 description: Unique ID for this VNF Module instance
3110 description: Unique role for this VM
3115 type: OS::Nova::Server
3117 name: { get_param: lb_name_0 }
3120 vnf_name: { get_param: vnf_name }
3121 vnf_id: { get_param: vnf_id }
3122 vf_module_name: { get_param: vf_module_name }
3123 vf_module_id: { get_param: vf_module_id }
3126 Resource: OS::Neutron::Port - Parameters
3127 ----------------------------------------
3129 The resource OS::Neutron::Port is for managing Neutron ports (See
3130 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3135 Four properties of the resource OS::Neutron::Port that must follow the
3136 ONAP parameter naming convention. The four properties are:
3140 2. fixed\_ips, ip\_address
3142 3. fixed\_ips, subnet\_id
3144 4. allowed\_address\_pairs, ip\_address
3146 The parameters associated with these properties may reference an
3147 external network or internal network. External networks and internal
3148 networks are defined in `Networking`_.
3153 When the parameter references an external network
3155 - the parameter name must contain {network-role}
3157 - the parameter must not be enumerated in the Heat environment file
3159 - the parameter is classified as an ONAP Orchestration Parameter
3161 +----------------------------------------+-----------------------------------------------+--------------------------+
3162 | Property Name | ONAP Parameter Name | Parameter Type |
3163 +========================================+===============================================+==========================+
3164 | network | {network-role}\_net\_id | string |
3165 +----------------------------------------+-----------------------------------------------+--------------------------+
3166 | | {network-role}\_net\_name | string |
3167 +----------------------------------------+-----------------------------------------------+--------------------------+
3168 | fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
3169 +----------------------------------------+-----------------------------------------------+--------------------------+
3170 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3171 +----------------------------------------+-----------------------------------------------+--------------------------+
3172 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3173 +----------------------------------------+-----------------------------------------------+--------------------------+
3174 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3175 +----------------------------------------+-----------------------------------------------+--------------------------+
3176 | fixed\_ips, subnet | {network-role}\_subnet\_id | string |
3177 +----------------------------------------+-----------------------------------------------+--------------------------+
3178 | | {network-role}\_v6\_subnet\_id | string |
3179 +----------------------------------------+-----------------------------------------------+--------------------------+
3180 | allowed\_address\_pairs, ip\_address | {vm-type}\_{network-role}\_floating\_ip | string |
3181 +----------------------------------------+-----------------------------------------------+--------------------------+
3182 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
3183 +----------------------------------------+-----------------------------------------------+--------------------------+
3184 | | {vm-type}\_{network-role}\_ip\_{index} | string |
3185 +----------------------------------------+-----------------------------------------------+--------------------------+
3186 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3187 +----------------------------------------+-----------------------------------------------+--------------------------+
3188 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3189 +----------------------------------------+-----------------------------------------------+--------------------------+
3190 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3191 +----------------------------------------+-----------------------------------------------+--------------------------+
3193 Table 5: OS::Neutron::Port Resource Property Parameters (External
3199 When the parameter references an internal network
3201 - the parameter name must contain int\_{network-role}
3203 - the parameter may be enumerated in the environment file.
3205 +----------------------------------------+----------------------------------------------------+--------------------------+
3206 | Property | Parameter Name for Internal Networks | Parameter Type |
3207 +========================================+====================================================+==========================+
3208 | network | int\_{network-role}\_net\_id | string |
3209 +----------------------------------------+----------------------------------------------------+--------------------------+
3210 | | int\_{network-role}\_net\_name | string |
3211 +----------------------------------------+----------------------------------------------------+--------------------------+
3212 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3213 +----------------------------------------+----------------------------------------------------+--------------------------+
3214 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3215 +----------------------------------------+----------------------------------------------------+--------------------------+
3216 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3217 +----------------------------------------+----------------------------------------------------+--------------------------+
3218 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3219 +----------------------------------------+----------------------------------------------------+--------------------------+
3220 | fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
3221 +----------------------------------------+----------------------------------------------------+--------------------------+
3222 | | int\_{network-role}\_v6\_subnet\_id | string |
3223 +----------------------------------------+----------------------------------------------------+--------------------------+
3224 | allowed\_address\_pairs, ip\_address | {vm-type}\_int\_{network-role}\_floating\_ip | string |
3225 +----------------------------------------+----------------------------------------------------+--------------------------+
3226 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
3227 +----------------------------------------+----------------------------------------------------+--------------------------+
3228 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3229 +----------------------------------------+----------------------------------------------------+--------------------------+
3230 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3231 +----------------------------------------+----------------------------------------------------+--------------------------+
3232 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3233 +----------------------------------------+----------------------------------------------------+--------------------------+
3234 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3235 +----------------------------------------+----------------------------------------------------+--------------------------+
3237 Table 6: Port Resource Property Parameters (Internal Networks)
3242 The property networks in the resource OS::Neutron::Port must be
3243 referenced by Neutron Network ID, a UUID value, or by the network name
3244 defined in OpenStack.
3249 When the parameter associated with the property network is referencing
3250 an “external” network, the parameter must adhere to the following naming
3251 convention in the Heat Orchestration Template
3253 - {network-role}\_net\_id for the Neutron network ID
3255 - {network-role}\_net\_name for the network name in OpenStack
3257 The parameter must be declared as type: string
3259 The parameter must not be enumerated in the Heat environment file.
3261 *Example Parameter Definition*
3263 .. code-block:: yaml
3266 {network-role}_net_id:
3268 description: Neutron UUID for the {network-role} network
3269 {network-role}_net_name:
3271 description: Neutron name for the {network-role} network
3273 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3274 that has only one subnet*
3276 In this example, the {network-role} has been defined as oam to represent
3277 an oam network and the {vm-type} has been defined as lb for load
3278 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3279 to assign IP addresses.
3281 .. code-block:: yaml
3286 description: Neutron UUID for the oam network
3290 type: OS::Neutron::Port
3291 network: { get_param: oam_net_id }
3296 When the parameter associated with the property network is referencing
3297 an “internal” network, the parameter must adhere to the following naming
3300 - int\_{network-role}\_net\_id for the Neutron network ID
3302 - int\_{network-role}\_net\_name for the network name in OpenStack
3304 The parameter must be declared as type: string
3306 The assumption is that internal networks are created in the base module.
3307 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3308 Base Module Output Parameter) to the incremental modules. In the
3309 incremental modules, it will be defined as input parameter.
3311 *Example Parameter Definition*
3313 .. code-block:: yaml
3316 int_{network-role}_net_id:
3318 description: Neutron UUID for the {network-role} network
3319 int_{network-role}_net_name:
3321 description: Neutron name for the {network-role} network
3323 Property: fixed\_ips, Map Property: subnet\_id
3324 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3326 The property fixed\_ips is used to assign IPs to a port. The Map
3327 Property subnet\_id specifies the subnet the IP is assigned from.
3329 The property fixed\_ips and Map Property subnet\_id must be used if a
3330 Cloud (i.e., DHCP) IP address assignment is being requested and the
3331 Cloud IP address assignment is targeted at a specific subnet when two or
3334 The property fixed\_ips and Map Property subnet\_id should not be used
3335 if all IP assignments are fixed, or if the Cloud IP address assignment
3336 does not target a specific subnet or there is only one subnet.
3338 Note that DHCP assignment of IP addresses is also referred to as cloud
3339 assigned IP addresses.
3341 Subnet of an External Networks
3342 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3344 When the parameter is referencing a subnet of an “external” network, the
3345 property fixed\_ips and Map Property subnet\_id parameter must adhere to
3346 the following naming convention.
3348 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3350 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3352 The parameter must be declared as type: string
3354 The parameter must not be enumerated in the Heat environment file.
3356 *Example Parameter Definition*
3358 .. code-block:: yaml
3361 {network-role}_subnet_id:
3363 description: Neutron subnet UUID for the {network-role} network
3365 {network-role}_v6_subnet_id:
3367 description: Neutron subnet UUID for the {network-role} network
3369 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3370 that has two or more subnets subnet:*
3372 In this example, the {network-role} has been defined as oam to represent
3373 an oam network and the {vm-type} has been defined as lb for load
3374 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3375 to assign IP addresses.
3377 .. code-block:: yaml
3382 description: Neutron UUID for the oam network
3386 description: Neutron subnet UUID for the oam network
3390 type: OS::Neutron::Port
3391 network: { get_param: oam_net_id }
3393 - subnet_id: { get_param: oam_subnet_id }
3395 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3396 address assigned to a network that has at least one IPv4 subnet and one
3399 In this example, the {network-role} has been defined as oam to represent
3400 an oam network and the {vm-type} has been defined as lb for load
3403 .. code-block:: yaml
3408 description: Neutron UUID for the oam network
3412 description: Neutron subnet UUID for the oam network
3416 description: Neutron subnet UUID for the oam network
3420 type: OS::Neutron::Port
3422 network: { get_param: oam_net_id }
3424 - subnet_id: { get_param: oam_subnet_id }
3425 - subnet_id: { get_param: oam_v6_subnet_id }
3430 When the parameter is referencing the subnet of an “internal” network,
3431 the property fixed\_ips and Map Property subnet\_id parameter must
3432 adhere to the following naming convention.
3434 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3436 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3438 The parameter must be declared as type: string
3440 The assumption is that internal networks are created in the base module.
3441 The Neutron subnet network ID will be passed as an output parameter
3442 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3443 the incremental modules, it will be defined as input parameter.
3445 *Example Parameter Definition*
3447 .. code-block:: yaml
3450 int_{network-role}_subnet_id:
3452 description: Neutron subnet UUID for the {network-role} network
3454 int_{network-role}_v6_subnet_id:
3456 description: Neutron subnet UUID for the {network-role} network
3458 Property: fixed\_ips, Map Property: ip\_address
3459 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3461 The property fixed\_ips is used to assign IPs to a port. The Map
3462 Property ip\_address specifies the IP address to be assigned to the
3465 The property fixed\_ips and Map Property ip\_address must be used when
3466 statically assigning one or more IP addresses to a port. This is also
3467 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3468 the IP address assignment.
3470 An IP address is assigned to a port on a VM (referenced by {vm-type})
3471 that is connected to an external network (referenced by {network-role})
3472 or internal network (referenced by int\_{network-role}).
3474 When a SDN-C IP assignment is made to a port connected to an external
3475 network, the parameter name must contain {vm-type} and {network-role}.
3477 When a SDN-C IP assignment is made to a port connected to an internal
3478 network, the parameter name must contain {vm-type} and
3479 int\_{network-role}.
3481 IP Address Assignments on External Networks
3482 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3484 When the property fixed\_ips and Map Property ip\_address is used to
3485 assign IP addresses to an external network, the parameter name is
3486 dependent on the parameter type (comma\_delimited\_list or string) and
3487 IP address type (IPv4 or IPv6).
3489 When the parameter for property fixed\_ips and Map Property ip\_address
3490 is declared type: comma\_delimited\_list, the parameter must adhere to
3491 the following naming convention
3493 - {vm-type}\_{network-role}\_ips for IPv4 address
3495 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3497 Each element in the IP list should be assigned to successive instances
3498 of {vm-type} on {network-role}.
3500 The parameter must not be enumerated in the Heat environment file.
3502 *Example Parameter Definition*
3504 .. code-block:: yaml
3508 {vm-type}_{network-role}_ips:
3509 type: comma_delimited_list
3510 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3512 {vm-type}_{network-role}_v6_ips:
3513 type: comma_delimited_list
3514 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3516 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3517 Assignments to an external network*
3519 In this example, the {network-role} has been defined as oam to represent
3520 an oam network and the {vm-type} has been defined as db for database.
3522 .. code-block:: yaml
3527 description: Neutron UUID for a oam network
3530 type: comma_delimited_list
3531 description: Fixed IPv4 assignments for db VMs on the oam network
3534 type: comma_delimited_list
3535 description: Fixed IPv6 assignments for db VMs on the oam network
3539 type: OS::Neutron::Port
3540 network: { get_param: oam_net_id }
3541 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3544 type: OS::Neutron::Port
3546 network: { get_param: oam_net_id }
3548 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3549 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3551 When the parameter for property fixed\_ips and Map Property ip\_address
3552 is declared type: string, the parameter must adhere to the following
3555 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3557 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3559 The value for {index} must start at zero (0) and increment by one.
3561 The parameter must not be enumerated in the Heat environment file.
3563 *Example Parameter Definition*
3565 .. code-block:: yaml
3568 {vm-type}_{network-role}_ip_{index}:
3570 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3572 {vm-type}_{network-role}_v6_ip_{index}:
3574 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3576 *Example: string parameters for IPv4 and IPv6 Address Assignments to an external network*
3578 In this example, the {network-role} has been defined as “oam” to
3579 represent an oam network and the {vm-type} has been defined as “db” for
3582 .. code-block:: yaml
3587 description: Neutron UUID for an OAM network
3591 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3595 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3599 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3603 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3607 type: OS::Neutron::Port
3609 network: { get_param: oam_net_id }
3610 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3613 type: OS::Neutron::Port
3615 network: { get_param: oam_net_id }
3617 - “ip_address”: {get_param: db_oam_ip_1}}]
3618 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3620 IP Address Assignment on Internal Networks
3621 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3623 When the property fixed\_ips and Map Property ip\_address is used to
3624 assign IP addresses to an internal network, the parameter name is
3625 dependent on the parameter type (comma\_delimited\_list or string) and
3626 IP address type (IPv4 or IPv6).
3628 When the parameter for property fixed\_ips and Map Property ip\_address
3629 is declared type: comma\_delimited\_list, the parameter must adhere to
3630 the following naming convention
3632 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3634 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3636 Each element in the IP list should be assigned to successive instances
3637 of {vm-type} on {network-role}.
3639 The parameter must be enumerated in the Heat environment file. Since an
3640 internal network is local to the VNF, IP addresses can be re-used at
3643 *Example Parameter Definition*
3645 .. code-block:: yaml
3649 {vm-type}_int_{network-role}_ips:
3650 type: comma_delimited_list
3651 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3653 {vm-type}_int_{network-role}_v6_ips:
3654 type: comma_delimited_list
3655 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3657 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3658 Assignments to an internal network*
3660 In this example, the {network-role} has been defined as oam\_int to
3661 represent an oam network internal to the vnf. The role oam\_int was
3662 picked to differentiate from an external oam network with a
3663 {network-role} of oam. The {vm-type} has been defined as db for
3666 .. code-block:: yaml
3671 description: Neutron UUID for the oam internal network
3674 type: comma_delimited_list
3675 description: Fixed IPv4 assignments for db VMs on the oam internal network
3677 db_int_oam_int_v6_ips:
3678 type: comma_delimited_list
3679 description: Fixed IPv6 assignments for db VMs on the oam internal network
3683 type: OS::Neutron::Port
3685 network: { get_param: int_oam_int_net_id }
3686 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3689 type: OS::Neutron::Port
3691 network: { get_param: int_oam_int_net_id }
3693 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3694 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3696 When the parameter for property fixed\_ips and Map Property ip\_address
3697 is declared type: string, the parameter must adhere to the following
3700 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3702 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3704 The value for {index} must start at zero (0) and increment by one.
3706 The parameter must be enumerated in the Heat environment file. Since an
3707 internal network is local to the VNF, IP addresses can be re-used at
3710 *Example Parameter Definition*
3712 .. code-block:: yaml
3716 {vm-type}_int_{network-role}_ip_{index}:
3718 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3720 {vm-type}_int_{network-role}_v6_ip_{index}:
3722 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3724 *Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
3726 In this example, the {network-role} has been defined as oam\_int to
3727 represent an oam network internal to the vnf. The role oam\_int was
3728 picked to differentiate from an external oam network with a
3729 {network-role} of oam. The {vm-type} has been defined as db for
3732 .. code-block:: yaml
3737 description: Neutron UUID for an OAM internal network
3741 description: Fixed IPv4 assignment for db VM on the oam_int network
3745 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3749 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3753 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3757 type: OS::Neutron::Port
3759 network: { get_param: int_oam_int_net_id }
3760 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3763 type: OS::Neutron::Port
3765 network: { get_param: int_oam_int_net_id }
3767 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3768 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3770 Property: allowed\_address\_pairs, Map Property: ip\_address
3771 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3773 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3774 allows the user to specify a mac\_address and/or ip\_address that will
3775 pass through a port regardless of subnet. This enables the use of
3776 protocols such as VRRP, which floats an IP address between two instances
3777 to enable fast data plane failover. The map property ip\_address
3778 specifies the IP address.
3780 The allowed\_address\_pairs is an optional property. It is not required.
3782 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3783 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3784 and {network-role}/int\_{network-role} combination.
3786 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3787 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3788 and {network-role}/int\_{network-role} combination.
3790 Note that the management of these IP addresses (i.e. transferring
3791 ownership between active and standby VMs) is the responsibility of the
3794 Note that these parameters are **not** intended to represent Neutron
3795 “Floating IP” resources, for which OpenStack manages a pool of public IP
3796 addresses that are mapped to specific VM ports. In that case, the
3797 individual VMs are not even aware of the public IPs, and all assignment
3798 of public IPs to VMs is via OpenStack commands. ONAP does not support
3799 Neutron-style Floating IPs.
3804 When the parameter is referencing an “external” network, the property
3805 allowed\_address\_pairs and Map Property ip\_address parameter must
3806 adhere to the following naming convention.
3808 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3810 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3812 The parameter must be declared as type: string
3814 The parameter must not be enumerated in the Heat environment file.
3816 *Example Parameter Definition*
3818 .. code-block:: yaml
3822 {vm-type}_{network-role}_floating_ip:
3824 description: VIP for {vm-type} VMs on the {network-role} network
3826 {vm-type}_{network-role}_floating_v6_ip:
3828 description: VIP for {vm-type} VMs on the {network-role} network
3832 In this example, the {network-role} has been defined as oam to represent
3833 an oam network and the {vm-type} has been defined as db for database.
3835 .. code-block:: yaml
3840 description: Neutron UUID for the oam network
3843 type: comma_delimited_list
3844 description: Fixed IPs for db VMs on the oam network
3848 description: VIP IP for db VMs on the oam network
3852 type: OS::Neutron::Port
3854 network: { get_param: oam_net_id }
3855 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
3856 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3859 type: OS::Neutron::Port
3861 network: { get_param: oam_net_id }
3862 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
3863 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3868 When the parameter is referencing an “internal” network, the property
3869 allowed\_address\_pairs and Map Property ip\_address parameter must
3870 adhere to the following naming convention.
3872 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
3874 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
3876 The parameter must be declared as type: string
3878 The parameter must be enumerated in the Heat environment file.
3880 *Example Parameter Definition*
3882 .. code-block:: yaml
3886 {vm-type}_int_{network-role}_floating_ip:
3888 description: VIP for {vm-type} VMs on the int_{network-role} network
3890 {vm-type}_int_{network-role}_floating_v6_ip:
3892 description: VIP for {vm-type} VMs on the int_{network-role} network
3894 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
3895 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3897 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
3898 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
3900 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
3901 one allowed address pair IPv6 address per {vm-type} and {network-role}
3904 If there is a need for multiple allowed address pair IPs for a given
3905 {vm-type} and {network-role} combination within a VNF, then the
3906 parameter names defined for the property fixed\_ips and Map Property
3907 ip\_address should be used with the allowed\_address\_pairs property.
3908 The examples below illustrate this.
3910 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
3912 In this example, there are two administrative VM pairs. Each pair has
3913 one VIP. The {network-role} has been defined as oam to represent an oam
3914 network and the {vm-type} has been defined as admin for an
3917 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
3918 VIP, [admin\_oam\_ips,2]
3920 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
3921 VIP, [admin\_oam\_ips,5]
3923 .. code-block:: yaml
3928 description: Neutron UUID for the oam network
3930 type: comma_delimited_list
3931 description: Fixed IP assignments for admin VMs on the oam network
3936 type: OS::Neutron::Port
3938 network: { get_param: oam_net_id }
3939 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
3940 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3943 type: OS::Neutron::Port
3945 network: { get_param: oam_net_id }
3946 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
3947 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3950 type: OS::Neutron::Port
3952 network: { get_param: oam_net_id }
3953 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
3954 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3957 type: OS::Neutron::Port
3959 network: { get_param: oam_net_id }
3960 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
3961 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3963 *Example: A VNF has two load balancers. The pair of load balancers share
3966 In this example, there is one load balancer pairs. The pair has two
3967 VIPs. The {network-role} has been defined as oam to represent an oam
3968 network and the {vm-type} has been defined as lb for a load balancer VM.
3970 .. code-block:: yaml
3974 type: OS::Neutron::Port
3976 network: { get_param: oam_net_id }
3977 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
3978 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3981 type: OS::Neutron::Port
3983 network: { get_param: oam_net_id }
3984 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
3985 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3987 As a general rule, provide the fixed IPs for the VMs indexed first in
3988 the CDL and then the VIPs as shown in the examples above.
3990 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
3991 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3993 The following items must be taken into consideration when designing Heat
3994 Orchestration Templates that expect ONAP’s SDN-C to assign
3995 allowed\_address\_pair IP addresses via automation.
3997 The VMs must be of the same {vm-type}.
3999 The VMs must be created in the same module (base or incremental).
4001 Resource Property “name”
4002 ------------------------
4004 The parameter naming convention of the property name for the resource
4005 OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
4007 This section provides the requirements how the property name for non
4008 OS::Nova::Server resources must be defined when the property is used.
4009 Not all resources require the property name (e.g., it is optional) and
4010 some resources do not support the property.
4012 When the property name for a non OS::Nova::Server resources is defined
4013 in a Heat Orchestration Template, the intrinsic function str\_replace
4014 must be used in conjunction with the ONAP supplied metadata parameter
4015 vnf\_name to generate a unique value. This prevents the enumeration of a
4016 unique value for the property name in a per instance environment file.
4020 - In most cases, only the use of the metadata value vnf\_name is
4021 required to create a unique property name
4023 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4024 may also be used in the str\_replace construct to generate a unique
4025 name when the vnf\_name does not provide uniqueness
4027 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4029 .. code-block:: yaml
4033 type: OS::Neutron::SecurityGroup
4035 description: vDNS security group
4038 template: VNF_NAME_sec_grp_DNS
4040 VNF_NAME: {get_param: vnf_name}
4044 *Example: Property name for resource* OS::Cinder::Volume
4046 .. code-block:: yaml
4050 type: OS::Cinder::Volume
4052 description: Cinder Volume
4055 template: VNF_NAME_STACK_NAME_dns_volume
4057 VNF_NAME: {get_param: vnf_name}
4058 STACK_NAME: { get_param: 'OS::stack_name' }
4061 Contrail Issue with Values for the Property Name
4062 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4064 The Contrail GUI has a limitation displaying special characters. The
4065 issue is documented in
4066 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4067 recommended that special characters be avoided. However, if special
4068 characters must be used, note that for the following resources:
4082 the only special characters supported are:
4084 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4086 ONAP Output Parameter Names
4087 ---------------------------
4089 ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
4091 ONAP Base Module Output Parameters:
4092 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4094 ONAP Base Module Output Parameters do not have an explicit naming
4095 convention. The parameter name must contain {vm-type} and {network-role}
4098 ONAP Volume Template Output Parameters:
4099 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4101 ONAP Base Module Output Parameters do not have an explicit naming
4102 convention. The parameter name must contain {vm-type} when appropriate.
4104 Predefined Output Parameters
4105 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4107 ONAP currently defines one predefined output parameter the OAM
4108 Management IP Addresses.
4110 OAM Management IP Addresses
4111 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
4113 A VNF may have a management interface for application controllers to
4114 interact with and configure the VNF. Typically, this will be via a
4115 specific VM that performs a VNF administration function. The IP address
4116 of this interface must be captured and inventoried by ONAP. The IP
4117 address might be a VIP if the VNF contains an HA pair of management VMs,
4118 or may be a single IP address assigned to one VM.
4120 The Heat template may define either (or both) of the following Output
4121 parameters to identify the management IP address.
4123 - oam\_management\_v4\_address
4125 - oam\_management\_v6\_address
4129 - The use of this output parameters are optional.
4131 - The Management IP Address should be defined only once per VNF, so it
4132 must only appear in one Module template
4134 - If a fixed IP for the admin VM is passed as an input parameter, it
4135 may be echoed in the output parameters. In this case, a IPv4 and/or
4136 IPv6 parameter must be defined in the parameter section of the YAML
4137 Heat template. The parameter maybe named oam\_management\_v4\_address
4138 and/or oam\_management\_v6\_address or may be named differently.
4140 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4141 from the resource attributes. In this case,
4142 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4143 not be defined in the parameter section of the YAML Heat template.
4145 *Example: SDN-C Assigned IP Address echoed as*
4146 oam\_management\_v4\_address
4148 .. code-block:: yaml
4153 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4157 admin_oam_net_0_port:
4158 type: OS::Neutron::Port
4162 template: VNF_NAME_admin_oam_net_0_port
4164 VNF_NAME: {get_param: vnf_name}
4165 network: { get_param: oam_net_id }
4166 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4167 security_groups: [{ get_param: security_group }]
4170 type: OS::Nova::Server
4172 name: { get_param: admin_names }
4173 image: { get_param: admin_image_name }
4174 flavor: { get_param: admin_flavor_name }
4175 availability_zone: { get_param: availability_zone_0 }
4177 - port: { get_resource: admin_oam_net_0_port }
4179 vnf_id: { get_param: vnf_id }
4180 vf_module_id: { get_param: vf_module_id }
4181 vnf_name: {get_param: vnf_name }
4183 oam_management_v4_address:
4184 value: {get_param: admin_oam_ip_0 }
4186 *Example: Cloud Assigned IP Address output as*
4187 oam\_management\_v4\_address
4189 .. code-block:: yaml
4194 admin_oam_net_0_port:
4195 type: OS::Neutron::Port
4199 template: VNF_NAME_admin_oam_net_0_port
4201 VNF_NAME: {get_param: vnf_name}
4202 network: { get_param: oam_net_id }
4203 security_groups: [{ get_param: security_group }]
4206 type: OS::Nova::Server
4208 name: { get_param: admin_names }
4209 image: { get_param: admin_image_name }
4210 flavor: { get_param: admin_flavor_name }
4211 availability_zone: { get_param: availability_zone_0 }
4213 - port: { get_resource: admin_oam_net_0_port }
4215 vnf_id: { get_param: vnf_id }
4216 vf_module_id: { get_param: vf_module_id }
4217 vnf_name: {get_param: vnf_name }
4220 oam_management_v4_address:
4221 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4223 Contrail Resource Parameters
4224 ----------------------------
4226 ONAP requires the parameter names of certain Contrail Resources to
4227 follow specific naming conventions. This section provides these
4230 Contrail Network Parameters
4231 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4233 Contrail based resources may require references to a Contrail network
4234 using the network FQDN.
4239 When the parameter associated with the Contrail Network is referencing
4240 an “external” network, the parameter must adhere to the following naming
4241 convention in the Heat Orchestration Template
4243 - {network-role}\_net\_fqdn
4245 The parameter must be declared as type: string
4247 The parameter must not be enumerated in the Heat environment file.
4249 *Example: Parameter declaration*
4251 .. code-block:: yaml
4254 {network-role}_net_fqdn:
4256 description: Contrail FQDN for the {network-role} network
4258 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4259 Reference to a Network FQDN.*
4261 In this example, the {network-role} has been defined as oam to represent
4262 an oam network and the {vm-type} has been defined as fw for firewall.
4263 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4264 virtual\_network\_refs references a contrail network FQDN.
4266 .. code-block:: yaml
4269 type: OS::ContrailV2::VirtualMachineInterface
4273 template: VM_NAME_virtual_machine_interface_1
4275 VM_NAME: { get_param: fw_name_0 }
4276 virtual_machine_interface_properties:
4277 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4278 virtual_network_refs:
4279 - get_param: oam_net_fqdn
4280 security_group_refs:
4281 - get_param: fw_sec_grp_id
4283 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4284 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4286 The parameter associated with the resource
4287 OS::ContrailV2::InterfaceRouteTable property
4288 interface\_route\_table\_routes, map property
4289 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4292 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4293 in the Heat Orchestration Template.
4295 The parameter must be declared as type: json
4297 The parameter supports IP addresses in the format:
4299 1. Host IP Address (e.g., 10.10.10.10)
4301 2. CIDR Notation format (e.g., 10.0.0.0/28)
4303 The parameter must not be enumerated in the Heat environment file.
4305 *Example Parameter Definition*
4307 .. code-block:: yaml
4310 {vm-type}_{network-role}_route_prefixes:
4312 description: JSON list of Contrail Interface Route Table route prefixes
4316 .. code-block:: yaml
4321 description: Unique name for this VF instance
4322 fw_int_fw_route_prefixes:
4324 description: prefix for the ServiceInstance InterfaceRouteTable
4325 int_fw_dns_trusted_interface_type:
4327 description: service_interface_type for ServiceInstance
4330 type: OS::ContrailV2::InterfaceRouteTable
4331 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4335 template: VNF_NAME_interface_route_table
4337 VNF_NAME: { get_param: vnf_name }
4338 interface_route_table_routes:
4339 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4340 service_instance_refs:
4341 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4342 service_instance_refs_data:
4343 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4345 Parameter Names in Contrail Resources
4346 -------------------------------------
4348 Contrail Heat resource properties will use, when appropriate, the same
4349 naming convention as OpenStack Heat resources. For example, the resource
4350 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4351 convention is identical to properties in OS::Neutron::Port.
4353 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4354 instance\_ip\_address*
4356 The property instance\_ip\_address uses the same parameter naming
4357 convention as the property fixed\_ips and Map Property ip\_address in
4358 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4359 Address. The {network-role} has been defined as oam\_protected to
4360 represent an oam protected network and the {vm-type} has been defined as
4363 .. code-block:: yaml
4365 CMD_FW_OAM_PROTECTED_RII:
4366 type: OS::ContrailV2::InstanceIp
4368 - FW_OAM_PROTECTED_RVMI
4370 virtual_machine_interface_refs:
4371 - get_resource: FW_OAM_PROTECTED_RVMI
4372 virtual_network_refs:
4373 - get_param: oam_protected_net_fqdn
4374 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4376 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4379 The property instance\_ip\_address uses the same parameter naming
4380 convention as the property fixed\_ips and Map Property subnet\_id in
4381 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4382 Address. The {network-role} has been defined as “oam\_protected” to
4383 represent an oam protected network and the {vm-type} has been defined as
4386 .. code-block:: yaml
4388 CMD_FW_SGI_PROTECTED_RII:
4389 type: OS::ContrailV2::InstanceIp
4391 - FW_OAM_PROTECTED_RVMI
4393 virtual_machine_interface_refs:
4394 - get_resource: FW_OAM_PROTECTED_RVMI
4395 virtual_network_refs:
4396 - get_param: oam_protected_net_fqdn
4397 subnet_uuid: { get_param: oam_protected_subnet_id }
4399 Cinder Volume Templates
4400 -----------------------
4402 ONAP supports the independent deployment of a Cinder volume via separate
4403 Heat Orchestration Templates, the Cinder Volume module. This allows the
4404 volume to persist after VNF deletion so that they can be reused on
4405 another instance (e.g., during a failover activity).
4407 A Base Module or Incremental Module may have a corresponding volume
4408 module. Use of separate volume modules is optional. A Cinder volume may
4409 be embedded within the Base Module or Incremental Module if persistence
4412 If a VNF Base Module or Incremental Module has an independent volume
4413 module, the scope of volume templates must be 1:1 with Base module or
4414 Incremental module. A single volume module must create only the volumes
4415 required by a single Incremental module or Base module.
4417 The following rules apply to independent volume Heat templates:
4419 - Cinder volumes must be created in a separate Heat Orchestration
4420 Template from the Base Module or Incremental Module.
4422 - A single Cinder volume module must include all Cinder volumes
4423 needed by the Base/Incremental module.
4425 - The volume template must define “outputs” for each Cinder volume
4426 resource universally unique identifier (UUID) (i.e. ONAP Volume
4427 Template Output Parameters).
4429 - The VNF Incremental Module or Base Module must define input
4430 parameters that match each Volume output parameter (i.e., ONAP Volume
4431 Template Output Parameters).
4433 - ONAP will supply the volume template outputs automatically to the
4434 bases/incremental template input parameters.
4436 - Volume modules may utilize nested Heat templates.
4438 *Examples: Volume Template*
4440 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4441 creates an independent Cinder volume for a VM in the module
4442 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4443 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4444 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4445 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4446 output statement and provides the value to the incremental module.
4448 Note that the example below is not a complete Heat Orchestration
4449 Template. The {vm-type} has been defined as “lb” for load balancer
4451 incremental\_volume.yaml
4453 .. code-block:: yaml
4464 type: OS::Cinder::Volume
4468 template: VNF_NAME_volume_0
4470 VNF_NAME: { get_param: vnf_name }
4471 size: {get_param: dns_volume_size_0}
4476 value: {get_resource: dns_volume_0}
4482 .. code-block:: yaml
4493 type: OS::Nova::Server
4495 name: {get_param: dns_name_0}
4500 type: OS::Cinder::VolumeAttachment
4502 instance_uuid: { get_resource: lb_0 }
4503 volume_id: { get_param: lb_volume_id_0 }
4505 ONAP Support of Environment Files
4506 ---------------------------------
4508 The use of an environment file in OpenStack is optional. In ONAP, it is
4509 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
4510 corresponding environment file, even if no parameters are required to be
4513 (Note that ONAP, the open source version of ONAP, does not
4514 programmatically enforce the use of an environment file.)
4516 A Base Module Heat Orchestration Template must have a corresponding
4519 An Incremental Module Heat Orchestration Template must have a
4520 corresponding environment file.
4522 A Cinder Volume Module Heat Orchestration Template must have a
4523 corresponding environment file.
4525 A nested heat template must not have an environment file; OpenStack does
4528 The environment file must contain parameter values for the ONAP
4529 Orchestration Constants and VNF Orchestration Constants. These
4530 parameters are identical across all instances of a VNF type, and
4531 expected to change infrequently. The ONAP Orchestration Constants are
4532 associated with OS::Nova::Server image and flavor properties (See
4533 `Property: image`_ and `Property: flavor`_). Examples of VNF Orchestration Constants are the networking
4534 parameters associated with an internal network (e.g., private IP ranges)
4535 and Cinder volume sizes.
4537 The environment file must not contain parameter values for parameters
4538 that are instance specific (ONAP Orchestration Parameters, VNF
4539 Orchestration Parameters). These parameters are supplied to the Heat by
4540 ONAP at orchestration time.
4542 SDC Treatment of Environment Files
4543 ----------------------------------
4545 Parameter values enumerated in the environment file are used by SDC as
4546 the default value. However, the SDC user may use the SDC GUI to
4547 overwrite the default values in the environment file.
4549 SDC generates a new environment file for distribution to MSO based on
4550 the uploaded environment file and the user provided GUI updates. The
4551 user uploaded environment file is discarded when the new file is
4552 created. Note that if the user did not change any values via GUI
4553 updates, the SDC generated environment file will contain the same values
4554 as the uploaded file.
4556 Use of Environment Files when using OpenStack “heat stack-create” CLI
4557 ---------------------------------------------------------------------
4559 When ONAP is instantiating the Heat Orchestration Template, certain
4560 parameter must not be enumerated in the environment file. This document
4561 provides the details of what parameters should not be enumerated.
4563 If the Heat Orchestration Template is to be instantiated from the
4564 OpenStack Command Line Interface (CLI) using the command “heat
4565 stack-create”, all parameters must be enumerated in the environment
4568 Heat Template Constructs
4569 ------------------------
4571 Nested Heat Templates
4572 ---------------------
4574 ONAP supports nested Heat templates per the OpenStack specifications.
4575 Nested templates may be suitable for larger VNFs that contain many
4576 repeated instances of the same VM type(s). A common usage pattern is to
4577 create a nested template for each {vm-type} along with its supporting
4578 resources. The VNF module may then reference these component templates
4579 either statically by repeated definition or dynamically by using the
4580 resource OS::Heat::ResourceGroup.
4582 Nested Heat Template Requirements
4583 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4585 ONAP supports nested Heat Orchestration Templates. A Base Module,
4586 Incremental Module, and Cinder Volume Module may use nested heat.
4588 A Heat Orchestration Template may reference the nested heat statically
4589 by repeated definition.
4591 A Heat Orchestration Template may reference the nested heat dynamically
4592 using the resource OS::Heat::ResourceGroup.
4594 A Heat Orchestration template must have no more than three levels of
4595 nesting. ONAP supports a maximum of three levels.
4597 Nested heat templates must be referenced by file name. The use of
4598 resource\_registry in the environment file is not supported and must not
4601 A nested heat yaml file must have a unique file names within the scope
4604 ONAP does not support a directory hierarchy for nested templates. All
4605 templates must be in a single, flat directory (per VNF)
4607 A nested heat template may be used by any module within a given VNF.
4611 - Constrains must not be defined for any parameter enumerated in a
4612 nested heat template.
4614 - All parameters defined in nested heat must be passed in as properties
4615 of the resource calling the nested yaml file.
4617 - When OS::Nova::Server metadata parameters are past into a nested heat
4618 template, the parameter names must not change
4620 - With nested templates, outputs are required to expose any resource
4621 properties of the child templates to the parent template. Those would
4622 not explicitly be declared as parameters but simply referenced as
4623 get\_attribute targets against the “parent” resource.
4625 Nested Heat Template Example: Static
4626 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4630 .. code-block:: yaml
4636 dns_image_name: { get_param: dns_image_name }
4637 dns_flavor_name: { get_param: dns_flavor_name }
4638 availability_zone: { get_param: availability_zone_0 }
4639 security_group: { get_param: DNS_shared_sec_grp_id }
4640 oam_net_id: { get_param: oam_protected_net_id }
4641 dns_oam_ip: { get_param: dns_oam_ip_0 }
4642 dns_name: { get_param: dns_name_0 }
4643 vnf_name: { get_param: vnf_name }
4644 vnf_id: { get_param: vnf_id }
4645 vf_module_id: {get_param: vf_module_id}
4650 dns_image_name: { get_param: dns_image_name }
4651 dns_flavor_name: { get_param: dns_flavor_name }
4652 availability_zone: { get_param: availability_zone_1 }
4653 security_group: { get_param: DNS_shared_sec_grp_id }
4654 oam_net_id: { get_param: oam_protected_net_id }
4655 dns_oam_ip: { get_param: dns_oam_ip_1 }
4656 dns_name: { get_param: dns_name_1 }
4657 vnf_name: { get_param: vnf_name }
4658 vnf_id: { get_param: vnf_id }
4659 vf_module_id: {get_param: vf_module_id}
4663 .. code-block:: yaml
4666 type: OS::Neutron::Port
4670 template: VNF_NAME_dns_oam_port
4672 VNF_NAME: {get_param: vnf_name}
4673 network: { get_param: oam_net_id }
4674 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4675 security_groups: [{ get_param: security_group }]
4678 type: OS::Nova::Server
4680 name: { get_param: dns_names }
4681 image: { get_param: dns_image_name }
4682 flavor: { get_param: dns_flavor_name }
4683 availability_zone: { get_param: availability_zone }
4685 - port: { get_resource: dns_oam_0_port }
4687 vnf_id: { get_param: vnf_id }
4688 vf_module_id: { get_param: vf_module_id }
4689 vnf_name {get_param: vnf_name }
4691 Use of Heat ResourceGroup
4692 ~~~~~~~~~~~~~~~~~~~~~~~~~
4694 The OS::Heat::ResourceGroup is a useful Heat element for creating
4695 multiple instances of a given resource or collection of resources.
4696 Typically it is used with a nested Heat template, to create, for
4697 example, a set of identical OS::Nova::Server resources plus their
4698 related OS::Neutron::Port resources via a single resource in a master
4701 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4702 template that creates multiple instances of the same VM type.
4704 However, there are important caveats to be aware of:
4706 ResourceGroup does not deal with structured parameters
4707 (comma-delimited-list and json) as one might typically expect. In
4708 particular, when using a list-based parameter, where each list element
4709 corresponds to one instance of the ResourceGroup, it is not possible to
4710 use the intrinsic “loop variable” %index% in the ResourceGroup
4713 For instance, the following is **not** valid Heat for ResourceGroup:
4715 .. code-block:: yaml
4717 type: OS::Heat::ResourceGroup
4719 type: my_nested_vm_template.yaml
4721 name: {get_param: [vm_name_list, %index%]}
4723 Although this appears to use the nth entry of the vm\_name\_list list
4724 for the nth element of the ResourceGroup, it will in fact result in a
4725 Heat exception. When parameters are provided as a list (one for each
4726 element of a ResourceGroup), you must pass the complete parameter to the
4727 nested template along with the current index as separate parameters.
4729 Below is an example of an **acceptable** Heat Syntax for a
4732 .. code-block:: yaml
4734 type: OS::Heat::ResourceGroup
4736 type: my_nested_vm_template.yaml
4738 names: {get_param: vm_name_list}
4741 You can then reference within the nested template as:
4743 { get\_param: [names, {get\_param: index} ] }
4745 ResourceGroup Property count
4746 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4748 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4749 (even if the value is one) and that the value must be enumerated in the
4750 environment file. This is required for ONAP to build the TOSCA model for
4753 .. code-block:: yaml
4755 type: OS::Heat::ResourceGroup
4757 count: { get_param: count }
4760 type: my_nested_vm_template.yaml
4762 names: {get_param: vm_name_list}
4765 Availability Zone and ResourceGroups
4766 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4768 The resource OS::Heat::ResourceGroup and the property availability\_zone
4769 has been an “issue” with a few VNFs since ONAP only supports
4770 availability\_zone as a string parameter and not a
4771 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4772 to create Virtual Machines in more than one availability zone.
4774 There are numerous solutions to this issue. Below are two suggested
4777 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4778 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4779 availability\_zones by using the intrinsic function list\_join.
4781 .. code-block:: yaml
4784 type: OS::Heat::ResourceGroup
4786 count: { get_param: node_count }
4792 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4796 .. code-block:: yaml
4799 avaialability_zones:
4800 type: comma_delimited_list
4805 type: OS::Nova::Server
4807 name: { get_param: [ dns_names, get_param: index ] }
4808 image: { get_param: dns_image_name }
4809 flavor: { get_param: dns_flavor_name }
4810 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
4813 **Option 2:** Create a resource group per availability zone. A separate
4814 OS::Heat::ResourceGroup is created for each availability zone.
4819 Heat templates *should not* reference any HTTP-based resource
4820 definitions, any HTTP-based nested configurations, or any HTTP-based
4823 - During orchestration, ONAP *should not* retrieve any such resources
4824 from external/untrusted/unknown sources.
4826 - VNF images should not contain such references in user-data or other
4827 configuration/operational scripts that are specified via Heat or
4828 encoded into the VNF image itself.
4830 *Note:* HTTP-based references are acceptable if the HTTP-based reference
4831 is accessing information with the VM private/internal network.
4833 Heat Files Support (get\_file)
4834 ------------------------------
4836 Heat Templates may contain the inclusion of text files into Heat
4837 templates via the Heat get\_file directive. This may be used, for
4838 example, to define a common “user-data” script, or to inject files into
4839 a VM on startup via the “personality” property.
4841 Support for Heat Files is subject to the following limitations:
4843 - The get\_files targets must be referenced in Heat templates by file
4844 name, and the corresponding files should be delivered to ONAP along
4845 with the Heat templates.
4847 - URL-based file retrieval must not be used; it is not supported.
4849 - The included files must have unique file names within the scope of
4852 - ONAP does not support a directory hierarchy for included files.
4854 - All files must be in a single, flat directory per VNF.
4856 - Included files may be used by all Modules within a given VNF.
4858 - get\_file directives may be used in both non-nested and nested
4864 When Nova Servers are created via Heat templates, they may be passed a
4865 “keypair” which provides an ssh key to the ‘root’ login on the newly
4866 created VM. This is often done so that an initial root key/password does
4867 not need to be hard-coded into the image.
4869 Key pairs are unusual in OpenStack, because they are the one resource
4870 that is owned by an OpenStack User as opposed to being owned by an
4871 OpenStack Tenant. As a result, they are usable only by the User that
4872 created the keypair. This causes a problem when a Heat template attempts
4873 to reference a keypair by name, because it assumes that the keypair was
4874 previously created by a specific ONAP user ID.
4876 When a keypair is assigned to a server, the SSH public-key is
4877 provisioned on the VMs at instantiation time. They keypair itself is not
4878 referenced further by the VM (i.e. if the keypair is updated with a new
4879 public key, it would only apply to subsequent VMs created with that
4882 Due to this behavior, the recommended usage of keypairs is in a more
4883 generic manner which does not require the pre-requisite creation of a
4884 keypair. The Heat should be structured in such a way as to:
4886 - Pass a public key as a parameter value instead of a keypair name
4888 - Create a new keypair within the VNF Heat templates (in the base
4889 module) for use within that VNF
4891 By following this approach, the end result is the same as pre-creating
4892 the keypair using the public key – i.e., that public key will be
4893 provisioned in the new VM. However, this recommended approach also makes
4894 sure that a known public key is supplied (instead of having OpenStack
4895 generate a public/private pair to be saved and tracked outside of ONAP).
4896 It also removes any access/ownership issues over the created keypair.
4898 The public keys may be enumerated as a VNF Orchestration Constant in the
4899 environment file (since it is public, it is not a secret key), or passed
4900 at run-time as instance-specific parameters. ONAP will never
4901 automatically assign a public/private key pair.
4903 *Example (create keypair with an existing ssh public-key for {vm-type}
4904 of lb (for load balancer)):*
4906 .. code-block:: yaml
4916 type: OS::Nova::Keypair
4920 template: VNF_NAME_key_pair
4922 VNF_NAME: { get_param: vnf_name }
4923 public_key: {get_param: lb_ssh_public_key}
4924 save_private_key: false
4929 OpenStack allows a tenant to create Security groups and define rules
4930 within the security groups.
4932 Security groups, with their rules, may either be created in the Heat
4933 Orchestration Template or they can be pre-created in OpenStack and
4934 referenced within the Heat template via parameter(s). There can be a
4935 different approach for security groups assigned to ports on internal
4936 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
4937 there can be a common security group across all VMs for a specific
4938 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
4941 Anti-Affinity and Affinity Rules
4942 --------------------------------
4944 Anti-affinity or affinity rules are supported using normal OpenStack
4945 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
4946 created for each VM type to prevent them from residing on the same host,
4947 but they can be applied to multiple VM types to extend the
4948 affinity/anti-affinity across related VM types as well.
4952 In this example, the {network-role} has been defined as oam to represent
4953 an oam network and the {vm-type} have been defined as lb for load
4954 balancer and db for database.
4956 .. code-block:: yaml
4960 type: OS::Nova::ServerGroup
4965 $vnf_name: {get_param: vnf_name}
4966 template: $vnf_name-server_group1
4971 type: OS::Nova::ServerGroup
4976 $vnf_name: {get_param: vnf_name}
4977 template: $vnf_name-server_group2
4982 type: OS::Nova::Server
4986 group: {get_resource: db_server_group}
4989 type: OS::Nova::Server
4993 group: {get_resource: db_server_group}
4996 type: OS::Nova::Server
5000 group: {get_resource: lb_server_group}
5002 Resource Data Synchronization
5003 -----------------------------
5005 For cases where synchronization is required in the orchestration of Heat
5006 resources, two approaches are recommended:
5008 - Standard Heat depends\_on property for resources
5010 - Assures that one resource completes before the dependent resource
5013 - Definition of completeness to OpenStack may not be sufficient
5014 (e.g., a VM is considered complete by OpenStack when it is ready
5015 to be booted, not when the application is up and running).
5017 - Use of Heat Notifications
5019 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5022 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5024 - Dependent resource define depends\_on in the
5025 OS::Heat::WaitCondition resource.
5027 *Example: “depends\_on” case*
5029 In this example, the {network-role} has been defined as oam to represent
5030 an oam network and the {vm-type} has been defined as oam to represent an
5033 .. code-block:: yaml
5037 type: OS::Nova::Server
5039 name: {get_param: [oam_ names, 0]}
5040 image: {get_param: oam_image_name}
5041 flavor: {get_param: oam_flavor_name}
5042 availability_zone: {get_param: availability_zone_0}
5044 - port: {get_resource: oam01_port_0}
5045 - port: {get_resource: oam01_port_1}
5047 scheduler_hints: {group: {get_resource: oam_servergroup}}
5048 user_data_format: RAW
5051 type: OS::Neutron::Port
5053 network: {get_resource: oam_net_name}
5054 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5055 security_groups: [{get_resource: oam_security_group}]
5058 type: OS::Neutron::Port
5060 network: {get_param: oam_net_name}
5061 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5062 security_groups: [{get_resource: oam_security_group}]
5064 oam_01_vol_attachment:
5065 type: OS::Cinder::VolumeAttachment
5066 depends_on: oam_server_01
5068 volume_id: {get_param: oam_vol_1}
5069 mountpoint: /dev/vdb
5070 instance_uuid: {get_resource: oam_server_01}
5075 VNF/VM parameters may include availability zone IDs for VNFs that
5076 require high availability.
5078 The Heat must comply with the following requirements to specific
5079 availability zone IDs:
5081 - The Heat template should spread Nova and Cinder resources across the
5082 availability zones as desired
5084 Post Orchestration & VNF Configuration
5085 --------------------------------------
5087 Heat templates should contain a minimum amount of post-orchestration
5088 configuration data. For instance, *do not* embed complex user-data
5089 scripts in the template with large numbers of configuration parameters
5090 to the Heat template.
5092 - VNFs may provide configuration APIs for use after VNF creation. Such
5093 APIs will be invoked via application and/or SDN controllers.
5095 *Note:* It is important to follow this convention to the extent possible
5096 even in the short-term as of the long-term direction.
5098 c. VNFM Driver Develop Steps
5099 ==============================
5101 Aid to help the VNF vendors to fasten the integration with VF-C via
5102 special VNFM, ONAP provides the documents. In this chapter, the
5103 develop steps for VNF vendors will be introduced.
5105 First, using the VNF SDK tools to design the VNF with TOSCA model and
5106 output the VNF TOSCA package. The VNF package can be validated, and
5109 Second, the VNF vendor should provide special VNFM driver in ONAP, which
5110 is a micro service and in duty of translation interface from VF-C to
5111 special VNFM. The interfaces of special VNFM are provided by
5112 the VNF vendors themselves.
5114 d. Create Special VNFM Adaptor Mircoservice
5115 ============================================
5117 Some vnfs are managed by special VNFM. Before adding special VNFM to ONAP, a
5118 special VNFM adaptor must be added to ONAP implementing the interface of the special VNFM.
5120 A special VNFM adaptor is a micro service with unique name and an appointed
5121 port, when started up, it must be automatically registered to MSB(Micro server
5122 bus),following describes an example RESTful of registering to MSB:
5124 POST /api/microservices/v1/services
5128 "serviceName": "catalog",
5132 "url": "/api/catalog/v1",
5142 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob