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.
88 Figure 1: Structural Elements of Service Template and their Relations
90 TOSCA Modeling Principles & Data Model
91 --------------------------------------
93 This section describing TOSCA modeling principles and data model for
94 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
95 V1.0], or new type based on ETSI NFV requirements, etc.
97 VNF Descriptor Template
98 -----------------------
100 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
101 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
102 Links, External Connection Points, Scaling Aspects, Instantiation Levels
103 and Deployment Flavours.
105 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
106 represents the contract & interface of a VNF and ensures the
107 interoperability across the NFV functional blocks.
109 The main parts of the VNFD are the following:
111 - VNF topology: it is modeled in a cloud agnostic way using virtualized
112 containers and their connectivity. Virtual Deployment Units (VDU)
113 describe the capabilities of the virtualized containers, such as
114 virtual CPU, RAM, disks; their connectivity is modeled with VDU
115 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
116 and VNF External Connection Point Descriptors (VnfExternalCpd);
118 - VNF deployment aspects: they are described in one or more deployment
119 flavours, including instantiation levels, supported LCM operations,
120 VNF LCM operation configuration parameters, placement constraints
121 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
122 and scaling aspect for horizontal scaling.
124 The following table defines the TOSCA Type “derived from” values that
125 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
126 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
128 +-----------------------------------------+---------------------------------------+-----------------------+
129 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
131 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
132 +=========================================+=======================================+=======================+
133 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
134 +-----------------------------------------+---------------------------------------+-----------------------+
135 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
136 +-----------------------------------------+---------------------------------------+-----------------------+
137 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
138 +-----------------------------------------+---------------------------------------+-----------------------+
139 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
140 +-----------------------------------------+---------------------------------------+-----------------------+
141 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
142 +-----------------------------------------+---------------------------------------+-----------------------+
143 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
144 +-----------------------------------------+---------------------------------------+-----------------------+
145 | Virtual Storage | | |
146 +-----------------------------------------+---------------------------------------+-----------------------+
147 | Virtual Compute | | |
148 +-----------------------------------------+---------------------------------------+-----------------------+
149 | Software Image | | |
150 +-----------------------------------------+---------------------------------------+-----------------------+
151 | Deployment Flavour | | |
152 +-----------------------------------------+---------------------------------------+-----------------------+
153 | Scaling Aspect | | |
154 +-----------------------------------------+---------------------------------------+-----------------------+
155 | Element Group | | |
156 +-----------------------------------------+---------------------------------------+-----------------------+
157 | Instantiation Level | | |
158 +-----------------------------------------+---------------------------------------+-----------------------+
160 +--------------------------------------------------------------------+
161 | +--------------------------------------------------------------+ |
162 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
164 | | description: VNFD TOSCA file demo | |
168 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
170 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
172 | | | **node\_types: | |
173 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
174 | | derived\_from:** tosca.nodes.nfv.VNF | |
175 | | | **requirements: | |
176 | | **- **sriov\_plane: | |
177 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
178 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
179 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
180 | +--------------------------------------------------------------+ |
181 +====================================================================+
182 +--------------------------------------------------------------------+
187 1. SR-IOV Passthrought
189 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
192 +------------------------------------------------+
201 | tosca\_name: SRIOV\_Port |
205 | virtual\_network\_interface\_requirements: |
209 | support\_mandatory: false |
211 | description: sriov |
219 | description: sriov port |
221 | layer\_protocol: ipv4 |
225 | - virtual\_binding: |
227 | capability: virtual\_binding |
233 | type: tosca.relationships.nfv.VirtualBindsTo |
237 | node: tosca.nodes.Root |
239 | type: tosca.nodes.nfv.VduCpd |
241 | substitution\_mappings: |
251 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
252 +------------------------------------------------+
256 Definitions of mem\_page\_size as one property shall be added to
257 Properties and set the value to large if one VDU node supports
258 huagepages. Here is an example.
260 +----------------------------------+
269 | tosca\_name: Huge\_pages\_demo |
273 | mem\_page\_size:large |
274 +==================================+
275 +----------------------------------+
279 Likewise, we shall add definitions of numa to
280 requested\_additional\_capabilities if we wand VUD nodes to support
281 NUMA. Here is an example.
283 +-------------------------------------------------+
284 | topology\_template: |
292 | virtual\_compute: |
298 | numa\_enabled: true |
300 | virtual\_mem\_size: 2 GB |
302 | requested\_additional\_capabilities: |
306 | support\_mandatory: true |
308 | requested\_additional\_capability\_name: numa |
310 | target\_performance\_parameters: |
312 | hw:numa\_nodes: "2" |
314 | hw:numa\_cpus.0: "0,1" |
316 | hw:numa\_mem.0: "1024" |
318 | hw:numa\_cpus.1: "2,3,4,5" |
320 | hw:numa\_mem.1: "1024" |
321 +-------------------------------------------------+
325 Definitions of Hyper-Theading are necessary as one of
326 requested\_additional\_capabilities of one VUD node if that node
327 supports Hyper-Theading. Here is an example.
329 +-------------------------------------------------------------+
330 | topology\_template: |
338 | virtual\_compute: |
344 | numa\_enabled: true |
346 | virtual\_mem\_size: 2 GB |
348 | requested\_additional\_capabilities: |
350 | hyper\_threading: |
352 | support\_mandatory: true |
354 | requested\_additional\_capability\_name: hyper\_threading |
356 | target\_performance\_parameters: |
358 | hw:cpu\_sockets : "2" |
360 | hw:cpu\_threads : "2" |
362 | hw:cpu\_cores : "2" |
364 | hw:cpu\_threads\_policy: "isolate" |
365 +-------------------------------------------------------------+
369 Definitions of ovs\_dpdk are necessary as one of
370 requested\_additional\_capabilities of one VUD node if that node
371 supports dpdk. Here is an example.
373 +------------------------------------------------------+
374 | topology\_template: |
382 | virtual\_compute: |
388 | numa\_enabled: true |
390 | virtual\_mem\_size: 2 GB |
392 | requested\_additional\_capabilities: |
396 | support\_mandatory: true |
398 | requested\_additional\_capability\_name: ovs\_dpdk |
400 | target\_performance\_parameters: |
402 | sw:ovs\_dpdk: "true" |
403 +------------------------------------------------------+
405 NFV TOSCA Type Definition
406 -------------------------
408 tosca.capabilites.nfv.VirtualCompute
409 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
411 +---------------------------+-----------------------------------------+
412 | **Shorthand Name** | VirtualCompute |
413 +===========================+=========================================+
414 | **Type Qualified Name** | tosca: VirtualCompute |
415 +---------------------------+-----------------------------------------+
416 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
417 +---------------------------+-----------------------------------------+
418 | **derived from** | tosca.nodes.Root |
419 +---------------------------+-----------------------------------------+
424 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
425 | Name | Required | Type | Constraints | Description |
426 +=====================================+============+=====================================================+===============+=========================================================+
427 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
428 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
429 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
430 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
431 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
432 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
433 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
435 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
440 +-----------------------------------------------------------+
441 | tosca.capabilities.nfv.VirtualCompute: |
443 | derived\_from: tosca.capabilities.Root |
447 | requested\_additional\_capabilities: |
453 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
459 | type: tosca.datatypes.nfv.VirtualMemory |
465 | type: tosca.datatypes.nfv.VirtualCpu |
468 +-----------------------------------------------------------+
470 tosca.nodes.nfv.VDU.Compute
471 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
473 The NFV Virtualization Deployment Unit (VDU) compute node type
474 represents a VDU entity which it describes the deployment and
475 operational behavior of a VNF component (VNFC), as defined by **[ETSI
478 +-----------------------+-------------------------------+
479 | Shorthand Name | VDU.Compute |
480 +=======================+===============================+
481 | Type Qualified Name | tosca:VDU.Compute |
482 +-----------------------+-------------------------------+
483 | Type URI | tosca.nodes.nfv.VDU.Compute |
484 +-----------------------+-------------------------------+
485 | derived\_from | tosca.nodes.Compute |
486 +-----------------------+-------------------------------+
499 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
500 | Name | Type | Constraints | Description |
501 +=========================+=================================================+===============+=====================================================================================================+
502 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
503 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
504 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
506 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
507 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
508 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
510 | | editor note: need to create a capability type | | |
511 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
516 +-----------------------------------------------------------------------------------------------------+
517 | tosca.nodes.nfv.VDU.Compute: |
519 | derived\_from: tosca.nodes.Compute |
537 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
545 | nfvi\_constraints: |
555 | configurable\_properties: |
561 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
567 | private\_address: |
569 | status: deprecated |
573 | status: deprecated |
577 | status: deprecated |
581 | status: deprecated |
585 | virtual\_compute: |
587 | type: tosca.capabilities.nfv.VirtualCompute |
589 | virtual\_binding: |
591 | type: tosca.capabilities.nfv.VirtualBindable |
593 | #monitoring\_parameter: |
595 | # modeled as ad hoc (named) capabilities in VDU node template |
601 | # cpu\_load: tosca.capabilities.nfv.Metric |
603 | # memory\_usage: tosca.capabilities.nfv.Metric |
605 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
607 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
609 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
611 | occurrences: [0,UNBOUNDED] |
615 | occurrences: [0,0] |
619 | occurrences: [0,0] |
621 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
623 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
627 | occurrences: [0,UNBOUND] |
631 | - virtual\_storage: |
633 | capability: tosca.capabilities.nfv.VirtualStorage |
635 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
637 | node: tosca.nodes.nfv.VDU.VirtualStorage |
639 | occurences: [ 0, UNBOUNDED ] |
641 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
643 | occurrences: [0,0] |
651 | type: tosca.artifacts.nfv.SwImage |
652 +-----------------------------------------------------------------------------------------------------+
656 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
657 | Name | Required | Type | Constraints | Description |
658 +===========+============+===============================+===============+================================================+
659 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
660 | | | | | directly realizing this virtual storage |
661 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
671 The TOSCA Cpd node represents network connectivity to a compute resource
672 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
673 used as parent for the various Cpd types.
675 +-----------------------+-----------------------+
676 | Shorthand Name | Cpd |
677 +=======================+=======================+
678 | Type Qualified Name | tosca:Cpd |
679 +-----------------------+-----------------------+
680 | Type URI | tosca.nodes.nfv.Cpd |
681 +-----------------------+-----------------------+
687 +--------+------------+--------+---------------+---------------+
688 | Name | Required | Type | Constraints | Description |
689 +========+============+========+===============+===============+
690 +--------+------------+--------+---------------+---------------+
705 +----------------------------------------------------------------------+
706 | tosca.nodes.nfv.Cpd: |
708 | derived\_from: tosca.nodes.Root |
718 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
722 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
728 | - valid\_values: [ root, leaf ] |
744 | type: tosca.datatype.nfv.AddressData |
747 +----------------------------------------------------------------------+
749 Additional Requirement
750 ^^^^^^^^^^^^^^^^^^^^^^
754 tosca.nodes.nfv.VduCpd
755 ~~~~~~~~~~~~~~~~~~~~~~
757 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
758 network connectivity between a VNFC instance (based on this VDU) and an
759 internal VL as defined by [ETSI GS NFV-IFA 011].
761 +-----------------------+--------------------------+
762 | Shorthand Name | VduCpd |
763 +=======================+==========================+
764 | Type Qualified Name | tosca: VduCpd |
765 +-----------------------+--------------------------+
766 | Type URI | tosca.nodes.nfv.VduCpd |
767 +-----------------------+--------------------------+
773 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
774 | Name | Required | Type | Constraints | Description |
775 +===============================+============+==========================================+==========================================================================+
776 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
777 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
778 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
779 | requirements | | | | realising the CPs instantiated from this CPD |
780 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
790 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
791 | Name | Required | Type | Constraints | Description |
792 +====================+============+==========================================+===============+==========================================================+
793 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
794 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
795 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
796 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
801 +----------------------------------------------------------------+
802 | tosca.nodes.nfv.VduCpd: |
804 | derived\_from: tosca.nodes.nfv.Cpd |
808 | bitrate\_requirement: |
814 | virtual\_network\_interface\_requirements |
820 | type: VirtualNetworkInterfaceRequirements |
828 | capability: tosca.capabilities.nfv.VirtualLinkable |
830 | relationship: tosca.relationships.nfv.VirtualLinksTo |
832 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
834 | capability: tosca.capabilities.nfv.VirtualBindable |
836 | relationship: tosca.relationships.nfv.VirtualBindsTo |
838 | node: tosca.nodes.nfv.VDU |
839 +----------------------------------------------------------------+
841 tosca.nodes.nfv.VDU.VirtualStorage
842 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
844 The NFV VirtualStorage node type represents a virtual storage entity
845 which it describes the deployment and operational behavior of a virtual
846 storage resources, as defined by **[ETSI NFV IFA011].**
848 **[editor note]** open issue: should NFV profile use the current storage
849 model as described in YAML 1.1. Pending on Shitao proposal (see
850 NFVIFA(17)000110 discussion paper)
852 **[editor note]** new relationship type as suggested in Matt
853 presentation. Slide 8. With specific rules of “valid\_target\_type”
855 +---------------------------+--------------------------------------+
856 | **Shorthand Name** | VirtualStorage |
857 +===========================+======================================+
858 | **Type Qualified Name** | tosca: VirtualStorage |
859 +---------------------------+--------------------------------------+
860 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
861 +---------------------------+--------------------------------------+
862 | **derived\_from** | tosca.nodes.Root |
863 +---------------------------+--------------------------------------+
865 tosca.artifacts.nfv.SwImage
866 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
868 +---------------------------+------------------------------------+
869 | **Shorthand Name** | SwImage |
870 +===========================+====================================+
871 | **Type Qualified Name** | tosca:SwImage |
872 +---------------------------+------------------------------------+
873 | **Type URI** | tosca.artifacts.nfv.SwImage |
874 +---------------------------+------------------------------------+
875 | **derived\_from** | tosca.artifacts.Deployment.Image |
876 +---------------------------+------------------------------------+
881 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
882 | Name | Required | Type | Constraints | Description |
883 +==========================================+============+====================+===============+====================================================================================================+
884 | name | yes | string | | Name of this software image |
885 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
886 | version | yes | string | | Version of this software image |
887 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
888 | checksum | yes | string | | Checksum of the software image file |
889 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
890 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
891 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
892 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
893 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
894 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
895 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
896 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
897 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
898 | Size | yes | scalar-unit.size | | The size of this software image |
899 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
900 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
901 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
902 | operating\_system | no | string | | Identifies the operating system used in the software image. |
903 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
904 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
905 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
910 +-----------------------------------------------------+
911 | tosca.artifacts.nfv.SwImage: |
913 | derived\_from: tosca.artifacts.Deployment.Image |
915 | properties or metadata: |
939 | container\_format: |
953 | type: scalar-unit.size # Number |
959 | type: scalar-unit.size # Number |
965 | type: scalar-unit.size # Number |
975 | operating\_system: |
981 | supported\_virtualisation\_environments: |
990 +-----------------------------------------------------+
995 openovnf\_\_vOpenNAT.yaml
996 ~~~~~~~~~~~~~~~~~~~~~~~~~
998 +-------------------------------------------------------------+
1001 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1003 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1005 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1007 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1009 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1011 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1013 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1015 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1017 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1019 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1021 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1023 | - openonfv\_\_tosca.capabilities.Container.yaml |
1025 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1027 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1029 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1031 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1033 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1035 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1037 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1041 | vnfProductName: openNAT |
1043 | vnfdVersion: 1.0.0 |
1045 | vnfProvider: intel |
1049 | csarVersion: 1.0.0 |
1051 | vnfdId: openNAT-1.0 |
1053 | csarProvider: intel |
1055 | vnfProductInfoDescription: openNAT |
1063 | localizationLanguage: '[english, chinese]' |
1067 | defaultLocalizationLanguage: english |
1069 | vnfProductInfoName: openNAT |
1071 | vnfSoftwareVersion: 1.0.0 |
1073 | topology\_template: |
1075 | node\_templates: |
1083 | file: /swimages/xenial-snat.qcow2 |
1085 | type: tosca.artifacts.nfv.SwImage |
1089 | name: vNatVNFImage |
1093 | checksum: "5000" |
1095 | container\_format: bare |
1097 | disk\_format: qcow2 |
1099 | min\_disk: 10 GB |
1105 | sw\_image: /swimages/xenial-snat.qcow2 |
1107 | operating\_system: unbantu |
1111 | tosca\_name: vdu\_vNat |
1115 | virtual\_compute: |
1119 | virtual\_memory: |
1121 | numa\_enabled: true |
1123 | virtual\_mem\_size: 2 GB |
1125 | requested\_additional\_capabilities: |
1129 | support\_mandatory: true |
1131 | requested\_additional\_capability\_name: numa |
1133 | target\_performance\_parameters: |
1135 | hw:numa\_nodes: "2" |
1137 | hw:numa\_cpus.0: "0,1" |
1139 | hw:numa\_mem.0: "1024" |
1141 | hw:numa\_cpus.1: "2,3,4,5" |
1143 | hw:numa\_mem.1: "1024" |
1145 | hyper\_threading: |
1147 | support\_mandatory: true |
1149 | requested\_additional\_capability\_name: hyper\_threading |
1151 | target\_performance\_parameters: |
1153 | hw:cpu\_sockets : "2" |
1155 | hw:cpu\_threads : "2" |
1157 | hw:cpu\_cores : "2" |
1159 | hw:cpu\_threads\_policy: "isolate" |
1163 | support\_mandatory: true |
1165 | requested\_additional\_capability\_name: ovs\_dpdk |
1167 | target\_performance\_parameters: |
1169 | sw:ovs\_dpdk: "true" |
1173 | cpu\_architecture: X86 |
1175 | num\_virtual\_cpu: 2 |
1179 | configurable\_properties: |
1183 | additional\_vnfc\_configurable\_properties: |
1189 | descrption: the virtual machine of vNat |
1197 | - virtual\_storage: |
1199 | capability: virtual\_storage |
1201 | node: vNAT\_Storage |
1207 | location: /mnt/volume\_0 |
1209 | type: tosca.relationships.nfv.VDU.AttachedTo |
1211 | - local\_storage: |
1213 | node: tosca.nodes.Root |
1215 | type: tosca.nodes.nfv.VDU.Compute |
1221 | tosca\_name: SRIOV\_Port |
1225 | virtual\_network\_interface\_requirements: |
1229 | support\_mandatory: false |
1231 | description: sriov |
1239 | description: sriov port |
1241 | layer\_protocol: ipv4 |
1245 | - virtual\_binding: |
1247 | capability: virtual\_binding |
1253 | type: tosca.relationships.nfv.VirtualBindsTo |
1255 | - virtual\_link: |
1257 | node: tosca.nodes.Root |
1259 | type: tosca.nodes.nfv.VduCpd |
1265 | tosca\_name: vNAT\_Storage |
1269 | id: vNAT\_Storage |
1271 | size\_of\_storage: 10 GB |
1273 | rdma\_enabled: false |
1275 | type\_of\_storage: volume |
1277 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1279 | substitution\_mappings: |
1289 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1291 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1292 +-------------------------------------------------------------+
1294 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1295 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1297 +------------------------------------------------------------+
1300 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1304 | tosca.nodes.nfv.VDU.VirtualStorage: |
1308 | virtual\_storage: |
1310 | type: tosca.capabilities.nfv.VirtualStorage |
1312 | derived\_from: tosca.nodes.Root |
1320 | size\_of\_storage: |
1330 | type\_of\_storage: |
1334 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1335 +------------------------------------------------------------+
1337 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1338 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1340 +-----------------------------------------------------------------+
1343 | tosca.datatypes.nfv.L3AddressData: |
1347 | number\_of\_ip\_address: |
1353 | ip\_address\_assignment: |
1357 | ip\_address\_type: |
1361 | - valid\_values: |
1371 | floating\_ip\_activated: |
1375 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1385 | support\_mandatory: |
1403 | tosca.datatype.nfv.AddressData: |
1411 | - valid\_values: |
1419 | l2\_address\_data: |
1423 | type: tosca.datatypes.nfv.L2AddressData |
1425 | l3\_address\_data: |
1429 | type: tosca.datatypes.nfv.L3AddressData |
1431 | tosca.datatypes.nfv.L2AddressData: {} |
1435 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1437 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1441 | tosca.nodes.nfv.VduCpd: |
1443 | derived\_from: tosca.nodes.Root |
1447 | virtual\_network\_interface\_requirements: |
1451 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1461 | - valid\_values: |
1471 | bitrate\_requirement: |
1483 | layer\_protocol: |
1487 | - valid\_values: |
1507 | type: tosca.datatype.nfv.AddressData |
1515 | - virtual\_binding: |
1517 | capability: tosca.capabilities.nfv.VirtualBindable |
1525 | - virtual\_link: |
1527 | capability: tosca.capabilities.nfv.VirtualBindable |
1535 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1536 +-----------------------------------------------------------------+
1538 .. |image1| image:: Image1.png
1541 .. |image2| image:: Image2.png
1555 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1556 Markup Language) is a human friendly data serialization standard for all
1557 programming languages. See http://www.yaml.org/.
1559 Heat Orchestration Template Format
1560 ----------------------------------
1562 Heat Orchestration templates must be defined in YAML.
1566 - Tabs are NOT allowed, use spaces ONLY.
1568 - You MUST indent your properties and lists with 1 or more spaces.
1570 - All Resource IDs and resource property parameters are case-sensitive.
1571 (e.g., "ThIs", is not the same as "thiS")
1573 Heat Orchestration Template Structure
1574 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1576 Heat Orchestration template structure follows the following format, as
1577 defined by OpenStack at
1578 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1580 .. code-block:: yaml
1582 heat_template_version: <date>
1585 # a description of the template
1588 # a declaration of input parameter groups and order
1591 # declaration of input parameters
1594 # declaration of template resources
1597 # declaration of output parameters
1600 # declaration of conditions
1603 Heat Orchestration templates for ONAP must contain the following
1606 - heat\_template\_version:
1614 Heat Orchestration templates for ONAP may contain the following
1617 - parameter\_groups:
1621 heat\_template\_version
1622 ^^^^^^^^^^^^^^^^^^^^^^^
1624 This section is ONAP mandatory. The heat\_template\_version must be set
1625 to a date that is supported by the OpenStack environment.
1630 This ONAP mandatory section allows for a description of the template.
1635 This ONAP optional section allows for specifying how the input
1636 parameters should be grouped and the order to provide the parameters in.
1641 The parameter section is ONAP mandatory. This section allows for
1642 specifying input parameters that have to be provided when instantiating
1643 the template. Each parameter is specified in a separated nested block
1644 with the name of the parameters defined in the first line and additional
1645 attributes (e.g., type, label) defined as nested elements.
1647 The Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process
1648 requires all parameters declared in a template to be used in a resource
1649 with the exception of the parameters for the OS::Nova::Server property
1650 availability\_zone. See `Property: availability\_zone`_. for more details on
1653 .. code-block:: yaml
1657 type: <string | number | json | comma_delimited_list | boolean>
1658 label: <human-readable name of the parameter>
1659 description: <description of the parameter>
1660 default: <default value for parameter>
1661 hidden: <true | false>
1663 <parameter constraints>
1664 immutable: <true | false>
1668 - The name of the parameter.
1670 - ONAP requires that the param name must contain only alphanumeric
1671 characters and “\_” underscores. Special characters must not be
1676 - The type of the parameter. Supported types are string, number,
1677 comma\_delimited\_list, json and boolean.
1679 - This attribute must be provided per the OpenStack Heat
1680 Orchestration Template standard.
1684 - A human readable name for the parameter.
1686 - This attribute is optional.
1690 - A human readable description for the parameter.
1692 - This attribute is ONAP mandatory; it must be provided. (Note that
1693 this attribute is OpenStack optional.)
1697 - A default value for the parameter.
1699 - ONAP does not support this attribute; it *must not* be provided in
1700 the Heat Orchestration Template. If a parameter has a default
1701 value, it must be provided in the environment file. (Note that
1702 this attribute is OpenStack optional.)
1706 - Defines whether the parameters should be hidden when a user
1707 requests information about a stack created from the template. This
1708 attribute can be used to hide passwords specified as parameters.
1710 - This attribute is optional and defaults to false.
1714 - A list of constraints to apply. The constraints block of a
1715 parameter definition defines additional validation constraints
1716 that apply to the value of the parameter. The parameter values
1717 provided in the Heat Orchestration Template are validated against
1718 the constraints at instantiation time. The constraints are defined
1719 as a list with the following syntax
1723 - <constraint type>: <constraint definition>
1725 description: <constraint description>
1727 - constraint type: Type of constraint to apply.
1729 - constraint definition: The actual constraint, depending on the
1732 - description: A description of the constraint. The text is presented
1733 to the user when the value the user defines violates the constraint.
1734 If omitted, a default validation message is presented to the user.
1735 This attribute is optional.
1737 - When the parameter type is set to number, the Heat Orchestration
1738 Template uploaded into ONAP must have constraints for range or
1741 - range: The range constraint applies to parameters of type number.
1742 It defines a lower and upper limit for the numeric value of the
1743 parameter. The syntax of the range constraint is
1745 range: { min: <lower limit>, max: <upper limit> }
1747 It is possible to define a range constraint with only a lower limit
1750 - allowed\_values: The allowed\_values constraint applies to parameters
1751 of type string or number. It specifies a set of possible values for a
1752 parameter. At deployment time, the user-provided value for the
1753 respective parameter must match one of the elements of the list. The
1754 syntax of the allowed\_values constraint is
1756 allowed\_values: [ <value>, <value>, ... ]
1758 Alternatively, the following YAML list notation can be used
1768 - Other <constraint type> are optional, they may be used (e.g., length,
1769 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1772 - Note that constrains must not be defined for any parameter enumerated
1773 in a nested heat template.
1775 - Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
1779 - Defines whether the parameter is updatable. Stack update fails, if
1780 this is set to true and the parameter value is changed.
1782 - This attribute is optional and defaults to false.
1787 This section is ONAP mandatory; it must be provided. This section
1788 contains the declaration of the single resources of the template. This
1789 section with at least one resource must be defined in the Heat
1790 Orchestration Template, or the template would not create any resources
1791 when being instantiated.
1793 Each resource is defined as a separate block in the resources section
1794 with the following syntax.
1796 .. code-block:: yaml
1800 type: <resource type>
1802 <property name>: <property value>
1804 <resource specific metadata>
1805 depends\_on: <resource ID or list of ID>
1806 update\_policy: <update policy>
1807 deletion\_policy: <deletion policy>
1808 external\_id: <external resource ID>
1809 condition: <condition name or expression or boolean>
1813 - A resource ID that must be unique within the resources section of
1814 the Heat Orchestration Template.
1816 - ONAP requires that the resource ID must be unique across all Heat
1817 Orchestration Templates that compose the VNF. This requirement
1818 also applies when a VNF is composed of more than one Heat
1819 Orchestration Template (see ONAP VNF Modularity Overview).
1821 - The naming convention for a resource ID is provided in `Resource IDs`_.
1825 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1826 Note that the type may specify a nested heat file. This attribute
1831 - A list of resource-specific properties. The property value can be
1832 provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
1834 - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
1838 - Resource-specific metadata. This section is optional, except for
1839 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1843 - Dependencies of the resource on one or more resources of the
1844 template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
1848 - Update policy for the resource, in the form of a nested
1849 dictionary. Whether update policies are supported and what the
1850 exact semantics are depends on the type of the current resource.
1851 This attribute is optional.
1855 - Deletion policy for the resource. The allowed deletion policies
1856 are Delete, Retain, and Snapshot. Beginning with
1857 heat\_template\_version 2016-10-14, the lowercase equivalents
1858 delete, retain, and snapshot are also allowed. This attribute is
1859 optional; the default policy is to delete the physical resource
1860 when deleting a resource from the stack.
1864 - Allows for specifying the resource\_id for an existing external
1865 (to the stack) resource. External resources cannot depend on other
1866 resources, but we allow other resources to depend on external
1867 resource. This attribute is optional. Note: when this is
1868 specified, properties will not be used for building the resource
1869 and the resource is not managed by Heat. This is not possible to
1870 update that attribute. Also, resource won’t be deleted by heat
1871 when stack is deleted.
1875 - Condition for the resource. The condition decides whether to
1876 create the resource or not. This attribute is optional.
1881 This ONAP optional section allows for specifying output parameters
1882 available to users once the template has been instantiated. If the
1883 section is specified, it will need to adhere to specific requirements.
1884 See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
1886 Environment File Format
1887 -----------------------
1889 The environment file is a yaml text file.
1890 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1892 The environment file can contain the following sections:
1894 - parameters: A list of key/value pairs.
1896 - resource\_registry: Definition of custom resources.
1898 - parameter\_defaults: Default parameters passed to all template
1901 - encrypted\_parameters: List of encrypted parameters.
1903 - event\_sinks: List of endpoints that would receive stack events.
1905 - parameter\_merge\_strategies: Merge strategies for merging parameters
1906 and parameter defaults from the environment file.
1908 Environment files for ONAP must contain the following sections:
1912 Environment files for ONAP may contain the following sections:
1914 - resource\_registry:
1916 - parameter\_defaults:
1918 - encrypted\_parameters:
1922 - parameter\_merge\_strategies:
1924 The use of an environment file in OpenStack is optional. In ONAP, it is
1925 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
1926 corresponding environment file, even if no parameters are enumerated in
1927 the mandatory parameter section.
1929 (Note that ONAP, the open source version of ONAP, does not
1930 programmatically enforce the use of an environment file.)
1932 SDC Treatment of Environment Files
1933 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1935 Parameter values enumerated in the environment file are used by SDC as
1936 the default value. However, the SDC user may use the SDC GUI to
1937 overwrite the default values in the environment file.
1939 SDC generates a new environment file for distribution to MSO based on
1940 the uploaded environment file and the user provided GUI updates. The
1941 user uploaded environment file is discarded when the new file is
1944 ONAP has requirements for what parameters must be enumerated in the
1945 environment file and what parameter must not be enumerated in the
1946 environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1948 Nested Heat Orchestration Templates Overview
1949 --------------------------------------------
1951 ONAP supports nested Heat Orchestration Templates per OpenStack
1954 A Base Module may utilize nested templates.
1956 An Incremental Module may utilize nested templates.
1958 A Cinder Volume Module may utilize nested templates.
1960 A nested template must not define parameter constraints in the parameter
1963 Nested templates may be suitable for larger VNFs that contain many
1964 repeated instances of the same VM type(s). A common usage pattern is to
1965 create a nested template for each VM type along with its supporting
1966 resources. The Heat Orchestration Template may then reference these
1967 nested templates either statically (by repeated definition) or
1968 dynamically (via OS::Heat::ResourceGroup).
1970 See `Nested Heat Templates`_ for additional details.
1972 ONAP Heat Orchestration Template Filenames
1973 ------------------------------------------
1975 In order to enable ONAP to understand the relationship between Heat
1976 files, the following Heat file naming convention must be utilized.
1978 In the examples below, <text> represents any alphanumeric string that
1979 must not contain any special characters and must not contain the word
1985 The file name for the base module must include “base” in the filename
1986 and must match one of the following options:
1988 - base\_<text>.y[a]ml
1990 - <text>\_base.y[a]ml
1994 - <text>\_base\_<text>.y[a]ml
1996 The base module’s corresponding environment file must be named identical
1997 to the base module with “.y[a]ml” replaced with “.env”.
2002 There is no explicit naming convention for the incremental modules. As
2003 noted above, <text> represents any alphanumeric string that must not
2004 contain any special characters and must not contain the word “base”.
2008 The incremental module’s corresponding environment file must be named
2009 identical to the incremental module with “.y[a]ml” replaced with “.env”.
2011 To clearly identify the incremental module, it is recommended to use the
2012 following naming options for modules:
2014 - module\_<text>.y[a]ml
2016 - <text>\_module.y[a]ml
2020 Cinder Volume Modules
2021 ~~~~~~~~~~~~~~~~~~~~~
2023 The file name for the Cinder volume module must be named the same as the
2024 corresponding module it is supporting (base module or incremental
2025 module) with “\_volume” appended
2027 - <base module name>\_volume.y[a]ml
2029 - <incremental module name>\_volume.y[a]ml
2031 The volume module’s corresponding environment file must be named
2032 identical to the volume module with “.y[a]ml” replaced with “.env”.
2037 There is no explicit naming convention for nested Heat files with the
2038 following exceptions; the name should contain “nest”. As noted above,
2039 <text> represents any alphanumeric string that must not contain any
2040 special characters and must not contain the word “base”.
2044 Nested Heat files do not have corresponding environment files, per
2045 OpenStack specifications. All parameter values associated with the
2046 nested heat file must be passed in as properties in the resource
2047 definition defined in the parent heat template.
2049 ONAP Parameter Classifications Overview
2050 ---------------------------------------
2052 In order for ONAP to support workflow automation, Heat Orchestration
2053 Template resource property parameters must adhere to specific naming
2054 conventions and requirements.
2056 Broadly, ONAP categorizes parameters into four categories:
2058 1. ONAP metadata parameters
2060 2. Instance specific parameters
2062 3. Constant parameters
2064 4. Output parameters.
2066 ONAP Metadata Parameters
2067 ~~~~~~~~~~~~~~~~~~~~~~~~
2069 There are both mandatory and optional ONAP metadata parameters
2070 associated with the resource OS::Nova::Server.
2072 - ONAP metadata parameters must not have parameter constraints defined.
2074 - Both mandatory and optional (if specified) ONAP metadata parameter
2075 names must follow the ONAP metadata parameter naming convention.
2077 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
2079 Instance specific parameters
2080 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2082 The instance specific parameters are VNF instance specific. The value of
2083 the parameter will be different for every instance of a VNF (e.g., IP
2084 address). The instance specific parameters are subdivided into two
2085 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2088 ONAP Orchestration Parameters
2089 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2091 ONAP Orchestration Parameters are per instance parameters where the
2092 value is assigned via ONAP automation. (Note that in some cases,
2093 automation is currently not available and the value is loaded into ONAP
2094 prior to instantiation.)
2096 - ONAP orchestration parameters must not be enumerated in the
2099 - When the ONAP orchestration parameter type is set to number, the
2100 parameter must have constraints for range and/or allowed\_values.
2102 - Parameter constraints for ONAP orchestration parameters are optional
2103 for all parameter types other than number. If constraints are
2104 specified, they must adhere to the OpenStack specifications.
2106 - The ONAP orchestration parameter names must follow the ONAP
2107 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2110 VNF Orchestration Parameters
2111 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2113 VNF Orchestration Parameters are per instance parameters where the
2114 values are assigned manually. They are not supported by ONAP automation.
2115 The per instance values are loaded into ONAP prior to VNF instantiation.
2117 - VNF orchestration parameters must not be enumerated in the
2120 - When the VNF orchestration parameter type is set to number, the
2121 parameter must have constraints for range or allowed\_values.
2123 - Parameter constraints for VNF orchestration parameters are optional
2124 for all parameter types other than number. If constraints are
2125 specified, they must adhere to the OpenStack specifications.
2127 - The VNF orchestration parameter names should follow the VNF
2128 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2134 The constant parameters are parameters that remain constant across many
2135 VNF instances (e.g., image, flavor). The constant parameters are
2136 subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
2138 ONAP Constant Parameters
2139 ^^^^^^^^^^^^^^^^^^^^^^^^
2141 - ONAP Constant Parameters must be enumerated in the environment file.
2142 These parameter values are not assigned by ONAP.
2144 - When the ONAP Constant Parameter type is set to number, the parameter
2145 must have constraints for range and/or allowed\_values.
2147 - Parameter constraints for ONAP constant parameters are optional for
2148 all parameter types other than number. If constraints are specified,
2149 they must adhere to the OpenStack specifications.
2151 - The ONAP Constant Parameter names must follow the ONAP orchestration
2152 parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2154 VNF Constant Parameters
2155 ^^^^^^^^^^^^^^^^^^^^^^^
2157 - VNF Constant Parameters must be enumerated in the environment file.
2158 These parameter values are not assigned by ONAP.
2160 - When the VNF Constant Parameters type is set to number, the parameter
2161 must have constraints for range and/or allowed\_values.
2163 - Parameter constraints for ONAP constant parameters are optional for
2164 all parameter types other than number. If constraints are specified,
2165 they must adhere to the OpenStack specifications.
2167 - The VNF Constant Parameters names should follow the ONAP
2168 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2174 The output parameters are parameters defined in the output section of a
2175 Heat Orchestration Template. The ONAP output parameters are subdivided
2176 into three categories:
2178 1. ONAP Base Module Output Parameters
2180 2. ONAP Volume Module Output Parameters
2182 3. ONAP Predefined Output Parameters.
2184 ONAP Base Module Output Parameters
2185 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2187 ONAP Base Module Output Parameters are declared in the outputs: section
2188 of the base module Heat Orchestration Template. A Base Module Output
2189 Parameter is available as an input parameter (i.e., declared in the
2190 “parameters:” section) to all incremental modules in the VNF.
2192 - A Base Module Output Parameter may be used as an input parameter in
2193 an incremental module.
2195 - The Output parameter name and type must match the input parameter
2196 name and type unless the Output parameter is of the type
2197 comma\_delimited\_list.
2199 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2200 a collection of UUIDs from a Resource Group), then the
2201 corresponding input parameter must be declared as type json and
2202 not a comma\_delimited\_list, which is actually a string value
2203 with embedded commas.
2205 - When a Base Module Output Parameter is declared as an input parameter
2206 in an incremental module Heat Orchestration Template, parameter
2207 constraints must not be declared.
2209 Additional details on ONAP Base Module Output Parameters are provided in
2210 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2212 ONAP Volume Module Output Parameters
2213 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2215 The volume template output parameters are only available for the module
2216 (base or add on) that the volume is associated with.
2218 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2219 section of the Cinder volume module Heat Orchestration Template
2221 - An ONAP Volume Module Output Parameter is available as an input
2222 parameter (i.e., declared in the parameters: section) only for the
2223 module (base or incremental) that the Cinder volume module is
2224 associated with. The Output parameter name and type must match the
2225 input parameter name and type unless the Output parameter is of the
2226 type comma\_delimited\_list.
2228 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2229 collection of UUIDs from a Resource Group), then the corresponding
2230 input parameter must be declared as type json and not a
2231 comma\_delimited\_list, which is actually a string value with
2234 - When an ONAP Volume Module Output Parameter is declared as an input
2235 parameter in a base module or incremental module, parameter
2236 constraints must not be declared.
2238 Additional details on ONAP Base Module Output Parameters are provided in
2239 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2241 ONAP Predefined Output Parameters
2242 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2244 ONAP will look for a small set of pre-defined Heat output parameters to
2245 capture resource attributes for inventory in ONAP. These output
2246 parameters are optional and are specified in `OAM Management IP Addresses`_.
2248 Support of heat stack update
2249 ----------------------------
2251 VNF Heat Orchestration Templates must not be designed to utilize the
2252 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2253 does not support the use of heat stack-update command for scaling.
2255 It is important to note that ONAP only supports heat stack-update for
2261 ONAP defines two types of networks: External Networks and Internal
2264 ONAP defines an external network in relation to the VNF and not with
2265 regard to the Network Cloud site. External networks may also be referred
2266 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2268 - VMs in another VNF or
2270 - an external gateway or router
2272 ONAP defines an internal network in relation to the VNF and not with
2273 regard to the Network Cloud site. Internal networks may also be referred
2274 to as “intra-VNF” networks or “private” networks. An internal network
2275 only connects VMs in a single VNF. It must not connect to other VNFs or
2276 an external gateway or router.
2281 VNF Heat Orchestration Templates must not include any resources for
2282 external networks connected to the VNF. External networks must be
2283 orchestrated separately, as independent, stand-alone VNF Heat
2284 Orchestration Templates, so they can be shared by multiple VNFs and
2285 managed independently.
2287 When the external network is created, it must be assigned a unique
2288 {network-role}. The {network-role} should describe the network (e.g.,
2289 oam). The {network-role} while unique to the LCP, can repeat across
2292 An External Network may be a Neutron Network or a Contrail Network
2294 External networks must be passed into the VNF Heat Orchestration
2295 Templates as parameters.
2297 - Neutron Network-id (UUID)
2299 - Neutron Network subnet ID (UUID)
2301 - Contrail Network Fully Qualified Domain Name (FQDN)
2303 ONAP enforces a naming convention for parameters associated with
2304 external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2306 Parameter values associated with an external network will be generated
2307 and/or assigned by ONAP at orchestration time. Parameter values
2308 associated with an external network must not be enumerated in the
2309 environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2311 VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
2312 when attaching VMs to an external network
2314 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2316 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2319 - Note that Neutron Floating IPs must not be used. ONAP does not
2320 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2322 - ONAP supports the property allowed\_address\_pairs in the resource
2323 OS::Neutron:Port and the property
2324 virtual\_machine\_interface\_allowed\_address\_pairs in
2325 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2326 of a virtual IP (VIP) address to a set of VMs.
2328 VNF Heat Orchestration Templates must pass the appropriate external
2329 network IDs into nested VM templates when nested Heat is used.
2334 The VNF Heat Orchestration Templates must include the resource(s) to
2335 create the internal network. The internal network must be either a
2336 Neutron Network or a Contrail Network.
2338 In the modular approach, internal networks must be created in the Base
2339 Module, with their resource IDs exposed as outputs (i.e., ONAP Base
2340 Module Output Parameters) for use by all incremental modules. If the
2341 Network resource ID is required in the base template, then a
2342 get\_resource must be used.
2344 When the internal network is created, it should be assigned a unique
2345 {network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
2348 VNFs may use **Cloud assigned IP addresses** or
2349 **predetermined static IPs** when attaching VMs to an internal network.
2351 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2353 - A predetermined static IP address is enumerated in the Heat
2354 environment file. Since an internal network is local to the VNF, IP
2355 addresses can be re-used at every VNF instance.
2357 - Note that Neutron Floating IPs must not be used. ONAP does not
2358 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2360 - ONAP supports the property allowed\_address\_pairs in the resource
2361 OS::Neutron:Port and the property
2362 virtual\_machine\_interface\_allowed\_address\_pairs in
2363 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2364 of a virtual IP (VIP) address to a set of VMs.
2366 ONAP does not programmatically enforce a naming convention for
2367 parameters for internal network. However, a naming convention is
2368 provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2370 ONAP Resource ID and Parameter Naming Convention
2371 ------------------------------------------------
2373 This section provides the ONAP naming requirements for
2377 2. Resource Property Parameters
2382 The Heat Orchestration Templates for a VNF must assign a VNF unique
2383 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2384 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2385 it does not have to be globally unique across all VNFs that ONAP
2388 Any parameter that is associated with a unique Virtual Machine type in
2389 the VNF must include {vm-type} as part of the parameter name.
2391 Any resource ID that is associated with a unique Virtual Machine type in
2392 the VNF must include {vm-type} as part of the resource ID.
2394 Note that {vm-type} must not be a substring of {network-role}. A
2395 substring of a string is another string that occurs "in". For example,
2396 "oam" is a substring of "oam\_protected". It will cause the
2397 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2398 produce erroneous error messages.
2400 The {vm-type} should not contain the string “\_int” or “int\_” or
2401 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2402 ICE Project) process to produce erroneous error messages.
2404 The {vm-type} must be the same case in all parameter names in the VNF.
2406 The {vm-type} must be the same case in all Resource IDs in the VNF.
2408 It is recommended that the {vm-type} case in the parameter names matches
2409 the {vm-type} case in the Resource IDs.
2411 There are two exceptions to the above rules:
2413 1. The six ONAP Metadata parameters must not be prefixed with a common
2414 {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
2415 *vf\_module\_id*, *vf\_module\_name, vm\_role*. The ONAP Metadata
2416 parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
2418 2. The parameter referring to the OS::Nova::Server property
2419 availability\_zone must not be prefixed with a common {vm-type}
2420 identifier. availability\_zone is described in `Property: availability_zone`_.
2425 The assignment of a {network-role} is discussed in `Networking`_.
2427 Any parameter that is associated with an external network must include
2428 the {network-role} as part of the parameter name.
2430 Any resource ID that is associated with an external network must include
2431 the {network-role} as part of the resource ID.
2433 Any parameter that is associated with an internal network must include
2434 int\_{network-role} as part of the parameter name.
2436 Any resource ID that is associated with an internal network must include
2437 int\_{network-role} as part of the resource ID.
2439 Note that {network-role} must not be a substring of {vm-type}. A
2440 substring of a string is another string that occurs "in". For example,
2441 "oam" is a substring of "oam\_protected". It will cause the
2442 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2443 produce erroneous error messages.
2445 The {network-role} should not contain the string “\_int” or “int\_” or
2446 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2447 ICE Project) process to produce erroneous error messages.
2449 The {network-role} must be the same case in all parameter names in the
2452 The {network-role} must be the same case in all Resource IDs in the VNF.
2454 It is recommended that the {network-role} case in the parameter names
2455 matches the {network-role} case in the Resource IDs.
2460 Heat Orchestration Template resources are described in `resources`_
2462 A resource ID that must be unique within the resources section of a Heat
2463 Orchestration Template. This is an OpenStack Requirement.
2465 When a VNF is composed of more than one Heat Orchestration Template
2466 (i.e., modules), ONAP requires that the resource ID must be unique
2467 across all modules that compose the VNF.
2469 When a resource is associated with a single {vm-type}, the resource ID
2470 must contain {vm-type}.
2472 When a resource is associated with a single external network, the
2473 resource ID must contain {network-role}.
2475 When a resource is associated with a single internal network, the
2476 resource ID must contain int\_{network-role}.
2478 When a resource is associated with a single {vm-type} and a single
2479 external network, the resource ID must contain both the {vm-type} and
2482 - The {vm-type} must appear before the {network-role} and must be
2483 separated by an underscore (i.e., {vm-type}\_{network-role}).
2485 - Note that an {index} value may separate the {vm-type} and the
2486 {network-role}. An underscore will separate the three values (i.e.,
2487 {vm-type}\_{index}\_{network-role}).
2489 When a resource is associated with a single {vm-type} and a single
2490 internal network, the resource ID must contain both the {vm-type} and
2491 int\_{network-role}.
2493 - The {vm-type} must appear before the int\_{network-role} and must be
2494 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2496 - Note that an {index} value may separate the {vm-type} and the
2497 int\_{network-role}. An underscore will separate the three values
2498 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2500 When a resource is associated with more than one {vm-type} and/or more
2501 than one network, the resource ID
2503 - must not contain the {vm-type} and/or
2504 {network-role}/int\_{network-role}
2506 - should contain the term “shared” and/or contain text that identifies
2509 Only alphanumeric characters and “\_” underscores must be used in the
2510 resource ID. Special characters must not be used.
2512 All {index} values must be zero based. That is, the {index} must start
2513 at zero and increment by one.
2515 The table below provides example OpenStack Heat resource ID for
2516 resources only associated with one {vm-type} and/or one network.
2518 +--------------------------------+------------------------------------------------------------+
2519 | Resource Type | Resource ID Format |
2520 +================================+============================================================+
2521 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2522 +--------------------------------+------------------------------------------------------------+
2523 | OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
2524 +--------------------------------+------------------------------------------------------------+
2525 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2526 +--------------------------------+------------------------------------------------------------+
2527 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2528 +--------------------------------+------------------------------------------------------------+
2529 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2530 +--------------------------------+------------------------------------------------------------+
2531 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2532 +--------------------------------+------------------------------------------------------------+
2533 | OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
2534 +--------------------------------+------------------------------------------------------------+
2535 | | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
2536 +--------------------------------+------------------------------------------------------------+
2537 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2538 +--------------------------------+------------------------------------------------------------+
2539 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2540 +--------------------------------+------------------------------------------------------------+
2541 | OS::Nova::Server | {vm\_type}\_{index} |
2542 +--------------------------------+------------------------------------------------------------+
2543 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2544 +--------------------------------+------------------------------------------------------------+
2545 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2546 +--------------------------------+------------------------------------------------------------+
2548 Table 1: Example OpenStack Heat Resource ID
2550 The table below provides example Contrail Heat resource ID for resources
2551 only associated with one {vm-type} and/or one network.
2553 +-------------------------------------------+---------------------------------------------+
2554 | Resource Type | Resource ID Format |
2555 +===========================================+=============================================+
2556 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
2557 +-------------------------------------------+---------------------------------------------+
2558 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2559 +-------------------------------------------+---------------------------------------------+
2560 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2561 +-------------------------------------------+---------------------------------------------+
2562 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2563 +-------------------------------------------+---------------------------------------------+
2564 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2565 +-------------------------------------------+---------------------------------------------+
2566 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2567 +-------------------------------------------+---------------------------------------------+
2568 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2569 +-------------------------------------------+---------------------------------------------+
2570 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2571 +-------------------------------------------+---------------------------------------------+
2573 Table 2: Example Contrail Heat resource ID
2575 Resource: OS::Nova::Server - Parameters
2576 ---------------------------------------
2578 The resource OS::Nova::Server manages the running virtual machine (VM)
2579 instance within an OpenStack cloud. (See
2580 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2582 Four properties of this resource must follow the ONAP parameter naming
2583 convention. The four properties are:
2591 4. availability\_zone
2593 The table below provides a summary. The sections that follow provides
2596 Note that the {vm\_type} must be identical across all four property
2597 parameter for a given OS::Nova::Server resource.
2599 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2600 | Resource OS::Nova::Server |
2601 +=============================+===============================+==================+==============================+=================================+
2602 | Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
2603 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2604 | image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
2605 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2606 | flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
2607 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2608 | name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
2609 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2610 | | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
2611 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2612 | availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
2613 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2615 Table 3 Resource Property Parameter Names
2620 The parameter associated with the property image is an ONAP Constant
2623 The parameters must be named {vm-type}\_image\_name in the Heat
2624 Orchestration Template.
2626 The parameter must be declared as type: string
2628 The parameter must be enumerated in the Heat Orchestration Template
2631 Each VM type (i.e., {vm-type}) must have a separate parameter for image,
2632 even if more than one {vm-type} shares the same image. This provides
2633 maximum clarity and flexibility.
2635 *Example Parameter Definition*
2637 .. code-block:: yaml
2640 {vm-type}_image_name:
2642 description: {vm-type} server image
2647 The parameter associated with the property flavor is an ONAP Constant
2650 The parameters must be named {vm-type}\_flavor\_name in the Heat
2651 Orchestration Template.
2653 The parameter must be declared as type: string
2655 The parameter must be enumerated in the Heat Orchestration Template
2658 Each VM type (i.e., {vm-type}) must have a separate parameter for
2659 flavors, even if more than one {vm-type} shares the same flavor. This
2660 provides maximum clarity and flexibility.
2662 *Example Parameter Definition*
2664 .. code-block:: yaml
2667 {vm-type}_flavor_name:
2669 description: {vm-type} flavor
2674 The parameter associated with the property name is an ONAP Orchestration
2677 The parameter value is provided to the Heat template by ONAP. The
2678 parameter must not be enumerated in the environment file.
2680 The parameter must be declared as type: string or type:
2681 comma\_delimited\_list
2683 If the parameter is declared as type:string, the parameter must be named
2684 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2685 at zero and increments by one.
2687 If the parameter is declared as type:comma\_delimited\_list, the
2688 parameter must be named as {vm-type}\_names
2690 Each element in the VM Name list should be assigned to successive
2691 instances of that VM type.
2693 If a VNF contains more than three instances of a given {vm-type}, the
2694 comma\_delimited\_list form of the parameter name (i.e.,
2695 {vm-type}\_names) should be used to minimize the number of unique
2696 parameters defined in the Heat.
2698 *Example: Parameter Definition*
2700 .. code-block:: yaml
2704 type: comma_delimited_list
2705 description: VM Names for {vm-type} VMs
2706 {vm-type}_name_{index}:
2708 description: VM Name for {vm-type} VM {index}
2710 *Example: comma\_delimited\_list*
2712 In this example, the {vm-type} has been defined as “lb” for load
2715 .. code-block:: yaml
2719 type: comma_delimited_list
2720 description: VM Names for lb VMs
2724 type: OS::Nova::Server
2726 name: { get_param: [lb_names, 0] }
2730 type: OS::Nova::Server
2732 name: { get_param: [lb_names, 1] }
2735 *Example: fixed-index*
2737 In this example, the {vm-type} has been defined as “lb” for load
2740 .. code-block:: yaml
2745 description: VM Name for lb VM 0
2749 description: VM Name for lb VM 1
2753 type: OS::Nova::Server
2755 name: { get_param: lb_name_0 }
2759 type: OS::Nova::Server
2761 name: { get_param: lb_name_1 }
2764 Contrail Issue with Values for OS::Nova::Server Property Name
2765 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2767 The Contrail GUI has a limitation displaying special characters. The
2768 issue is documented in
2769 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2770 recommended that special characters be avoided. However, if special
2771 characters must be used, the only special characters supported are:
2773 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2775 Property: availability\_zone
2776 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2778 The parameter associated with the property availability\_zone is an ONAP
2779 Orchestration parameter.
2781 The parameter value is provided to the Heat template by ONAP. The
2782 parameter must not be enumerated in the environment file.
2784 The parameter must be named availability\_zone\_{index} in the Heat
2785 Orchestration Template. The {index} must start at zero. The {index} must
2786 increment by one. The parameter name must not include the {vm-type}.
2788 The parameter must be declared as type: string
2790 The parameter must not be declared as type: comma\_delimited\_list
2795 The example below depicts part of a Heat Orchestration Template that
2796 uses the four OS::Nova::Server properties discussed in this section.
2798 In the Heat Orchestration Template below, four Virtual Machines
2799 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2800 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2801 parameter associated with the property name is a comma\_delimited\_list
2802 for dns and a string for oam.
2804 .. code-block:: yaml
2809 description: dns server image
2812 description: dns server flavor
2814 type: comma_delimited_list
2815 description: dns server names
2818 description: oam server image
2821 description: oam server flavor
2824 description: oam server name 0
2827 description: oam server name 1
2828 availability_zone_0:
2830 description: availability zone ID or Name
2831 availability_zone_1:
2833 description: availability zone ID or Name
2837 type: OS::Nova::Server
2839 name: { get_param: [ dns_names, 0 ] }
2840 image: { get_param: dns_image_name }
2841 flavor: { get_param: dns_flavor_name }
2842 availability_zone: { get_param: availability_zone_0 }
2846 type: OS::Nova::Server
2848 name: { get_param: [ dns_names, 1 ] }
2849 image: { get_param: dns_image_name }
2850 flavor: { get_param: dns_flavor_name }
2851 availability_zone: { get_param: availability_zone_1 }
2855 type: OS::Nova::Server
2857 name: { get_param: oam_name_0 }
2858 image: { get_param: oam_image_name }
2859 flavor: { get_param: oam_flavor_name }
2860 availability_zone: { get_param: availability_zone_0 }
2864 type: OS::Nova::Server
2866 name: { get_param: oam_name_1 }
2867 image: { get_param: oam_image_name }
2868 flavor: { get_param: oam_flavor_name }
2869 availability_zone: { get_param: availability_zone_1 }
2872 Resource: OS::Nova::Server – Metadata Parameters
2873 ------------------------------------------------
2875 The resource OS::Nova::Server has an OpenStack optional property
2876 metadata. The metadata property is mandatory for ONAP Heat Orchestration
2877 Templates; it must be included.
2879 ONAP requires the following three mandatory metadata parameters for an
2880 OS::Nova::Server resource:
2888 ONAP allows the following three optional metadata parameters for an
2889 OS::Nova::Server resource. They may be included
2895 Note that the metadata parameters do not and must not contain {vm-type}
2898 When Metadata parameters are past into a nested heat template, the
2899 parameter names must not change.
2901 The table below provides a summary. The sections that follow provides
2904 +---------------------------+------------------+----------------------+------------------------------+
2905 | Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
2906 +===========================+==================+======================+==============================+
2907 | vnf\_id | string | Mandatory | ONAP |
2908 +---------------------------+------------------+----------------------+------------------------------+
2909 | vf\_module\_id | string | Mandatory | ONAP |
2910 +---------------------------+------------------+----------------------+------------------------------+
2911 | vnf\_name | string | Mandatory | ONAP |
2912 +---------------------------+------------------+----------------------+------------------------------+
2913 | vf\_module\_name | string | Optional | ONAP |
2914 +---------------------------+------------------+----------------------+------------------------------+
2915 | vm\_role | string | Optional | YAML or Environment File |
2916 +---------------------------+------------------+----------------------+------------------------------+
2917 +---------------------------+------------------+----------------------+------------------------------+
2919 Table 4: ONAP Metadata
2924 The vnf\_id parameter is mandatory; it must be included in the Heat
2925 Orchestration Template.
2927 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
2928 UUID that is the vnf\_id and supplies it to the Heat Orchestration
2929 Template at orchestration time.
2931 The parameter must be declared as type: string
2933 Parameter constraints must not be defined.
2935 The parameter must not be enumerated in the Heat environment file.
2937 *Example Parameter Definition*
2939 .. code-block:: yaml
2944 description: Unique ID for this VNF instance
2949 The vf\_module\_id parameter is mandatory; it must be included in the
2950 Heat Orchestration Template.
2952 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
2953 generates the UUID that is the vf\_module\_id and supplies it to the
2954 Heat Orchestration Template at orchestration time.
2956 The parameter must be declared as type: string
2958 Parameter constraints must not be defined.
2960 The parameter must not be enumerated in the Heat environment file.
2962 *Example Parameter Definition*
2964 .. code-block:: yaml
2969 description: Unique ID for this VNF module instance
2974 The vnf\_name parameter is mandatory; it must be included in the Heat
2975 Orchestration Template.
2977 The vnf\_name parameter value will be generated and/or assigned by ONAP
2978 and supplied to the Heat Orchestration Template by ONAP at orchestration
2981 The parameter must be declared as type: string
2983 Parameter constraints must not be defined.
2985 The parameter must not be enumerated in the Heat environment file.
2987 *Example Parameter Definition*
2989 .. code-block:: yaml
2994 description: Unique name for this VNF instance
2999 The vf\_module\_name parameter is optional; it may be included in the
3000 Heat Orchestration Template.
3002 The vf\_module\_name parameter is the name of the name of the Heat stack
3003 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3004 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3005 needs to be specified as part of the orchestration process.
3007 The parameter must be declared as type: string
3009 Parameter constraints must not be defined.
3011 The parameter must not be enumerated in the Heat environment file.
3013 *Example Parameter Definition*
3015 .. code-block:: yaml
3020 description: Unique name for this VNF Module instance
3025 The vm\_role parameter is optional; it may be included in the Heat
3026 Orchestration Template.
3028 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3029 system and available for use by other ONAP components and/or north bound
3032 The vm\_role values must be either
3034 - hard-coded into the Heat Orchestration Template or
3036 - enumerated in the environment file.
3038 Defining the vm\_role as the {vm-type} is a recommended convention
3040 The parameter must be declared as type: string
3042 Parameter constraints must not be defined.
3044 *Example Parameter Definition*
3046 .. code-block:: yaml
3051 description: Unique role for this VM
3053 *Example Resource Definition: Hard Coded*
3055 In this example, the {vm-role} is hard coded in the Heat Orchestration
3058 .. code-block:: yaml
3062 type: OS::Nova::Server
3068 *Example Resource Definition: get\_param*
3070 In this example, the {vm-role} is enumerated in the environment file.
3072 .. code-block:: yaml
3076 type: OS::Nova::Server
3080 vm_role: { get_param: vm_role }
3085 The example below depicts part of a Heat Orchestration Template that
3086 uses the five of the OS::Nova::Server metadata parameter discussed in
3087 this section. The {vm-type} has been defined as lb for load balancer.
3089 .. code-block:: yaml
3094 description: VM Name for lb VM 0
3097 description: Unique name for this VNF instance
3100 description: Unique ID for this VNF instance
3103 description: Unique name for this VNF Module instance
3106 description: Unique ID for this VNF Module instance
3109 description: Unique role for this VM
3114 type: OS::Nova::Server
3116 name: { get_param: lb_name_0 }
3119 vnf_name: { get_param: vnf_name }
3120 vnf_id: { get_param: vnf_id }
3121 vf_module_name: { get_param: vf_module_name }
3122 vf_module_id: { get_param: vf_module_id }
3125 Resource: OS::Neutron::Port - Parameters
3126 ----------------------------------------
3128 The resource OS::Neutron::Port is for managing Neutron ports (See
3129 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3134 Four properties of the resource OS::Neutron::Port that must follow the
3135 ONAP parameter naming convention. The four properties are:
3139 2. fixed\_ips, ip\_address
3141 3. fixed\_ips, subnet\_id
3143 4. allowed\_address\_pairs, ip\_address
3145 The parameters associated with these properties may reference an
3146 external network or internal network. External networks and internal
3147 networks are defined in `Networking`_.
3152 When the parameter references an external network
3154 - the parameter name must contain {network-role}
3156 - the parameter must not be enumerated in the Heat environment file
3158 - the parameter is classified as an ONAP Orchestration Parameter
3160 +----------------------------------------+-----------------------------------------------+--------------------------+
3161 | Property Name | ONAP Parameter Name | Parameter Type |
3162 +========================================+===============================================+==========================+
3163 | network | {network-role}\_net\_id | string |
3164 +----------------------------------------+-----------------------------------------------+--------------------------+
3165 | | {network-role}\_net\_name | string |
3166 +----------------------------------------+-----------------------------------------------+--------------------------+
3167 | fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
3168 +----------------------------------------+-----------------------------------------------+--------------------------+
3169 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3170 +----------------------------------------+-----------------------------------------------+--------------------------+
3171 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3172 +----------------------------------------+-----------------------------------------------+--------------------------+
3173 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3174 +----------------------------------------+-----------------------------------------------+--------------------------+
3175 | fixed\_ips, subnet | {network-role}\_subnet\_id | string |
3176 +----------------------------------------+-----------------------------------------------+--------------------------+
3177 | | {network-role}\_v6\_subnet\_id | string |
3178 +----------------------------------------+-----------------------------------------------+--------------------------+
3179 | allowed\_address\_pairs, ip\_address | {vm-type}\_{network-role}\_floating\_ip | string |
3180 +----------------------------------------+-----------------------------------------------+--------------------------+
3181 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
3182 +----------------------------------------+-----------------------------------------------+--------------------------+
3183 | | {vm-type}\_{network-role}\_ip\_{index} | string |
3184 +----------------------------------------+-----------------------------------------------+--------------------------+
3185 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3186 +----------------------------------------+-----------------------------------------------+--------------------------+
3187 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3188 +----------------------------------------+-----------------------------------------------+--------------------------+
3189 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3190 +----------------------------------------+-----------------------------------------------+--------------------------+
3192 Table 5: OS::Neutron::Port Resource Property Parameters (External
3198 When the parameter references an internal network
3200 - the parameter name must contain int\_{network-role}
3202 - the parameter may be enumerated in the environment file.
3204 +----------------------------------------+----------------------------------------------------+--------------------------+
3205 | Property | Parameter Name for Internal Networks | Parameter Type |
3206 +========================================+====================================================+==========================+
3207 | network | int\_{network-role}\_net\_id | string |
3208 +----------------------------------------+----------------------------------------------------+--------------------------+
3209 | | int\_{network-role}\_net\_name | string |
3210 +----------------------------------------+----------------------------------------------------+--------------------------+
3211 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3212 +----------------------------------------+----------------------------------------------------+--------------------------+
3213 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3214 +----------------------------------------+----------------------------------------------------+--------------------------+
3215 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3216 +----------------------------------------+----------------------------------------------------+--------------------------+
3217 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3218 +----------------------------------------+----------------------------------------------------+--------------------------+
3219 | fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
3220 +----------------------------------------+----------------------------------------------------+--------------------------+
3221 | | int\_{network-role}\_v6\_subnet\_id | string |
3222 +----------------------------------------+----------------------------------------------------+--------------------------+
3223 | allowed\_address\_pairs, ip\_address | {vm-type}\_int\_{network-role}\_floating\_ip | string |
3224 +----------------------------------------+----------------------------------------------------+--------------------------+
3225 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
3226 +----------------------------------------+----------------------------------------------------+--------------------------+
3227 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3228 +----------------------------------------+----------------------------------------------------+--------------------------+
3229 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3230 +----------------------------------------+----------------------------------------------------+--------------------------+
3231 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3232 +----------------------------------------+----------------------------------------------------+--------------------------+
3233 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3234 +----------------------------------------+----------------------------------------------------+--------------------------+
3236 Table 6: Port Resource Property Parameters (Internal Networks)
3241 The property networks in the resource OS::Neutron::Port must be
3242 referenced by Neutron Network ID, a UUID value, or by the network name
3243 defined in OpenStack.
3248 When the parameter associated with the property network is referencing
3249 an “external” network, the parameter must adhere to the following naming
3250 convention in the Heat Orchestration Template
3252 - {network-role}\_net\_id for the Neutron network ID
3254 - {network-role}\_net\_name for the network name in OpenStack
3256 The parameter must be declared as type: string
3258 The parameter must not be enumerated in the Heat environment file.
3260 *Example Parameter Definition*
3262 .. code-block:: yaml
3265 {network-role}_net_id:
3267 description: Neutron UUID for the {network-role} network
3268 {network-role}_net_name:
3270 description: Neutron name for the {network-role} network
3272 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3273 that has only one subnet*
3275 In this example, the {network-role} has been defined as oam to represent
3276 an oam network and the {vm-type} has been defined as lb for load
3277 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3278 to assign IP addresses.
3280 .. code-block:: yaml
3285 description: Neutron UUID for the oam network
3289 type: OS::Neutron::Port
3290 network: { get_param: oam_net_id }
3295 When the parameter associated with the property network is referencing
3296 an “internal” network, the parameter must adhere to the following naming
3299 - int\_{network-role}\_net\_id for the Neutron network ID
3301 - int\_{network-role}\_net\_name for the network name in OpenStack
3303 The parameter must be declared as type: string
3305 The assumption is that internal networks are created in the base module.
3306 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3307 Base Module Output Parameter) to the incremental modules. In the
3308 incremental modules, it will be defined as input parameter.
3310 *Example Parameter Definition*
3312 .. code-block:: yaml
3315 int_{network-role}_net_id:
3317 description: Neutron UUID for the {network-role} network
3318 int_{network-role}_net_name:
3320 description: Neutron name for the {network-role} network
3322 Property: fixed\_ips, Map Property: subnet\_id
3323 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3325 The property fixed\_ips is used to assign IPs to a port. The Map
3326 Property subnet\_id specifies the subnet the IP is assigned from.
3328 The property fixed\_ips and Map Property subnet\_id must be used if a
3329 Cloud (i.e., DHCP) IP address assignment is being requested and the
3330 Cloud IP address assignment is targeted at a specific subnet when two or
3333 The property fixed\_ips and Map Property subnet\_id should not be used
3334 if all IP assignments are fixed, or if the Cloud IP address assignment
3335 does not target a specific subnet or there is only one subnet.
3337 Note that DHCP assignment of IP addresses is also referred to as cloud
3338 assigned IP addresses.
3340 Subnet of an External Networks
3341 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3343 When the parameter is referencing a subnet of an “external” network, the
3344 property fixed\_ips and Map Property subnet\_id parameter must adhere to
3345 the following naming convention.
3347 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3349 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3351 The parameter must be declared as type: string
3353 The parameter must not be enumerated in the Heat environment file.
3355 *Example Parameter Definition*
3357 .. code-block:: yaml
3360 {network-role}_subnet_id:
3362 description: Neutron subnet UUID for the {network-role} network
3364 {network-role}_v6_subnet_id:
3366 description: Neutron subnet UUID for the {network-role} network
3368 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3369 that has two or more subnets subnet:*
3371 In this example, the {network-role} has been defined as oam to represent
3372 an oam network and the {vm-type} has been defined as lb for load
3373 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3374 to assign IP addresses.
3376 .. code-block:: yaml
3381 description: Neutron UUID for the oam network
3385 description: Neutron subnet UUID for the oam network
3389 type: OS::Neutron::Port
3390 network: { get_param: oam_net_id }
3392 - subnet_id: { get_param: oam_subnet_id }
3394 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3395 address assigned to a network that has at least one IPv4 subnet and one
3398 In this example, the {network-role} has been defined as oam to represent
3399 an oam network and the {vm-type} has been defined as lb for load
3402 .. code-block:: yaml
3407 description: Neutron UUID for the oam network
3411 description: Neutron subnet UUID for the oam network
3415 description: Neutron subnet UUID for the oam network
3419 type: OS::Neutron::Port
3421 network: { get_param: oam_net_id }
3423 - subnet_id: { get_param: oam_subnet_id }
3424 - subnet_id: { get_param: oam_v6_subnet_id }
3429 When the parameter is referencing the subnet of an “internal” network,
3430 the property fixed\_ips and Map Property subnet\_id parameter must
3431 adhere to the following naming convention.
3433 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3435 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3437 The parameter must be declared as type: string
3439 The assumption is that internal networks are created in the base module.
3440 The Neutron subnet network ID will be passed as an output parameter
3441 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3442 the incremental modules, it will be defined as input parameter.
3444 *Example Parameter Definition*
3446 .. code-block:: yaml
3449 int_{network-role}_subnet_id:
3451 description: Neutron subnet UUID for the {network-role} network
3453 int_{network-role}_v6_subnet_id:
3455 description: Neutron subnet UUID for the {network-role} network
3457 Property: fixed\_ips, Map Property: ip\_address
3458 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3460 The property fixed\_ips is used to assign IPs to a port. The Map
3461 Property ip\_address specifies the IP address to be assigned to the
3464 The property fixed\_ips and Map Property ip\_address must be used when
3465 statically assigning one or more IP addresses to a port. This is also
3466 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3467 the IP address assignment.
3469 An IP address is assigned to a port on a VM (referenced by {vm-type})
3470 that is connected to an external network (referenced by {network-role})
3471 or internal network (referenced by int\_{network-role}).
3473 When a SDN-C IP assignment is made to a port connected to an external
3474 network, the parameter name must contain {vm-type} and {network-role}.
3476 When a SDN-C IP assignment is made to a port connected to an internal
3477 network, the parameter name must contain {vm-type} and
3478 int\_{network-role}.
3480 IP Address Assignments on External Networks
3481 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3483 When the property fixed\_ips and Map Property ip\_address is used to
3484 assign IP addresses to an external network, the parameter name is
3485 dependent on the parameter type (comma\_delimited\_list or string) and
3486 IP address type (IPv4 or IPv6).
3488 When the parameter for property fixed\_ips and Map Property ip\_address
3489 is declared type: comma\_delimited\_list, the parameter must adhere to
3490 the following naming convention
3492 - {vm-type}\_{network-role}\_ips for IPv4 address
3494 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3496 Each element in the IP list should be assigned to successive instances
3497 of {vm-type} on {network-role}.
3499 The parameter must not be enumerated in the Heat environment file.
3501 *Example Parameter Definition*
3503 .. code-block:: yaml
3507 {vm-type}_{network-role}_ips:
3508 type: comma_delimited_list
3509 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3511 {vm-type}_{network-role}_v6_ips:
3512 type: comma_delimited_list
3513 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3515 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3516 Assignments to an external network*
3518 In this example, the {network-role} has been defined as oam to represent
3519 an oam network and the {vm-type} has been defined as db for database.
3521 .. code-block:: yaml
3526 description: Neutron UUID for a oam network
3529 type: comma_delimited_list
3530 description: Fixed IPv4 assignments for db VMs on the oam network
3533 type: comma_delimited_list
3534 description: Fixed IPv6 assignments for db VMs on the oam network
3538 type: OS::Neutron::Port
3539 network: { get_param: oam_net_id }
3540 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3543 type: OS::Neutron::Port
3545 network: { get_param: oam_net_id }
3547 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3548 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3550 When the parameter for property fixed\_ips and Map Property ip\_address
3551 is declared type: string, the parameter must adhere to the following
3554 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3556 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3558 The value for {index} must start at zero (0) and increment by one.
3560 The parameter must not be enumerated in the Heat environment file.
3562 *Example Parameter Definition*
3564 .. code-block:: yaml
3567 {vm-type}_{network-role}_ip_{index}:
3569 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3571 {vm-type}_{network-role}_v6_ip_{index}:
3573 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3575 *Example: string parameters for IPv4 and IPv6 Address Assignments to an external network*
3577 In this example, the {network-role} has been defined as “oam” to
3578 represent an oam network and the {vm-type} has been defined as “db” for
3581 .. code-block:: yaml
3586 description: Neutron UUID for an OAM network
3590 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3594 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3598 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3602 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3606 type: OS::Neutron::Port
3608 network: { get_param: oam_net_id }
3609 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3612 type: OS::Neutron::Port
3614 network: { get_param: oam_net_id }
3616 - “ip_address”: {get_param: db_oam_ip_1}}]
3617 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3619 IP Address Assignment on Internal Networks
3620 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3622 When the property fixed\_ips and Map Property ip\_address is used to
3623 assign IP addresses to an internal network, the parameter name is
3624 dependent on the parameter type (comma\_delimited\_list or string) and
3625 IP address type (IPv4 or IPv6).
3627 When the parameter for property fixed\_ips and Map Property ip\_address
3628 is declared type: comma\_delimited\_list, the parameter must adhere to
3629 the following naming convention
3631 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3633 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3635 Each element in the IP list should be assigned to successive instances
3636 of {vm-type} on {network-role}.
3638 The parameter must be enumerated in the Heat environment file. Since an
3639 internal network is local to the VNF, IP addresses can be re-used at
3642 *Example Parameter Definition*
3644 .. code-block:: yaml
3648 {vm-type}_int_{network-role}_ips:
3649 type: comma_delimited_list
3650 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3652 {vm-type}_int_{network-role}_v6_ips:
3653 type: comma_delimited_list
3654 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3656 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3657 Assignments to an internal network*
3659 In this example, the {network-role} has been defined as oam\_int to
3660 represent an oam network internal to the vnf. The role oam\_int was
3661 picked to differentiate from an external oam network with a
3662 {network-role} of oam. The {vm-type} has been defined as db for
3665 .. code-block:: yaml
3670 description: Neutron UUID for the oam internal network
3673 type: comma_delimited_list
3674 description: Fixed IPv4 assignments for db VMs on the oam internal network
3676 db_int_oam_int_v6_ips:
3677 type: comma_delimited_list
3678 description: Fixed IPv6 assignments for db VMs on the oam internal network
3682 type: OS::Neutron::Port
3684 network: { get_param: int_oam_int_net_id }
3685 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3688 type: OS::Neutron::Port
3690 network: { get_param: int_oam_int_net_id }
3692 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3693 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3695 When the parameter for property fixed\_ips and Map Property ip\_address
3696 is declared type: string, the parameter must adhere to the following
3699 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3701 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3703 The value for {index} must start at zero (0) and increment by one.
3705 The parameter must be enumerated in the Heat environment file. Since an
3706 internal network is local to the VNF, IP addresses can be re-used at
3709 *Example Parameter Definition*
3711 .. code-block:: yaml
3715 {vm-type}_int_{network-role}_ip_{index}:
3717 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3719 {vm-type}_int_{network-role}_v6_ip_{index}:
3721 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3723 *Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
3725 In this example, the {network-role} has been defined as oam\_int to
3726 represent an oam network internal to the vnf. The role oam\_int was
3727 picked to differentiate from an external oam network with a
3728 {network-role} of oam. The {vm-type} has been defined as db for
3731 .. code-block:: yaml
3736 description: Neutron UUID for an OAM internal network
3740 description: Fixed IPv4 assignment for db VM on the oam_int network
3744 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3748 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3752 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3756 type: OS::Neutron::Port
3758 network: { get_param: int_oam_int_net_id }
3759 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3762 type: OS::Neutron::Port
3764 network: { get_param: int_oam_int_net_id }
3766 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3767 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3769 Property: allowed\_address\_pairs, Map Property: ip\_address
3770 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3772 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3773 allows the user to specify a mac\_address and/or ip\_address that will
3774 pass through a port regardless of subnet. This enables the use of
3775 protocols such as VRRP, which floats an IP address between two instances
3776 to enable fast data plane failover. The map property ip\_address
3777 specifies the IP address.
3779 The allowed\_address\_pairs is an optional property. It is not required.
3781 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3782 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3783 and {network-role}/int\_{network-role} combination.
3785 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3786 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3787 and {network-role}/int\_{network-role} combination.
3789 Note that the management of these IP addresses (i.e. transferring
3790 ownership between active and standby VMs) is the responsibility of the
3793 Note that these parameters are **not** intended to represent Neutron
3794 “Floating IP” resources, for which OpenStack manages a pool of public IP
3795 addresses that are mapped to specific VM ports. In that case, the
3796 individual VMs are not even aware of the public IPs, and all assignment
3797 of public IPs to VMs is via OpenStack commands. ONAP does not support
3798 Neutron-style Floating IPs.
3803 When the parameter is referencing an “external” network, the property
3804 allowed\_address\_pairs and Map Property ip\_address parameter must
3805 adhere to the following naming convention.
3807 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3809 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3811 The parameter must be declared as type: string
3813 The parameter must not be enumerated in the Heat environment file.
3815 *Example Parameter Definition*
3817 .. code-block:: yaml
3821 {vm-type}_{network-role}_floating_ip:
3823 description: VIP for {vm-type} VMs on the {network-role} network
3825 {vm-type}_{network-role}_floating_v6_ip:
3827 description: VIP for {vm-type} VMs on the {network-role} network
3831 In this example, the {network-role} has been defined as oam to represent
3832 an oam network and the {vm-type} has been defined as db for database.
3834 .. code-block:: yaml
3839 description: Neutron UUID for the oam network
3842 type: comma_delimited_list
3843 description: Fixed IPs for db VMs on the oam network
3847 description: VIP IP for db VMs on the oam network
3851 type: OS::Neutron::Port
3853 network: { get_param: oam_net_id }
3854 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
3855 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3858 type: OS::Neutron::Port
3860 network: { get_param: oam_net_id }
3861 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
3862 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3867 When the parameter is referencing an “internal” network, the property
3868 allowed\_address\_pairs and Map Property ip\_address parameter must
3869 adhere to the following naming convention.
3871 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
3873 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
3875 The parameter must be declared as type: string
3877 The parameter must be enumerated in the Heat environment file.
3879 *Example Parameter Definition*
3881 .. code-block:: yaml
3885 {vm-type}_int_{network-role}_floating_ip:
3887 description: VIP for {vm-type} VMs on the int_{network-role} network
3889 {vm-type}_int_{network-role}_floating_v6_ip:
3891 description: VIP for {vm-type} VMs on the int_{network-role} network
3893 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
3894 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3896 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
3897 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
3899 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
3900 one allowed address pair IPv6 address per {vm-type} and {network-role}
3903 If there is a need for multiple allowed address pair IPs for a given
3904 {vm-type} and {network-role} combination within a VNF, then the
3905 parameter names defined for the property fixed\_ips and Map Property
3906 ip\_address should be used with the allowed\_address\_pairs property.
3907 The examples below illustrate this.
3909 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
3911 In this example, there are two administrative VM pairs. Each pair has
3912 one VIP. The {network-role} has been defined as oam to represent an oam
3913 network and the {vm-type} has been defined as admin for an
3916 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
3917 VIP, [admin\_oam\_ips,2]
3919 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
3920 VIP, [admin\_oam\_ips,5]
3922 .. code-block:: yaml
3927 description: Neutron UUID for the oam network
3929 type: comma_delimited_list
3930 description: Fixed IP assignments for admin VMs on the oam network
3935 type: OS::Neutron::Port
3937 network: { get_param: oam_net_id }
3938 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
3939 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3942 type: OS::Neutron::Port
3944 network: { get_param: oam_net_id }
3945 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
3946 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3949 type: OS::Neutron::Port
3951 network: { get_param: oam_net_id }
3952 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
3953 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3956 type: OS::Neutron::Port
3958 network: { get_param: oam_net_id }
3959 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
3960 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3962 *Example: A VNF has two load balancers. The pair of load balancers share
3965 In this example, there is one load balancer pairs. The pair has two
3966 VIPs. The {network-role} has been defined as oam to represent an oam
3967 network and the {vm-type} has been defined as lb for a load balancer VM.
3969 .. code-block:: yaml
3973 type: OS::Neutron::Port
3975 network: { get_param: oam_net_id }
3976 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
3977 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3980 type: OS::Neutron::Port
3982 network: { get_param: oam_net_id }
3983 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
3984 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
3986 As a general rule, provide the fixed IPs for the VMs indexed first in
3987 the CDL and then the VIPs as shown in the examples above.
3989 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
3990 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3992 The following items must be taken into consideration when designing Heat
3993 Orchestration Templates that expect ONAP’s SDN-C to assign
3994 allowed\_address\_pair IP addresses via automation.
3996 The VMs must be of the same {vm-type}.
3998 The VMs must be created in the same module (base or incremental).
4000 Resource Property “name”
4001 ------------------------
4003 The parameter naming convention of the property name for the resource
4004 OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
4006 This section provides the requirements how the property name for non
4007 OS::Nova::Server resources must be defined when the property is used.
4008 Not all resources require the property name (e.g., it is optional) and
4009 some resources do not support the property.
4011 When the property name for a non OS::Nova::Server resources is defined
4012 in a Heat Orchestration Template, the intrinsic function str\_replace
4013 must be used in conjunction with the ONAP supplied metadata parameter
4014 vnf\_name to generate a unique value. This prevents the enumeration of a
4015 unique value for the property name in a per instance environment file.
4019 - In most cases, only the use of the metadata value vnf\_name is
4020 required to create a unique property name
4022 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4023 may also be used in the str\_replace construct to generate a unique
4024 name when the vnf\_name does not provide uniqueness
4026 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4028 .. code-block:: yaml
4032 type: OS::Neutron::SecurityGroup
4034 description: vDNS security group
4037 template: VNF_NAME_sec_grp_DNS
4039 VNF_NAME: {get_param: vnf_name}
4043 *Example: Property name for resource* OS::Cinder::Volume
4045 .. code-block:: yaml
4049 type: OS::Cinder::Volume
4051 description: Cinder Volume
4054 template: VNF_NAME_STACK_NAME_dns_volume
4056 VNF_NAME: {get_param: vnf_name}
4057 STACK_NAME: { get_param: 'OS::stack_name' }
4060 Contrail Issue with Values for the Property Name
4061 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4063 The Contrail GUI has a limitation displaying special characters. The
4064 issue is documented in
4065 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4066 recommended that special characters be avoided. However, if special
4067 characters must be used, note that for the following resources:
4081 the only special characters supported are:
4083 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4085 ONAP Output Parameter Names
4086 ---------------------------
4088 ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
4090 ONAP Base Module Output Parameters:
4091 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4093 ONAP Base Module Output Parameters do not have an explicit naming
4094 convention. The parameter name must contain {vm-type} and {network-role}
4097 ONAP Volume Template Output Parameters:
4098 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4100 ONAP Base Module Output Parameters do not have an explicit naming
4101 convention. The parameter name must contain {vm-type} when appropriate.
4103 Predefined Output Parameters
4104 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4106 ONAP currently defines one predefined output parameter the OAM
4107 Management IP Addresses.
4109 OAM Management IP Addresses
4110 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
4112 A VNF may have a management interface for application controllers to
4113 interact with and configure the VNF. Typically, this will be via a
4114 specific VM that performs a VNF administration function. The IP address
4115 of this interface must be captured and inventoried by ONAP. The IP
4116 address might be a VIP if the VNF contains an HA pair of management VMs,
4117 or may be a single IP address assigned to one VM.
4119 The Heat template may define either (or both) of the following Output
4120 parameters to identify the management IP address.
4122 - oam\_management\_v4\_address
4124 - oam\_management\_v6\_address
4128 - The use of this output parameters are optional.
4130 - The Management IP Address should be defined only once per VNF, so it
4131 must only appear in one Module template
4133 - If a fixed IP for the admin VM is passed as an input parameter, it
4134 may be echoed in the output parameters. In this case, a IPv4 and/or
4135 IPv6 parameter must be defined in the parameter section of the YAML
4136 Heat template. The parameter maybe named oam\_management\_v4\_address
4137 and/or oam\_management\_v6\_address or may be named differently.
4139 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4140 from the resource attributes. In this case,
4141 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4142 not be defined in the parameter section of the YAML Heat template.
4144 *Example: SDN-C Assigned IP Address echoed as*
4145 oam\_management\_v4\_address
4147 .. code-block:: yaml
4152 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4156 admin_oam_net_0_port:
4157 type: OS::Neutron::Port
4161 template: VNF_NAME_admin_oam_net_0_port
4163 VNF_NAME: {get_param: vnf_name}
4164 network: { get_param: oam_net_id }
4165 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4166 security_groups: [{ get_param: security_group }]
4169 type: OS::Nova::Server
4171 name: { get_param: admin_names }
4172 image: { get_param: admin_image_name }
4173 flavor: { get_param: admin_flavor_name }
4174 availability_zone: { get_param: availability_zone_0 }
4176 - port: { get_resource: admin_oam_net_0_port }
4178 vnf_id: { get_param: vnf_id }
4179 vf_module_id: { get_param: vf_module_id }
4180 vnf_name: {get_param: vnf_name }
4182 oam_management_v4_address:
4183 value: {get_param: admin_oam_ip_0 }
4185 *Example: Cloud Assigned IP Address output as*
4186 oam\_management\_v4\_address
4188 .. code-block:: yaml
4193 admin_oam_net_0_port:
4194 type: OS::Neutron::Port
4198 template: VNF_NAME_admin_oam_net_0_port
4200 VNF_NAME: {get_param: vnf_name}
4201 network: { get_param: oam_net_id }
4202 security_groups: [{ get_param: security_group }]
4205 type: OS::Nova::Server
4207 name: { get_param: admin_names }
4208 image: { get_param: admin_image_name }
4209 flavor: { get_param: admin_flavor_name }
4210 availability_zone: { get_param: availability_zone_0 }
4212 - port: { get_resource: admin_oam_net_0_port }
4214 vnf_id: { get_param: vnf_id }
4215 vf_module_id: { get_param: vf_module_id }
4216 vnf_name: {get_param: vnf_name }
4219 oam_management_v4_address:
4220 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4222 Contrail Resource Parameters
4223 ----------------------------
4225 ONAP requires the parameter names of certain Contrail Resources to
4226 follow specific naming conventions. This section provides these
4229 Contrail Network Parameters
4230 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4232 Contrail based resources may require references to a Contrail network
4233 using the network FQDN.
4238 When the parameter associated with the Contrail Network is referencing
4239 an “external” network, the parameter must adhere to the following naming
4240 convention in the Heat Orchestration Template
4242 - {network-role}\_net\_fqdn
4244 The parameter must be declared as type: string
4246 The parameter must not be enumerated in the Heat environment file.
4248 *Example: Parameter declaration*
4250 .. code-block:: yaml
4253 {network-role}_net_fqdn:
4255 description: Contrail FQDN for the {network-role} network
4257 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4258 Reference to a Network FQDN.*
4260 In this example, the {network-role} has been defined as oam to represent
4261 an oam network and the {vm-type} has been defined as fw for firewall.
4262 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4263 virtual\_network\_refs references a contrail network FQDN.
4265 .. code-block:: yaml
4268 type: OS::ContrailV2::VirtualMachineInterface
4272 template: VM_NAME_virtual_machine_interface_1
4274 VM_NAME: { get_param: fw_name_0 }
4275 virtual_machine_interface_properties:
4276 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4277 virtual_network_refs:
4278 - get_param: oam_net_fqdn
4279 security_group_refs:
4280 - get_param: fw_sec_grp_id
4282 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4283 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4285 The parameter associated with the resource
4286 OS::ContrailV2::InterfaceRouteTable property
4287 interface\_route\_table\_routes, map property
4288 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4291 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4292 in the Heat Orchestration Template.
4294 The parameter must be declared as type: json
4296 The parameter supports IP addresses in the format:
4298 1. Host IP Address (e.g., 10.10.10.10)
4300 2. CIDR Notation format (e.g., 10.0.0.0/28)
4302 The parameter must not be enumerated in the Heat environment file.
4304 *Example Parameter Definition*
4306 .. code-block:: yaml
4309 {vm-type}_{network-role}_route_prefixes:
4311 description: JSON list of Contrail Interface Route Table route prefixes
4315 .. code-block:: yaml
4320 description: Unique name for this VF instance
4321 fw_int_fw_route_prefixes:
4323 description: prefix for the ServiceInstance InterfaceRouteTable
4324 int_fw_dns_trusted_interface_type:
4326 description: service_interface_type for ServiceInstance
4329 type: OS::ContrailV2::InterfaceRouteTable
4330 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4334 template: VNF_NAME_interface_route_table
4336 VNF_NAME: { get_param: vnf_name }
4337 interface_route_table_routes:
4338 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4339 service_instance_refs:
4340 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4341 service_instance_refs_data:
4342 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4344 Parameter Names in Contrail Resources
4345 -------------------------------------
4347 Contrail Heat resource properties will use, when appropriate, the same
4348 naming convention as OpenStack Heat resources. For example, the resource
4349 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4350 convention is identical to properties in OS::Neutron::Port.
4352 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4353 instance\_ip\_address*
4355 The property instance\_ip\_address uses the same parameter naming
4356 convention as the property fixed\_ips and Map Property ip\_address in
4357 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4358 Address. The {network-role} has been defined as oam\_protected to
4359 represent an oam protected network and the {vm-type} has been defined as
4362 .. code-block:: yaml
4364 CMD_FW_OAM_PROTECTED_RII:
4365 type: OS::ContrailV2::InstanceIp
4367 - FW_OAM_PROTECTED_RVMI
4369 virtual_machine_interface_refs:
4370 - get_resource: FW_OAM_PROTECTED_RVMI
4371 virtual_network_refs:
4372 - get_param: oam_protected_net_fqdn
4373 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4375 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4378 The property instance\_ip\_address uses the same parameter naming
4379 convention as the property fixed\_ips and Map Property subnet\_id in
4380 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4381 Address. The {network-role} has been defined as “oam\_protected” to
4382 represent an oam protected network and the {vm-type} has been defined as
4385 .. code-block:: yaml
4387 CMD_FW_SGI_PROTECTED_RII:
4388 type: OS::ContrailV2::InstanceIp
4390 - FW_OAM_PROTECTED_RVMI
4392 virtual_machine_interface_refs:
4393 - get_resource: FW_OAM_PROTECTED_RVMI
4394 virtual_network_refs:
4395 - get_param: oam_protected_net_fqdn
4396 subnet_uuid: { get_param: oam_protected_subnet_id }
4398 Cinder Volume Templates
4399 -----------------------
4401 ONAP supports the independent deployment of a Cinder volume via separate
4402 Heat Orchestration Templates, the Cinder Volume module. This allows the
4403 volume to persist after VNF deletion so that they can be reused on
4404 another instance (e.g., during a failover activity).
4406 A Base Module or Incremental Module may have a corresponding volume
4407 module. Use of separate volume modules is optional. A Cinder volume may
4408 be embedded within the Base Module or Incremental Module if persistence
4411 If a VNF Base Module or Incremental Module has an independent volume
4412 module, the scope of volume templates must be 1:1 with Base module or
4413 Incremental module. A single volume module must create only the volumes
4414 required by a single Incremental module or Base module.
4416 The following rules apply to independent volume Heat templates:
4418 - Cinder volumes must be created in a separate Heat Orchestration
4419 Template from the Base Module or Incremental Module.
4421 - A single Cinder volume module must include all Cinder volumes
4422 needed by the Base/Incremental module.
4424 - The volume template must define “outputs” for each Cinder volume
4425 resource universally unique identifier (UUID) (i.e. ONAP Volume
4426 Template Output Parameters).
4428 - The VNF Incremental Module or Base Module must define input
4429 parameters that match each Volume output parameter (i.e., ONAP Volume
4430 Template Output Parameters).
4432 - ONAP will supply the volume template outputs automatically to the
4433 bases/incremental template input parameters.
4435 - Volume modules may utilize nested Heat templates.
4437 *Examples: Volume Template*
4439 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4440 creates an independent Cinder volume for a VM in the module
4441 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4442 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4443 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4444 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4445 output statement and provides the value to the incremental module.
4447 Note that the example below is not a complete Heat Orchestration
4448 Template. The {vm-type} has been defined as “lb” for load balancer
4450 incremental\_volume.yaml
4452 .. code-block:: yaml
4463 type: OS::Cinder::Volume
4467 template: VNF_NAME_volume_0
4469 VNF_NAME: { get_param: vnf_name }
4470 size: {get_param: dns_volume_size_0}
4475 value: {get_resource: dns_volume_0}
4481 .. code-block:: yaml
4492 type: OS::Nova::Server
4494 name: {get_param: dns_name_0}
4499 type: OS::Cinder::VolumeAttachment
4501 instance_uuid: { get_resource: lb_0 }
4502 volume_id: { get_param: lb_volume_id_0 }
4504 ONAP Support of Environment Files
4505 ---------------------------------
4507 The use of an environment file in OpenStack is optional. In ONAP, it is
4508 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
4509 corresponding environment file, even if no parameters are required to be
4512 (Note that ONAP, the open source version of ONAP, does not
4513 programmatically enforce the use of an environment file.)
4515 A Base Module Heat Orchestration Template must have a corresponding
4518 An Incremental Module Heat Orchestration Template must have a
4519 corresponding environment file.
4521 A Cinder Volume Module Heat Orchestration Template must have a
4522 corresponding environment file.
4524 A nested heat template must not have an environment file; OpenStack does
4527 The environment file must contain parameter values for the ONAP
4528 Orchestration Constants and VNF Orchestration Constants. These
4529 parameters are identical across all instances of a VNF type, and
4530 expected to change infrequently. The ONAP Orchestration Constants are
4531 associated with OS::Nova::Server image and flavor properties (See
4532 `Property: image`_ and `Property: flavor`_). Examples of VNF Orchestration Constants are the networking
4533 parameters associated with an internal network (e.g., private IP ranges)
4534 and Cinder volume sizes.
4536 The environment file must not contain parameter values for parameters
4537 that are instance specific (ONAP Orchestration Parameters, VNF
4538 Orchestration Parameters). These parameters are supplied to the Heat by
4539 ONAP at orchestration time.
4541 SDC Treatment of Environment Files
4542 ----------------------------------
4544 Parameter values enumerated in the environment file are used by SDC as
4545 the default value. However, the SDC user may use the SDC GUI to
4546 overwrite the default values in the environment file.
4548 SDC generates a new environment file for distribution to MSO based on
4549 the uploaded environment file and the user provided GUI updates. The
4550 user uploaded environment file is discarded when the new file is
4551 created. Note that if the user did not change any values via GUI
4552 updates, the SDC generated environment file will contain the same values
4553 as the uploaded file.
4555 Use of Environment Files when using OpenStack “heat stack-create” CLI
4556 ---------------------------------------------------------------------
4558 When ONAP is instantiating the Heat Orchestration Template, certain
4559 parameter must not be enumerated in the environment file. This document
4560 provides the details of what parameters should not be enumerated.
4562 If the Heat Orchestration Template is to be instantiated from the
4563 OpenStack Command Line Interface (CLI) using the command “heat
4564 stack-create”, all parameters must be enumerated in the environment
4567 Heat Template Constructs
4568 ------------------------
4570 Nested Heat Templates
4571 ---------------------
4573 ONAP supports nested Heat templates per the OpenStack specifications.
4574 Nested templates may be suitable for larger VNFs that contain many
4575 repeated instances of the same VM type(s). A common usage pattern is to
4576 create a nested template for each {vm-type} along with its supporting
4577 resources. The VNF module may then reference these component templates
4578 either statically by repeated definition or dynamically by using the
4579 resource OS::Heat::ResourceGroup.
4581 Nested Heat Template Requirements
4582 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4584 ONAP supports nested Heat Orchestration Templates. A Base Module,
4585 Incremental Module, and Cinder Volume Module may use nested heat.
4587 A Heat Orchestration Template may reference the nested heat statically
4588 by repeated definition.
4590 A Heat Orchestration Template may reference the nested heat dynamically
4591 using the resource OS::Heat::ResourceGroup.
4593 A Heat Orchestration template must have no more than three levels of
4594 nesting. ONAP supports a maximum of three levels.
4596 Nested heat templates must be referenced by file name. The use of
4597 resource\_registry in the environment file is not supported and must not
4600 A nested heat yaml file must have a unique file names within the scope
4603 ONAP does not support a directory hierarchy for nested templates. All
4604 templates must be in a single, flat directory (per VNF)
4606 A nested heat template may be used by any module within a given VNF.
4610 - Constrains must not be defined for any parameter enumerated in a
4611 nested heat template.
4613 - All parameters defined in nested heat must be passed in as properties
4614 of the resource calling the nested yaml file.
4616 - When OS::Nova::Server metadata parameters are past into a nested heat
4617 template, the parameter names must not change
4619 - With nested templates, outputs are required to expose any resource
4620 properties of the child templates to the parent template. Those would
4621 not explicitly be declared as parameters but simply referenced as
4622 get\_attribute targets against the “parent” resource.
4624 Nested Heat Template Example: Static
4625 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4629 .. code-block:: yaml
4635 dns_image_name: { get_param: dns_image_name }
4636 dns_flavor_name: { get_param: dns_flavor_name }
4637 availability_zone: { get_param: availability_zone_0 }
4638 security_group: { get_param: DNS_shared_sec_grp_id }
4639 oam_net_id: { get_param: oam_protected_net_id }
4640 dns_oam_ip: { get_param: dns_oam_ip_0 }
4641 dns_name: { get_param: dns_name_0 }
4642 vnf_name: { get_param: vnf_name }
4643 vnf_id: { get_param: vnf_id }
4644 vf_module_id: {get_param: vf_module_id}
4649 dns_image_name: { get_param: dns_image_name }
4650 dns_flavor_name: { get_param: dns_flavor_name }
4651 availability_zone: { get_param: availability_zone_1 }
4652 security_group: { get_param: DNS_shared_sec_grp_id }
4653 oam_net_id: { get_param: oam_protected_net_id }
4654 dns_oam_ip: { get_param: dns_oam_ip_1 }
4655 dns_name: { get_param: dns_name_1 }
4656 vnf_name: { get_param: vnf_name }
4657 vnf_id: { get_param: vnf_id }
4658 vf_module_id: {get_param: vf_module_id}
4662 .. code-block:: yaml
4665 type: OS::Neutron::Port
4669 template: VNF_NAME_dns_oam_port
4671 VNF_NAME: {get_param: vnf_name}
4672 network: { get_param: oam_net_id }
4673 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4674 security_groups: [{ get_param: security_group }]
4677 type: OS::Nova::Server
4679 name: { get_param: dns_names }
4680 image: { get_param: dns_image_name }
4681 flavor: { get_param: dns_flavor_name }
4682 availability_zone: { get_param: availability_zone }
4684 - port: { get_resource: dns_oam_0_port }
4686 vnf_id: { get_param: vnf_id }
4687 vf_module_id: { get_param: vf_module_id }
4688 vnf_name {get_param: vnf_name }
4690 Use of Heat ResourceGroup
4691 ~~~~~~~~~~~~~~~~~~~~~~~~~
4693 The OS::Heat::ResourceGroup is a useful Heat element for creating
4694 multiple instances of a given resource or collection of resources.
4695 Typically it is used with a nested Heat template, to create, for
4696 example, a set of identical OS::Nova::Server resources plus their
4697 related OS::Neutron::Port resources via a single resource in a master
4700 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4701 template that creates multiple instances of the same VM type.
4703 However, there are important caveats to be aware of:
4705 ResourceGroup does not deal with structured parameters
4706 (comma-delimited-list and json) as one might typically expect. In
4707 particular, when using a list-based parameter, where each list element
4708 corresponds to one instance of the ResourceGroup, it is not possible to
4709 use the intrinsic “loop variable” %index% in the ResourceGroup
4712 For instance, the following is **not** valid Heat for ResourceGroup:
4714 .. code-block:: yaml
4716 type: OS::Heat::ResourceGroup
4718 type: my_nested_vm_template.yaml
4720 name: {get_param: [vm_name_list, %index%]}
4722 Although this appears to use the nth entry of the vm\_name\_list list
4723 for the nth element of the ResourceGroup, it will in fact result in a
4724 Heat exception. When parameters are provided as a list (one for each
4725 element of a ResourceGroup), you must pass the complete parameter to the
4726 nested template along with the current index as separate parameters.
4728 Below is an example of an **acceptable** Heat Syntax for a
4731 .. code-block:: yaml
4733 type: OS::Heat::ResourceGroup
4735 type: my_nested_vm_template.yaml
4737 names: {get_param: vm_name_list}
4740 You can then reference within the nested template as:
4742 { get\_param: [names, {get\_param: index} ] }
4744 ResourceGroup Property count
4745 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4747 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4748 (even if the value is one) and that the value must be enumerated in the
4749 environment file. This is required for ONAP to build the TOSCA model for
4752 .. code-block:: yaml
4754 type: OS::Heat::ResourceGroup
4756 count: { get_param: count }
4759 type: my_nested_vm_template.yaml
4761 names: {get_param: vm_name_list}
4764 Availability Zone and ResourceGroups
4765 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4767 The resource OS::Heat::ResourceGroup and the property availability\_zone
4768 has been an “issue” with a few VNFs since ONAP only supports
4769 availability\_zone as a string parameter and not a
4770 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4771 to create Virtual Machines in more than one availability zone.
4773 There are numerous solutions to this issue. Below are two suggested
4776 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4777 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4778 availability\_zones by using the intrinsic function list\_join.
4780 .. code-block:: yaml
4783 type: OS::Heat::ResourceGroup
4785 count: { get_param: node_count }
4791 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4795 .. code-block:: yaml
4798 avaialability_zones:
4799 type: comma_delimited_list
4804 type: OS::Nova::Server
4806 name: { get_param: [ dns_names, get_param: index ] }
4807 image: { get_param: dns_image_name }
4808 flavor: { get_param: dns_flavor_name }
4809 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
4812 **Option 2:** Create a resource group per availability zone. A separate
4813 OS::Heat::ResourceGroup is created for each availability zone.
4818 Heat templates *should not* reference any HTTP-based resource
4819 definitions, any HTTP-based nested configurations, or any HTTP-based
4822 - During orchestration, ONAP *should not* retrieve any such resources
4823 from external/untrusted/unknown sources.
4825 - VNF images should not contain such references in user-data or other
4826 configuration/operational scripts that are specified via Heat or
4827 encoded into the VNF image itself.
4829 *Note:* HTTP-based references are acceptable if the HTTP-based reference
4830 is accessing information with the VM private/internal network.
4832 Heat Files Support (get\_file)
4833 ------------------------------
4835 Heat Templates may contain the inclusion of text files into Heat
4836 templates via the Heat get\_file directive. This may be used, for
4837 example, to define a common “user-data” script, or to inject files into
4838 a VM on startup via the “personality” property.
4840 Support for Heat Files is subject to the following limitations:
4842 - The get\_files targets must be referenced in Heat templates by file
4843 name, and the corresponding files should be delivered to ONAP along
4844 with the Heat templates.
4846 - URL-based file retrieval must not be used; it is not supported.
4848 - The included files must have unique file names within the scope of
4851 - ONAP does not support a directory hierarchy for included files.
4853 - All files must be in a single, flat directory per VNF.
4855 - Included files may be used by all Modules within a given VNF.
4857 - get\_file directives may be used in both non-nested and nested
4863 When Nova Servers are created via Heat templates, they may be passed a
4864 “keypair” which provides an ssh key to the ‘root’ login on the newly
4865 created VM. This is often done so that an initial root key/password does
4866 not need to be hard-coded into the image.
4868 Key pairs are unusual in OpenStack, because they are the one resource
4869 that is owned by an OpenStack User as opposed to being owned by an
4870 OpenStack Tenant. As a result, they are usable only by the User that
4871 created the keypair. This causes a problem when a Heat template attempts
4872 to reference a keypair by name, because it assumes that the keypair was
4873 previously created by a specific ONAP user ID.
4875 When a keypair is assigned to a server, the SSH public-key is
4876 provisioned on the VMs at instantiation time. They keypair itself is not
4877 referenced further by the VM (i.e. if the keypair is updated with a new
4878 public key, it would only apply to subsequent VMs created with that
4881 Due to this behavior, the recommended usage of keypairs is in a more
4882 generic manner which does not require the pre-requisite creation of a
4883 keypair. The Heat should be structured in such a way as to:
4885 - Pass a public key as a parameter value instead of a keypair name
4887 - Create a new keypair within the VNF Heat templates (in the base
4888 module) for use within that VNF
4890 By following this approach, the end result is the same as pre-creating
4891 the keypair using the public key – i.e., that public key will be
4892 provisioned in the new VM. However, this recommended approach also makes
4893 sure that a known public key is supplied (instead of having OpenStack
4894 generate a public/private pair to be saved and tracked outside of ONAP).
4895 It also removes any access/ownership issues over the created keypair.
4897 The public keys may be enumerated as a VNF Orchestration Constant in the
4898 environment file (since it is public, it is not a secret key), or passed
4899 at run-time as instance-specific parameters. ONAP will never
4900 automatically assign a public/private key pair.
4902 *Example (create keypair with an existing ssh public-key for {vm-type}
4903 of lb (for load balancer)):*
4905 .. code-block:: yaml
4915 type: OS::Nova::Keypair
4919 template: VNF_NAME_key_pair
4921 VNF_NAME: { get_param: vnf_name }
4922 public_key: {get_param: lb_ssh_public_key}
4923 save_private_key: false
4928 OpenStack allows a tenant to create Security groups and define rules
4929 within the security groups.
4931 Security groups, with their rules, may either be created in the Heat
4932 Orchestration Template or they can be pre-created in OpenStack and
4933 referenced within the Heat template via parameter(s). There can be a
4934 different approach for security groups assigned to ports on internal
4935 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
4936 there can be a common security group across all VMs for a specific
4937 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
4940 Anti-Affinity and Affinity Rules
4941 --------------------------------
4943 Anti-affinity or affinity rules are supported using normal OpenStack
4944 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
4945 created for each VM type to prevent them from residing on the same host,
4946 but they can be applied to multiple VM types to extend the
4947 affinity/anti-affinity across related VM types as well.
4951 In this example, the {network-role} has been defined as oam to represent
4952 an oam network and the {vm-type} have been defined as lb for load
4953 balancer and db for database.
4955 .. code-block:: yaml
4959 type: OS::Nova::ServerGroup
4964 $vnf_name: {get_param: vnf_name}
4965 template: $vnf_name-server_group1
4970 type: OS::Nova::ServerGroup
4975 $vnf_name: {get_param: vnf_name}
4976 template: $vnf_name-server_group2
4981 type: OS::Nova::Server
4985 group: {get_resource: db_server_group}
4988 type: OS::Nova::Server
4992 group: {get_resource: db_server_group}
4995 type: OS::Nova::Server
4999 group: {get_resource: lb_server_group}
5001 Resource Data Synchronization
5002 -----------------------------
5004 For cases where synchronization is required in the orchestration of Heat
5005 resources, two approaches are recommended:
5007 - Standard Heat depends\_on property for resources
5009 - Assures that one resource completes before the dependent resource
5012 - Definition of completeness to OpenStack may not be sufficient
5013 (e.g., a VM is considered complete by OpenStack when it is ready
5014 to be booted, not when the application is up and running).
5016 - Use of Heat Notifications
5018 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5021 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5023 - Dependent resource define depends\_on in the
5024 OS::Heat::WaitCondition resource.
5026 *Example: “depends\_on” case*
5028 In this example, the {network-role} has been defined as oam to represent
5029 an oam network and the {vm-type} has been defined as oam to represent an
5032 .. code-block:: yaml
5036 type: OS::Nova::Server
5038 name: {get_param: [oam_ names, 0]}
5039 image: {get_param: oam_image_name}
5040 flavor: {get_param: oam_flavor_name}
5041 availability_zone: {get_param: availability_zone_0}
5043 - port: {get_resource: oam01_port_0}
5044 - port: {get_resource: oam01_port_1}
5046 scheduler_hints: {group: {get_resource: oam_servergroup}}
5047 user_data_format: RAW
5050 type: OS::Neutron::Port
5052 network: {get_resource: oam_net_name}
5053 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5054 security_groups: [{get_resource: oam_security_group}]
5057 type: OS::Neutron::Port
5059 network: {get_param: oam_net_name}
5060 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5061 security_groups: [{get_resource: oam_security_group}]
5063 oam_01_vol_attachment:
5064 type: OS::Cinder::VolumeAttachment
5065 depends_on: oam_server_01
5067 volume_id: {get_param: oam_vol_1}
5068 mountpoint: /dev/vdb
5069 instance_uuid: {get_resource: oam_server_01}
5074 VNF/VM parameters may include availability zone IDs for VNFs that
5075 require high availability.
5077 The Heat must comply with the following requirements to specific
5078 availability zone IDs:
5080 - The Heat template should spread Nova and Cinder resources across the
5081 availability zones as desired
5083 Post Orchestration & VNF Configuration
5084 --------------------------------------
5086 Heat templates should contain a minimum amount of post-orchestration
5087 configuration data. For instance, *do not* embed complex user-data
5088 scripts in the template with large numbers of configuration parameters
5089 to the Heat template.
5091 - VNFs may provide configuration APIs for use after VNF creation. Such
5092 APIs will be invoked via application and/or SDN controllers.
5094 *Note:* It is important to follow this convention to the extent possible
5095 even in the short-term as of the long-term direction.
5097 c. VNFM Driver Develop Steps
5098 ==============================
5100 Aid to help the VNF vendor to fasten the integration with the NFVO via
5101 Special VNFM, the ONAP provides the documents. In this charter, the
5102 develop steps for VNF vendors will be introduced.
5104 First, using the VNF SDK tools to design the VNF with TOSCA model and
5105 output the VNF TOSCA package. The VNF package can be validated, and
5108 Second, the VNF vendor should provide SVNFM Driver in the ONAP, which
5109 is a micro service and in duty of translation interface from NFVO to
5110 SVNFM. The interface of NFVO is aligned to the ETSI IFA interfaces and
5111 can be gotten in the charter 5.5. The interface of SVNFM is provided by
5112 the VNF vendor self.
5114 d. Create SVNFM Adaptor Mircoservice
5115 =======================================
5117 Some vnfs are managed by special VNFM, before add SVNFM to ONAP, a
5118 SVNFM adaptor must be added to ONAP to adapter the interface of NFVO
5121 A SVNFM adaptor is a micro service with unique name and an appointed
5122 port, when started up, it must be auto registered to MSB(Micro server
5123 bus),following describes an example rest of register to MSB:
5125 POST /openoapi/microservices/v1/services
5129 "serviceName": "catalog",
5133 "url": "/openoapi/catalog/v1",
5143 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob