1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
3 .. Copyright 2017 AT&T Intellectual Property. All rights reserved.
6 **VNF Modeling Requirements**
7 =====================================
10 --------------------------
16 This reference document is the VNF TOSCA Template Requirements for
17 ONAP, which provides recommendations and standards for building VNF
18 TOSCA templates compatible with ONAP initial implementations of
19 Network Cloud. It has the following features:
21 1. VNF TOSCA template designer supports GUI and CLI.
23 2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
24 Draft 04-Revision 06”.
26 3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
27 Threading, SRIOV， etc.
32 This document is intended for persons developing VNF TOSCA templates
33 that will be orchestrated by ONAP.
38 ONAP implementations of Network Cloud supports TOSCA Templates, also
39 referred to as TOSCA in this document.
41 ONAP requires the TOSCA Templates to follow a specific format. This
42 document provides the mandatory, recommended, and optional requirements
43 associated with this format.
48 The document includes three charters to help the VNF providers to use the
49 VNF model design tools and understand the VNF package structure and VNF
52 In the ONAP, VNF Package and VNFD template can be designed by manually
53 or via model designer tools. VNF model designer tools can provide the
54 GUI and CLI tools for the VNF provider to develop the VNF Package and VNFD
57 The VNF package structure is align to the NFV TOSCA protocol, and
60 The VNFD and VNF package are all align to the NFV TOSCA protocol, which
61 supports multiple TOSCA template yaml files, and also supports
62 self-defined node or other extensions.
67 TOSCA templates supported by ONAP must follow the requirements
68 enumerated in this section.
73 TOSCA defines a Meta model for defining IT services. This Meta model
74 defines both the structure of a service as well as how to manage it. A
75 Topology Template (also referred to as the topology model of a service)
76 defines the structure of a service. Plans define the process models that
77 are used to create and terminate a service as well as to manage a
78 service during its whole lifetime.
80 A Topology Template consists of a set of Node Templates and Relationship
81 Templates that together define the topology model of a service as a (not
82 necessarily connected) directed graph. A node in this graph is
83 represented by a *Node Template*. A Node Template specifies the
84 occurrence of a Node Type as a component of a service. A *Node Type*
85 defines the properties of such a component (via *Node Type Properties*)
86 and the operations (via *Interfaces*) available to manipulate the
87 component. Node Types are defined separately for reuse purposes and a
88 Node Template references a Node Type and adds usage constraints, such as
89 how many times the component can occur.
93 Figure 1: Structural Elements of Service Template and their Relations
95 TOSCA Modeling Principles & Data Model
96 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
98 This section describing TOSCA modeling principles and data model for
99 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
100 V1.0], or new type based on ETSI NFV requirements, etc.
102 VNF Descriptor Template
103 ^^^^^^^^^^^^^^^^^^^^^^^^^
105 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
106 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
107 Links, External Connection Points, Scaling Aspects, Instantiation Levels
108 and Deployment Flavours.
110 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
111 represents the contract & interface of a VNF and ensures the
112 interoperability across the NFV functional blocks.
114 The main parts of the VNFD are the following:
116 - VNF topology: it is modeled in a cloud agnostic way using virtualized
117 containers and their connectivity. Virtual Deployment Units (VDU)
118 describe the capabilities of the virtualized containers, such as
119 virtual CPU, RAM, disks; their connectivity is modeled with VDU
120 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
121 and VNF External Connection Point Descriptors (VnfExternalCpd);
123 - VNF deployment aspects: they are described in one or more deployment
124 flavours, including instantiation levels, supported LCM operations,
125 VNF LCM operation configuration parameters, placement constraints
126 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
127 and scaling aspect for horizontal scaling.
129 The following table defines the TOSCA Type “derived from” values that
130 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
131 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
133 +-----------------------------------------+---------------------------------------+-----------------------+
134 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
136 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
137 +=========================================+=======================================+=======================+
138 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
139 +-----------------------------------------+---------------------------------------+-----------------------+
140 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
141 +-----------------------------------------+---------------------------------------+-----------------------+
142 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
143 +-----------------------------------------+---------------------------------------+-----------------------+
144 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
145 +-----------------------------------------+---------------------------------------+-----------------------+
146 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
147 +-----------------------------------------+---------------------------------------+-----------------------+
148 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
149 +-----------------------------------------+---------------------------------------+-----------------------+
150 | Virtual Storage | | |
151 +-----------------------------------------+---------------------------------------+-----------------------+
152 | Virtual Compute | | |
153 +-----------------------------------------+---------------------------------------+-----------------------+
154 | Software Image | | |
155 +-----------------------------------------+---------------------------------------+-----------------------+
156 | Deployment Flavour | | |
157 +-----------------------------------------+---------------------------------------+-----------------------+
158 | Scaling Aspect | | |
159 +-----------------------------------------+---------------------------------------+-----------------------+
160 | Element Group | | |
161 +-----------------------------------------+---------------------------------------+-----------------------+
162 | Instantiation Level | | |
163 +-----------------------------------------+---------------------------------------+-----------------------+
165 +--------------------------------------------------------------------+
166 | +--------------------------------------------------------------+ |
167 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
169 | | description: VNFD TOSCA file demo | |
173 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
175 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
177 | | | **node\_types: | |
178 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
179 | | derived\_from:** tosca.nodes.nfv.VNF | |
180 | | | **requirements: | |
181 | | **- **sriov\_plane: | |
182 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
183 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
184 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
185 | +--------------------------------------------------------------+ |
186 +====================================================================+
187 +--------------------------------------------------------------------+
192 1. SR-IOV Passthrought
194 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
197 +------------------------------------------------+
206 | tosca\_name: SRIOV\_Port |
210 | virtual\_network\_interface\_requirements: |
214 | support\_mandatory: false |
216 | description: sriov |
224 | description: sriov port |
226 | layer\_protocol: ipv4 |
230 | - virtual\_binding: |
232 | capability: virtual\_binding |
238 | type: tosca.relationships.nfv.VirtualBindsTo |
242 | node: tosca.nodes.Root |
244 | type: tosca.nodes.nfv.VduCpd |
246 | substitution\_mappings: |
256 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
257 +------------------------------------------------+
261 Definitions of mem\_page\_size as one property shall be added to
262 Properties and set the value to large if one VDU node supports
263 huagepages. Here is an example.
265 +----------------------------------+
274 | tosca\_name: Huge\_pages\_demo |
278 | mem\_page\_size:large |
279 +==================================+
280 +----------------------------------+
284 Likewise, we shall add definitions of numa to
285 requested\_additional\_capabilities if we wand VUD nodes to support
286 NUMA. Here is an example.
288 +-------------------------------------------------+
289 | topology\_template: |
297 | virtual\_compute: |
303 | numa\_enabled: true |
305 | virtual\_mem\_size: 2 GB |
307 | requested\_additional\_capabilities: |
311 | support\_mandatory: true |
313 | requested\_additional\_capability\_name: numa |
315 | target\_performance\_parameters: |
317 | hw:numa\_nodes: "2" |
319 | hw:numa\_cpus.0: "0,1" |
321 | hw:numa\_mem.0: "1024" |
323 | hw:numa\_cpus.1: "2,3,4,5" |
325 | hw:numa\_mem.1: "1024" |
326 +-------------------------------------------------+
330 Definitions of Hyper-Theading are necessary as one of
331 requested\_additional\_capabilities of one VUD node if that node
332 supports Hyper-Theading. Here is an example.
334 +-------------------------------------------------------------+
335 | topology\_template: |
343 | virtual\_compute: |
349 | numa\_enabled: true |
351 | virtual\_mem\_size: 2 GB |
353 | requested\_additional\_capabilities: |
355 | hyper\_threading: |
357 | support\_mandatory: true |
359 | requested\_additional\_capability\_name: hyper\_threading |
361 | target\_performance\_parameters: |
363 | hw:cpu\_sockets : "2" |
365 | hw:cpu\_threads : "2" |
367 | hw:cpu\_cores : "2" |
369 | hw:cpu\_threads\_policy: "isolate" |
370 +-------------------------------------------------------------+
374 Definitions of ovs\_dpdk are necessary as one of
375 requested\_additional\_capabilities of one VUD node if that node
376 supports dpdk. Here is an example.
378 +------------------------------------------------------+
379 | topology\_template: |
387 | virtual\_compute: |
393 | numa\_enabled: true |
395 | virtual\_mem\_size: 2 GB |
397 | requested\_additional\_capabilities: |
401 | support\_mandatory: true |
403 | requested\_additional\_capability\_name: ovs\_dpdk |
405 | target\_performance\_parameters: |
407 | sw:ovs\_dpdk: "true" |
408 +------------------------------------------------------+
410 NFV TOSCA Type Definition
411 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
413 tosca.capabilites.nfv.VirtualCompute
414 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
416 +---------------------------+-----------------------------------------+
417 | **Shorthand Name** | VirtualCompute |
418 +===========================+=========================================+
419 | **Type Qualified Name** | tosca: VirtualCompute |
420 +---------------------------+-----------------------------------------+
421 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
422 +---------------------------+-----------------------------------------+
423 | **derived from** | tosca.nodes.Root |
424 +---------------------------+-----------------------------------------+
429 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
430 | Name | Required | Type | Constraints | Description |
431 +=====================================+============+=====================================================+===============+=========================================================+
432 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
433 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
434 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
435 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
436 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
437 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
438 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
440 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
445 +-----------------------------------------------------------+
446 | tosca.capabilities.nfv.VirtualCompute: |
448 | derived\_from: tosca.capabilities.Root |
452 | requested\_additional\_capabilities: |
458 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
464 | type: tosca.datatypes.nfv.VirtualMemory |
470 | type: tosca.datatypes.nfv.VirtualCpu |
473 +-----------------------------------------------------------+
475 tosca.nodes.nfv.VDU.Compute
476 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
478 The NFV Virtualization Deployment Unit (VDU) compute node type
479 represents a VDU entity which it describes the deployment and
480 operational behavior of a VNF component (VNFC), as defined by **[ETSI
483 +-----------------------+-------------------------------+
484 | Shorthand Name | VDU.Compute |
485 +=======================+===============================+
486 | Type Qualified Name | tosca:VDU.Compute |
487 +-----------------------+-------------------------------+
488 | Type URI | tosca.nodes.nfv.VDU.Compute |
489 +-----------------------+-------------------------------+
490 | derived\_from | tosca.nodes.Compute |
491 +-----------------------+-------------------------------+
504 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
505 | Name | Type | Constraints | Description |
506 +=========================+=================================================+===============+=====================================================================================================+
507 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
508 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
509 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
511 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
512 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
513 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
515 | | editor note: need to create a capability type | | |
516 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
521 +-----------------------------------------------------------------------------------------------------+
522 | tosca.nodes.nfv.VDU.Compute: |
524 | derived\_from: tosca.nodes.Compute |
542 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
550 | nfvi\_constraints: |
560 | configurable\_properties: |
566 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
572 | private\_address: |
574 | status: deprecated |
578 | status: deprecated |
582 | status: deprecated |
586 | status: deprecated |
590 | virtual\_compute: |
592 | type: tosca.capabilities.nfv.VirtualCompute |
594 | virtual\_binding: |
596 | type: tosca.capabilities.nfv.VirtualBindable |
598 | #monitoring\_parameter: |
600 | # modeled as ad hoc (named) capabilities in VDU node template |
606 | # cpu\_load: tosca.capabilities.nfv.Metric |
608 | # memory\_usage: tosca.capabilities.nfv.Metric |
610 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
612 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
614 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
616 | occurrences: [0,UNBOUNDED] |
620 | occurrences: [0,0] |
624 | occurrences: [0,0] |
626 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
628 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
632 | occurrences: [0,UNBOUND] |
636 | - virtual\_storage: |
638 | capability: tosca.capabilities.nfv.VirtualStorage |
640 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
642 | node: tosca.nodes.nfv.VDU.VirtualStorage |
644 | occurences: [ 0, UNBOUNDED ] |
646 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
648 | occurrences: [0,0] |
656 | type: tosca.artifacts.nfv.SwImage |
657 +-----------------------------------------------------------------------------------------------------+
661 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
662 | Name | Required | Type | Constraints | Description |
663 +===========+============+===============================+===============+================================================+
664 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
665 | | | | | directly realizing this virtual storage |
666 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
674 ~~~~~~~~~~~~~~~~~~~~~
676 The TOSCA Cpd node represents network connectivity to a compute resource
677 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
678 used as parent for the various Cpd types.
680 +-----------------------+-----------------------+
681 | Shorthand Name | Cpd |
682 +=======================+=======================+
683 | Type Qualified Name | tosca:Cpd |
684 +-----------------------+-----------------------+
685 | Type URI | tosca.nodes.nfv.Cpd |
686 +-----------------------+-----------------------+
692 +--------+------------+--------+---------------+---------------+
693 | Name | Required | Type | Constraints | Description |
694 +========+============+========+===============+===============+
695 +--------+------------+--------+---------------+---------------+
710 +----------------------------------------------------------------------+
711 | tosca.nodes.nfv.Cpd: |
713 | derived\_from: tosca.nodes.Root |
723 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
727 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
733 | - valid\_values: [ root, leaf ] |
749 | type: tosca.datatype.nfv.AddressData |
752 +----------------------------------------------------------------------+
754 Additional Requirement
755 +++++++++++++++++++++++
759 tosca.nodes.nfv.VduCpd
760 ~~~~~~~~~~~~~~~~~~~~~~~
762 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
763 network connectivity between a VNFC instance (based on this VDU) and an
764 internal VL as defined by [ETSI GS NFV-IFA 011].
766 +-----------------------+--------------------------+
767 | Shorthand Name | VduCpd |
768 +=======================+==========================+
769 | Type Qualified Name | tosca: VduCpd |
770 +-----------------------+--------------------------+
771 | Type URI | tosca.nodes.nfv.VduCpd |
772 +-----------------------+--------------------------+
778 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
779 | Name | Required | Type | Constraints | Description |
780 +===============================+============+==========================================+==========================================================================+
781 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
782 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
783 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
784 | requirements | | | | realising the CPs instantiated from this CPD |
785 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
795 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
796 | Name | Required | Type | Constraints | Description |
797 +====================+============+==========================================+===============+==========================================================+
798 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
799 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
800 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
801 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
806 +----------------------------------------------------------------+
807 | tosca.nodes.nfv.VduCpd: |
809 | derived\_from: tosca.nodes.nfv.Cpd |
813 | bitrate\_requirement: |
819 | virtual\_network\_interface\_requirements |
825 | type: VirtualNetworkInterfaceRequirements |
833 | capability: tosca.capabilities.nfv.VirtualLinkable |
835 | relationship: tosca.relationships.nfv.VirtualLinksTo |
837 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
839 | capability: tosca.capabilities.nfv.VirtualBindable |
841 | relationship: tosca.relationships.nfv.VirtualBindsTo |
843 | node: tosca.nodes.nfv.VDU |
844 +----------------------------------------------------------------+
846 tosca.nodes.nfv.VDU.VirtualStorage
847 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
849 The NFV VirtualStorage node type represents a virtual storage entity
850 which it describes the deployment and operational behavior of a virtual
851 storage resources, as defined by **[ETSI NFV IFA011].**
853 **[editor note]** open issue: should NFV profile use the current storage
854 model as described in YAML 1.1. Pending on Shitao proposal (see
855 NFVIFA(17)000110 discussion paper)
857 **[editor note]** new relationship type as suggested in Matt
858 presentation. Slide 8. With specific rules of “valid\_target\_type”
860 +---------------------------+--------------------------------------+
861 | **Shorthand Name** | VirtualStorage |
862 +===========================+======================================+
863 | **Type Qualified Name** | tosca: VirtualStorage |
864 +---------------------------+--------------------------------------+
865 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
866 +---------------------------+--------------------------------------+
867 | **derived\_from** | tosca.nodes.Root |
868 +---------------------------+--------------------------------------+
870 tosca.artifacts.nfv.SwImage
871 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
873 +---------------------------+------------------------------------+
874 | **Shorthand Name** | SwImage |
875 +===========================+====================================+
876 | **Type Qualified Name** | tosca:SwImage |
877 +---------------------------+------------------------------------+
878 | **Type URI** | tosca.artifacts.nfv.SwImage |
879 +---------------------------+------------------------------------+
880 | **derived\_from** | tosca.artifacts.Deployment.Image |
881 +---------------------------+------------------------------------+
886 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
887 | Name | Required | Type | Constraints | Description |
888 +==========================================+============+====================+===============+====================================================================================================+
889 | name | yes | string | | Name of this software image |
890 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
891 | version | yes | string | | Version of this software image |
892 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
893 | checksum | yes | string | | Checksum of the software image file |
894 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
895 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
896 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
897 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
898 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
899 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
900 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
901 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
902 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
903 | Size | yes | scalar-unit.size | | The size of this software image |
904 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
905 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
906 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
907 | operating\_system | no | string | | Identifies the operating system used in the software image. |
908 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
909 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
910 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
915 +-----------------------------------------------------+
916 | tosca.artifacts.nfv.SwImage: |
918 | derived\_from: tosca.artifacts.Deployment.Image |
920 | properties or metadata: |
944 | container\_format: |
958 | type: scalar-unit.size # Number |
964 | type: scalar-unit.size # Number |
970 | type: scalar-unit.size # Number |
980 | operating\_system: |
986 | supported\_virtualisation\_environments: |
995 +-----------------------------------------------------+
1000 openovnf\_\_vOpenNAT.yaml
1001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1003 +-------------------------------------------------------------+
1006 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1008 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1010 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1012 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1014 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1016 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1018 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1020 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1022 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1024 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1026 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1028 | - openonfv\_\_tosca.capabilities.Container.yaml |
1030 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1032 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1034 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1036 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1038 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1040 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1042 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1046 | vnfProductName: openNAT |
1048 | vnfdVersion: 1.0.0 |
1050 | vnfProvider: intel |
1054 | csarVersion: 1.0.0 |
1056 | vnfdId: openNAT-1.0 |
1058 | csarProvider: intel |
1060 | vnfProductInfoDescription: openNAT |
1068 | localizationLanguage: '[english, chinese]' |
1072 | defaultLocalizationLanguage: english |
1074 | vnfProductInfoName: openNAT |
1076 | vnfSoftwareVersion: 1.0.0 |
1078 | topology\_template: |
1080 | node\_templates: |
1088 | file: /swimages/xenial-snat.qcow2 |
1090 | type: tosca.artifacts.nfv.SwImage |
1094 | name: vNatVNFImage |
1098 | checksum: "5000" |
1100 | container\_format: bare |
1102 | disk\_format: qcow2 |
1104 | min\_disk: 10 GB |
1110 | sw\_image: /swimages/xenial-snat.qcow2 |
1112 | operating\_system: unbantu |
1116 | tosca\_name: vdu\_vNat |
1120 | virtual\_compute: |
1124 | virtual\_memory: |
1126 | numa\_enabled: true |
1128 | virtual\_mem\_size: 2 GB |
1130 | requested\_additional\_capabilities: |
1134 | support\_mandatory: true |
1136 | requested\_additional\_capability\_name: numa |
1138 | target\_performance\_parameters: |
1140 | hw:numa\_nodes: "2" |
1142 | hw:numa\_cpus.0: "0,1" |
1144 | hw:numa\_mem.0: "1024" |
1146 | hw:numa\_cpus.1: "2,3,4,5" |
1148 | hw:numa\_mem.1: "1024" |
1150 | hyper\_threading: |
1152 | support\_mandatory: true |
1154 | requested\_additional\_capability\_name: hyper\_threading |
1156 | target\_performance\_parameters: |
1158 | hw:cpu\_sockets : "2" |
1160 | hw:cpu\_threads : "2" |
1162 | hw:cpu\_cores : "2" |
1164 | hw:cpu\_threads\_policy: "isolate" |
1168 | support\_mandatory: true |
1170 | requested\_additional\_capability\_name: ovs\_dpdk |
1172 | target\_performance\_parameters: |
1174 | sw:ovs\_dpdk: "true" |
1178 | cpu\_architecture: X86 |
1180 | num\_virtual\_cpu: 2 |
1184 | configurable\_properties: |
1188 | additional\_vnfc\_configurable\_properties: |
1194 | descrption: the virtual machine of vNat |
1202 | - virtual\_storage: |
1204 | capability: virtual\_storage |
1206 | node: vNAT\_Storage |
1212 | location: /mnt/volume\_0 |
1214 | type: tosca.relationships.nfv.VDU.AttachedTo |
1216 | - local\_storage: |
1218 | node: tosca.nodes.Root |
1220 | type: tosca.nodes.nfv.VDU.Compute |
1226 | tosca\_name: SRIOV\_Port |
1230 | virtual\_network\_interface\_requirements: |
1234 | support\_mandatory: false |
1236 | description: sriov |
1244 | description: sriov port |
1246 | layer\_protocol: ipv4 |
1250 | - virtual\_binding: |
1252 | capability: virtual\_binding |
1258 | type: tosca.relationships.nfv.VirtualBindsTo |
1260 | - virtual\_link: |
1262 | node: tosca.nodes.Root |
1264 | type: tosca.nodes.nfv.VduCpd |
1270 | tosca\_name: vNAT\_Storage |
1274 | id: vNAT\_Storage |
1276 | size\_of\_storage: 10 GB |
1278 | rdma\_enabled: false |
1280 | type\_of\_storage: volume |
1282 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1284 | substitution\_mappings: |
1294 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1296 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1297 +-------------------------------------------------------------+
1299 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1300 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1302 +------------------------------------------------------------+
1305 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1309 | tosca.nodes.nfv.VDU.VirtualStorage: |
1313 | virtual\_storage: |
1315 | type: tosca.capabilities.nfv.VirtualStorage |
1317 | derived\_from: tosca.nodes.Root |
1325 | size\_of\_storage: |
1335 | type\_of\_storage: |
1339 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1340 +------------------------------------------------------------+
1342 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1343 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1345 +-----------------------------------------------------------------+
1348 | tosca.datatypes.nfv.L3AddressData: |
1352 | number\_of\_ip\_address: |
1358 | ip\_address\_assignment: |
1362 | ip\_address\_type: |
1366 | - valid\_values: |
1376 | floating\_ip\_activated: |
1380 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1390 | support\_mandatory: |
1408 | tosca.datatype.nfv.AddressData: |
1416 | - valid\_values: |
1424 | l2\_address\_data: |
1428 | type: tosca.datatypes.nfv.L2AddressData |
1430 | l3\_address\_data: |
1434 | type: tosca.datatypes.nfv.L3AddressData |
1436 | tosca.datatypes.nfv.L2AddressData: {} |
1440 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1442 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1446 | tosca.nodes.nfv.VduCpd: |
1448 | derived\_from: tosca.nodes.Root |
1452 | virtual\_network\_interface\_requirements: |
1456 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1466 | - valid\_values: |
1476 | bitrate\_requirement: |
1488 | layer\_protocol: |
1492 | - valid\_values: |
1512 | type: tosca.datatype.nfv.AddressData |
1520 | - virtual\_binding: |
1522 | capability: tosca.capabilities.nfv.VirtualBindable |
1530 | - virtual\_link: |
1532 | capability: tosca.capabilities.nfv.VirtualBindable |
1540 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1541 +-----------------------------------------------------------------+
1543 .. |image1| image:: Image1.png
1546 .. |image2| image:: Image2.png
1560 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1561 Markup Language) is a human friendly data serialization standard for all
1562 programming languages. See http://www.yaml.org/.
1564 Heat Orchestration Template Format
1565 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1567 Heat Orchestration templates must be defined in YAML.
1571 - Tabs are NOT allowed, use spaces ONLY.
1573 - R-43125 The VNF Heat **MUST** indent properties and lists with 1 or more spaces.
1575 - All Resource IDs and resource property parameters are case-sensitive.
1576 (e.g., "ThIs", is not the same as "thiS")
1578 Heat Orchestration Template Structure
1579 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1581 Heat Orchestration template structure follows the following format, as
1582 defined by OpenStack at
1583 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1585 .. code-block:: yaml
1587 heat_template_version: <date>
1590 # a description of the template
1593 # a declaration of input parameter groups and order
1596 # declaration of input parameters
1599 # declaration of template resources
1602 # declaration of output parameters
1605 # declaration of conditions
1608 R-67888 The VNF Heat **MUST** contain the following
1611 - heat\_template\_version:
1619 Heat Orchestration templates for ONAP may contain the following
1622 - parameter\_groups:
1626 heat\_template\_version
1627 ++++++++++++++++++++++++
1629 This section is ONAP mandatory. The heat\_template\_version must be set
1630 to a date that is supported by the OpenStack environment.
1635 R-39402 The VNF Heat **MUST** contain the description section.
1640 This ONAP optional section allows for specifying how the input
1641 parameters should be grouped and the order to provide the parameters in.
1646 R-35414 The VNF Heat **MUST** contain the parameter section.
1648 This section allows for
1649 specifying input parameters that must be provided when instantiating
1650 the template. Each parameter is specified in a separated nested block
1651 with the name of the parameters defined in the first line and additional
1652 attributes (e.g., type, label) defined as nested elements.
1654 R-90279 The VNF Heat **MUST** use in a resource all parameters declared in a template
1655 except for the parameters for the OS::Nova::Server property
1656 availability\_zone. See `Property: availability\_zone`_. for more details on
1659 .. code-block:: yaml
1663 type: <string | number | json | comma_delimited_list | boolean>
1664 label: <human-readable name of the parameter>
1665 description: <description of the parameter>
1666 default: <default value for parameter>
1667 hidden: <true | false>
1669 <parameter constraints>
1670 immutable: <true | false>
1674 - The name of the parameter.
1676 - ONAP requires that the param name must contain only alphanumeric
1677 characters and “\_” underscores. Special characters must not be
1682 - The type of the parameter. Supported types are string, number,
1683 comma\_delimited\_list, json and boolean.
1685 - R-28657 The VNF Heat **MUST** provide the attribute 'type' on parameters per the OpenStack Heat
1686 Orchestration Template standard.
1690 - A human readable name for the parameter.
1692 - This attribute is optional.
1696 - A human readable description for the parameter.
1698 - R-44001 The VNF Heat **MUST** provide the attribute 'description' on parameters. (Note that
1699 this attribute is OpenStack optional.)
1703 - A default value for the parameter.
1705 - R-90526 The VNF Heat **MUST NOT** use the attribute 'default'.
1706 If a parameter has a default
1707 value, it must be provided in the environment file. (Note that
1708 this attribute is OpenStack optional.)
1712 - Defines whether the parameters should be hidden when a user
1713 requests information about a stack created from the template. This
1714 attribute can be used to hide passwords specified as parameters.
1716 - This attribute is optional and defaults to false.
1720 - A list of constraints to apply. The constraints block of a
1721 parameter definition defines additional validation constraints
1722 that apply to the value of the parameter. The parameter values
1723 provided in the Heat Orchestration Template are validated against
1724 the constraints at instantiation time. The constraints are defined
1725 as a list with the following syntax
1729 - <constraint type>: <constraint definition>
1731 description: <constraint description>
1733 - constraint type: Type of constraint to apply.
1735 - constraint definition: The actual constraint, depending on the
1738 - description: A description of the constraint. The text is presented
1739 to the user when the value the user defines violates the constraint.
1740 If omitted, a default validation message is presented to the user.
1741 This attribute is optional.
1743 - R-88863 The VNF Heat **MUST** have a constraint of range or allowed\_values for a parameter type 'number'.
1745 - range: The range constraint applies to parameters of type number.
1746 It defines a lower and upper limit for the numeric value of the
1747 parameter. The syntax of the range constraint is
1749 range: { min: <lower limit>, max: <upper limit> }
1751 It is possible to define a range constraint with only a lower limit
1754 - allowed\_values: The allowed\_values constraint applies to parameters
1755 of type string or number. It specifies a set of possible values for a
1756 parameter. At deployment time, the user-provided value for the
1757 respective parameter must match one of the elements of the list. The
1758 syntax of the allowed\_values constraint is
1760 allowed\_values: [ <value>, <value>, ... ]
1762 Alternatively, the following YAML list notation can be used
1772 - Other <constraint type> are optional, they may be used (e.g., length,
1773 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1776 - Note that constrains must not be defined for any parameter enumerated
1777 in a nested heat template.
1779 - Some ONAP parameters must never have constraints defined. See `ONAP Resource ID and Parameter Naming Convention`_ for the use cases where these exceptions exist.
1783 - Defines whether the parameter is updatable. Stack update fails, if
1784 this is set to true and the parameter value is changed.
1786 - This attribute is optional and defaults to false.
1791 R-23664 The VNF Heat **MUST** have a resources: section with the declaration of at least one resource.
1794 contains the declaration of the single resources of the template. This
1795 section with at least one resource must be defined in the Heat
1796 Orchestration Template, or the template would not create any resources
1797 when being instantiated.
1799 Each resource is defined as a separate block in the resources section
1800 with the following syntax.
1802 .. code-block:: yaml
1806 type: <resource type>
1808 <property name>: <property value>
1810 <resource specific metadata>
1811 depends\_on: <resource ID or list of ID>
1812 update\_policy: <update policy>
1813 deletion\_policy: <deletion policy>
1814 external\_id: <external resource ID>
1815 condition: <condition name or expression or boolean>
1819 - A resource ID that must be unique within the resources section of
1820 the Heat Orchestration Template.
1822 - R-16447 The VNF Heat **MUST** have unique resource IDs across all Heat
1823 Orchestration Templates that compose the VNF. This requirement
1824 also applies when a VNF is composed of more than one Heat
1825 Orchestration Template (see ONAP VNF Modularity Overview).
1827 - The naming convention for a resource ID is provided in `Resource IDs`_.
1831 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1832 Note that the type may specify a nested heat file. This attribute
1837 - A list of resource-specific properties. The property value can be
1838 provided in place, or via a function (e.g., Intrinsic functions). This section is optional.
1840 - The naming convention for property parameters is provided in `ONAP Resource ID and Parameter Naming Convention`_.
1844 - Resource-specific metadata. This section is optional, except for
1845 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1847 - R-97199 The VNF Heat **MUST** use the metadata property for OS::Nova::Server resource type.
1851 - Dependencies of the resource on one or more resources of the
1852 template. This attribute is optional. See `Resource Data Synchronization`_ for additional details.
1856 - Update policy for the resource, in the form of a nested
1857 dictionary. Whether update policies are supported and what the
1858 exact semantics are depends on the type of the current resource.
1859 This attribute is optional.
1863 - Deletion policy for the resource. The allowed deletion policies
1864 are Delete, Retain, and Snapshot. Beginning with
1865 heat\_template\_version 2016-10-14, the lowercase equivalents
1866 delete, retain, and snapshot are also allowed. This attribute is
1867 optional; the default policy is to delete the physical resource
1868 when deleting a resource from the stack.
1872 - Allows for specifying the resource\_id for an existing external
1873 (to the stack) resource. External resources cannot depend on other
1874 resources, but we allow other resources to depend on external
1875 resource. This attribute is optional. Note: when this is
1876 specified, properties will not be used for building the resource
1877 and the resource is not managed by Heat. This is not possible to
1878 update that attribute. Also, resource won’t be deleted by heat
1879 when stack is deleted.
1883 - Condition for the resource. The condition decides whether to
1884 create the resource or not. This attribute is optional.
1889 This ONAP optional section allows for specifying output parameters
1890 available to users once the template has been instantiated. If the
1891 section is specified, it will need to adhere to specific requirements.
1892 See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
1894 Environment File Format
1895 ^^^^^^^^^^^^^^^^^^^^^^^^
1897 The environment file is a yaml text file.
1898 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1900 The environment file can contain the following sections:
1902 - parameters: A list of key/value pairs.
1904 - resource\_registry: Definition of custom resources.
1906 - parameter\_defaults: Default parameters passed to all template
1909 - encrypted\_parameters: List of encrypted parameters.
1911 - event\_sinks: List of endpoints that would receive stack events.
1913 - parameter\_merge\_strategies: Merge strategies for merging parameters
1914 and parameter defaults from the environment file.
1916 R-03324 The VNF Heat **MUST** contain the following sections in the environment file:
1920 Environment files for ONAP may contain the following sections:
1922 - resource\_registry:
1924 - parameter\_defaults:
1926 - encrypted\_parameters:
1930 - parameter\_merge\_strategies:
1932 The use of an environment file in OpenStack is optional. In ONAP, it is
1933 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
1934 corresponding environment file, even if no parameters are enumerated in
1935 the mandatory parameter section.
1937 (Note that ONAP, the open source version of ONAP, does not
1938 programmatically enforce the use of an environment file.)
1940 SDC Treatment of Environment Files
1941 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1943 Parameter values enumerated in the environment file are used by SDC as
1944 the default value. However, the SDC user may use the SDC GUI to
1945 overwrite the default values in the environment file.
1947 SDC generates a new environment file for distribution to MSO based on
1948 the uploaded environment file and the user provided GUI updates. The
1949 user uploaded environment file is discarded when the new file is
1952 ONAP has requirements for what parameters must be enumerated in the
1953 environment file and what parameter must not be enumerated in the
1954 environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1956 Nested Heat Orchestration Templates Overview
1957 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1959 ONAP supports nested Heat Orchestration Templates per OpenStack
1962 A Base Module may utilize nested templates.
1964 An Incremental Module may utilize nested templates.
1966 A Cinder Volume Module may utilize nested templates.
1968 A nested template must not define parameter constraints in the parameter
1971 Nested templates may be suitable for larger VNFs that contain many
1972 repeated instances of the same VM type(s). A common usage pattern is to
1973 create a nested template for each VM type along with its supporting
1974 resources. The Heat Orchestration Template may then reference these
1975 nested templates either statically (by repeated definition) or
1976 dynamically (via OS::Heat::ResourceGroup).
1978 See `Nested Heat Templates`_ for additional details.
1980 ONAP Heat Orchestration Template Filenames
1981 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1983 In order to enable ONAP to understand the relationship between Heat
1984 files, the following Heat file naming convention must be utilized.
1986 In the examples below, <text> represents any alphanumeric string that
1987 must not contain any special characters and must not contain the word
1993 R-19473 The VNF Heat **MUST** include “base” in the filename for the base module
1995 R-81339 The VNF Heat **MUST** match one of the following options for the base module file name:
1997 - base\_<text>.y[a]ml
1999 - <text>\_base.y[a]ml
2003 - <text>\_base\_<text>.y[a]ml
2005 R-91342 The VNF Heat **MUST** name the base module’s corresponding environment file to be identical
2006 to the base module with “.y[a]ml” replaced with “.env”.
2009 ~~~~~~~~~~~~~~~~~~~~~
2011 There is no explicit naming convention for the incremental modules.
2012 As noted above, <text> represents any alphanumeric string.
2014 R-87247 The VNF Heat **MUST NOT** use any special characters or the word “base” in the name of the incremental module.
2018 R-94509 The VNF Heat **MUST** name the incremental module’s corresponding environment file to be
2019 identical to the incremental module with “.y[a]ml” replaced with “.env”.
2021 To clearly identify the incremental module, it is recommended to use the
2022 following naming options for modules:
2024 - module\_<text>.y[a]ml
2026 - <text>\_module.y[a]ml
2030 Cinder Volume Modules
2031 ~~~~~~~~~~~~~~~~~~~~~~~
2033 R-82732 The VNF Heat **MUST** name the Cinder volume module file name to be the same as the
2034 corresponding module it is supporting (base module or incremental
2035 module) with “\_volume” appended.
2037 - <base module name>\_volume.y[a]ml
2039 - <incremental module name>\_volume.y[a]ml
2041 R-31141 The VNF Heat **MUST** name the volume module’s corresponding environment file
2042 to be identical to the volume module with “.y[a]ml” replaced with “.env”.
2047 There is no explicit naming convention for nested Heat files with the
2048 following exceptions; the name should contain “nest”.
2050 R-76057 The VNF Heat **MUST NOT** use special characters
2051 or the word “base” in the file name for the nested template.
2053 As noted above, <text> represents any alphanumeric string.
2057 Nested Heat files do not have corresponding environment files, per
2058 OpenStack specifications.
2060 R-18224 The VNF Heat **MUST** pass in as properties all parameter values associated with the
2061 nested heat file in the resource
2062 definition defined in the parent heat template.
2064 ONAP Parameter Classifications Overview
2065 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2067 In order for ONAP to support workflow automation, Heat Orchestration
2068 Template resource property parameters must adhere to specific naming
2069 conventions and requirements.
2071 Broadly, ONAP categorizes parameters into four categories:
2073 1. ONAP metadata parameters
2075 2. Instance specific parameters
2077 3. Constant parameters
2079 4. Output parameters.
2081 ONAP Metadata Parameters
2082 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2084 There are both mandatory and optional ONAP metadata parameters
2085 associated with the resource OS::Nova::Server.
2087 - ONAP metadata parameters must not have parameter constraints defined.
2089 - Both mandatory and optional (if specified) ONAP metadata parameter
2090 names must follow the ONAP metadata parameter naming convention.
2092 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on the metadata parameters.
2094 Instance specific parameters
2095 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2097 The instance specific parameters are VNF instance specific. The value of
2098 the parameter will be different for every instance of a VNF (e.g., IP
2099 address). The instance specific parameters are subdivided into two
2100 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2103 ONAP Orchestration Parameters
2104 +++++++++++++++++++++++++++++++
2106 ONAP Orchestration Parameters are per instance parameters where the
2107 value is assigned via ONAP automation. (Note that in some cases,
2108 automation is currently not available and the value is loaded into ONAP
2109 prior to instantiation.)
2111 - ONAP orchestration parameters must not be enumerated in the
2114 - When the ONAP orchestration parameter type is set to number, the
2115 parameter must have constraints for range and/or allowed\_values.
2117 - Parameter constraints for ONAP orchestration parameters are optional
2118 for all parameter types other than number. If constraints are
2119 specified, they must adhere to the OpenStack specifications.
2121 - The ONAP orchestration parameter names must follow the ONAP
2122 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2125 VNF Orchestration Parameters
2126 +++++++++++++++++++++++++++++
2128 VNF Orchestration Parameters are per instance parameters where the
2129 values are assigned manually. They are not supported by ONAP automation.
2130 The per instance values are loaded into ONAP prior to VNF instantiation.
2132 - VNF orchestration parameters must not be enumerated in the
2135 - When the VNF orchestration parameter type is set to number, the
2136 parameter must have constraints for range or allowed\_values.
2138 - Parameter constraints for VNF orchestration parameters are optional
2139 for all parameter types other than number. If constraints are
2140 specified, they must adhere to the OpenStack specifications.
2142 - The VNF orchestration parameter names should follow the VNF
2143 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2147 ~~~~~~~~~~~~~~~~~~~~~
2149 The constant parameters are parameters that remain constant across many
2150 VNF instances (e.g., image, flavor). The constant parameters are
2151 subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
2153 ONAP Constant Parameters
2154 ++++++++++++++++++++++++++
2156 - ONAP Constant Parameters must be enumerated in the environment file.
2157 These parameter values are not assigned by ONAP.
2159 - When the ONAP Constant Parameter type is set to number, the parameter
2160 must have constraints for range and/or allowed\_values.
2162 - Parameter constraints for ONAP constant parameters are optional for
2163 all parameter types other than number. If constraints are specified,
2164 they must adhere to the OpenStack specifications.
2166 - The ONAP Constant Parameter names must follow the ONAP orchestration
2167 parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2169 VNF Constant Parameters
2170 ++++++++++++++++++++++++
2172 - VNF Constant Parameters must be enumerated in the environment file.
2173 These parameter values are not assigned by ONAP.
2175 - When the VNF Constant Parameters type is set to number, the parameter
2176 must have constraints for range and/or allowed\_values.
2178 - Parameter constraints for ONAP constant parameters are optional for
2179 all parameter types other than number. If constraints are specified,
2180 they must adhere to the OpenStack specifications.
2182 - The VNF Constant Parameters names should follow the ONAP
2183 orchestration parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides
2189 The output parameters are parameters defined in the output section of a
2190 Heat Orchestration Template. The ONAP output parameters are subdivided
2191 into three categories:
2193 1. ONAP Base Module Output Parameters
2195 2. ONAP Volume Module Output Parameters
2197 3. ONAP Predefined Output Parameters.
2199 ONAP Base Module Output Parameters
2200 ++++++++++++++++++++++++++++++++++++
2202 ONAP Base Module Output Parameters are declared in the outputs: section
2203 of the base module Heat Orchestration Template. A Base Module Output
2204 Parameter is available as an input parameter (i.e., declared in the
2205 “parameters:” section) to all incremental modules in the VNF.
2207 - A Base Module Output Parameter may be used as an input parameter in
2208 an incremental module.
2210 - The Output parameter name and type must match the input parameter
2211 name and type unless the Output parameter is of the type
2212 comma\_delimited\_list.
2214 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2215 a collection of UUIDs from a Resource Group), then the
2216 corresponding input parameter must be declared as type json and
2217 not a comma\_delimited\_list, which is actually a string value
2218 with embedded commas.
2220 - When a Base Module Output Parameter is declared as an input parameter
2221 in an incremental module Heat Orchestration Template, parameter
2222 constraints must not be declared.
2224 Additional details on ONAP Base Module Output Parameters are provided in
2225 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2227 ONAP Volume Module Output Parameters
2228 ++++++++++++++++++++++++++++++++++++++
2230 The volume template output parameters are only available for the module
2231 (base or add on) that the volume is associated with.
2233 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2234 section of the Cinder volume module Heat Orchestration Template
2236 - An ONAP Volume Module Output Parameter is available as an input
2237 parameter (i.e., declared in the parameters: section) only for the
2238 module (base or incremental) that the Cinder volume module is
2241 - R-07443 The VNF Heat **MUST** match the Output parameter name and type with the
2242 input parameter name and type unless the Output parameter is of the
2243 type comma\_delimited\_list.
2245 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2246 collection of UUIDs from a Resource Group), then the corresponding
2247 input parameter must be declared as type json and not a
2248 comma\_delimited\_list, which is actually a string value with
2251 - When an ONAP Volume Module Output Parameter is declared as an input
2252 parameter in a base module or incremental module, parameter
2253 constraints must not be declared.
2255 Additional details on ONAP Base Module Output Parameters are provided in
2256 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2258 ONAP Predefined Output Parameters
2259 +++++++++++++++++++++++++++++++++++
2261 ONAP will look for a small set of pre-defined Heat output parameters to
2262 capture resource attributes for inventory in ONAP. These output
2263 parameters are optional and are specified in `OAM Management IP Addresses`_.
2265 Support of heat stack update
2266 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2268 VNF Heat Orchestration Templates must not be designed to utilize the
2269 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2270 does not support the use of heat stack-update command for scaling.
2272 It is important to note that ONAP only supports heat stack-update for
2278 ONAP defines two types of networks: External Networks and Internal
2281 ONAP defines an external network in relation to the VNF and not with
2282 regard to the Network Cloud site. External networks may also be referred
2283 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2285 - VMs in another VNF or
2287 - an external gateway or router
2289 ONAP defines an internal network in relation to the VNF and not with
2290 regard to the Network Cloud site. Internal networks may also be referred
2291 to as “intra-VNF” networks or “private” networks. An internal network
2292 only connects VMs in a single VNF. It must not connect to other VNFs or
2293 an external gateway or router.
2298 VNF Heat Orchestration Templates must not include any resources for
2299 external networks connected to the VNF. External networks must be
2300 orchestrated separately, as independent, stand-alone VNF Heat
2301 Orchestration Templates, so they can be shared by multiple VNFs and
2302 managed independently.
2304 When the external network is created, it must be assigned a unique
2305 {network-role}. The {network-role} should describe the network (e.g.,
2306 oam). The {network-role} while unique to the LCP, can repeat across
2309 An External Network may be a Neutron Network or a Contrail Network
2311 R-23983 The VNF **MUST** pass the external networks into the VNF Heat Orchestration
2312 Templates as parameters.
2314 - Neutron Network-id (UUID)
2316 - Neutron Network subnet ID (UUID)
2318 - Contrail Network Fully Qualified Domain Name (FQDN)
2320 ONAP enforces a naming convention for parameters associated with
2321 external networks. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2323 Parameter values associated with an external network will be generated
2324 and/or assigned by ONAP at orchestration time. Parameter values
2325 associated with an external network must not be enumerated in the
2326 environment file. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2328 VNFs may use **Cloud assigned IP addresses** or **ONAP SDN-C assigned IP addresses**
2329 when attaching VMs to an external network
2331 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2333 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2336 - Note that Neutron Floating IPs must not be used. ONAP does not
2337 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2339 - ONAP supports the property allowed\_address\_pairs in the resource
2340 OS::Neutron:Port and the property
2341 virtual\_machine\_interface\_allowed\_address\_pairs in
2342 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2343 of a virtual IP (VIP) address to a set of VMs.
2345 R-63345 The VNF Heat **MUST** pass the appropriate external
2346 network IDs into nested VM templates when nested Heat is used.
2351 R-35666 The VNF Heat **MUST** include the resource(s) to
2352 create the internal network. The internal network must be either a
2353 Neutron Network or a Contrail Network.
2355 R-86972 The VNF Heat **MUST** create internal networks in the Base
2356 Module, in the modular approach, with their resource IDs exposed as outputs (i.e., ONAP Base
2357 Module Output Parameters) for use by all incremental modules. If the
2358 Network resource ID is required in the base template, then a
2359 get\_resource must be used.
2361 R-68936 The VNF Heat **SHOULD** assign a unique
2362 {network-role} in the context of the VNF, when the internal network is
2363 created. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
2366 VNFs may use **Cloud assigned IP addresses** or
2367 **predetermined static IPs** when attaching VMs to an internal network.
2369 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2371 - A predetermined static IP address is enumerated in the Heat
2372 environment file. Since an internal network is local to the VNF, IP
2373 addresses can be re-used at every VNF instance.
2375 - Note that Neutron Floating IPs must not be used. ONAP does not
2376 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2378 - ONAP supports the property allowed\_address\_pairs in the resource
2379 OS::Neutron:Port and the property
2380 virtual\_machine\_interface\_allowed\_address\_pairs in
2381 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2382 of a virtual IP (VIP) address to a set of VMs.
2384 ONAP does not programmatically enforce a naming convention for
2385 parameters for internal network. However, a naming convention is
2386 provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
2388 ONAP Resource ID and Parameter Naming Convention
2389 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2391 This section provides the ONAP naming requirements for
2395 2. Resource Property Parameters
2400 R-01455 The VNF Heat **MUST** assign a VNF unique
2401 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2402 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2403 it does not have to be globally unique across all VNFs that ONAP
2406 R-82481 The VNF Heat **MUST** include {vm-type} as part of the parameter name
2407 for any parameter that is associated with a unique Virtual Machine type.
2409 R-66729 The VNF Heat **MUST** include {vm-type} as part of the resource ID
2410 for any resource ID that is associated with a unique Virtual Machine type in
2413 Note that {vm-type} must not be a substring of {network-role}. A
2414 substring of a string is another string that occurs "in". For example,
2415 "oam" is a substring of "oam\_protected". It will cause the
2416 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2417 produce erroneous error messages.
2419 The {vm-type} should not contain the string “\_int” or “int\_” or
2420 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2421 ICE Project) process to produce erroneous error messages.
2423 R-32394 The VNF Heat **MUST** use the same case for {vm-type} for all parameter names in the VNF.
2425 R-46839 The VNF Heat **MUST** use the same case for {vm-type} for all Resource IDs in the VNF.
2427 It is recommended that the {vm-type} case in the parameter names matches
2428 the {vm-type} case in the Resource IDs.
2430 There are two exceptions to the above rules:
2432 1. R-05008 The VNF Heat **MUST NOT** be prefixed with a common
2433 {vm-type} identifier for the six ONAP Metadata parameters. They are *vnf\_name*, *vnf\_id*,
2434 *vf\_module\_id*, *vf\_module\_name, vm\_role*. The ONAP Metadata
2435 parameters are described in `Resource: OS::Nova::Server – Metadata Parameters`_.
2437 2. R-15422 The VNF Heat **MUST NOT** be prefixed with a common {vm-type}
2438 identifier the parameter referring to the OS::Nova::Server property
2439 availability\_zone . availability\_zone is described in `Property: availability_zone`_.
2444 The assignment of a {network-role} is discussed in `Networking`_.
2446 R-21330 The VNF Heat **MUST** include
2447 the {network-role} as part of the parameter name for any parameter that is associated with an external network.
2449 R-11168 The VNF Heat **MUST** include
2450 the {network-role} as part of the resource ID for any resource ID that is associated with an external network must.
2452 R-84322 The VNF Heat **MUST** include
2453 int\_{network-role} as part of the parameter name for any parameter that is associated with an internal network.
2455 R-96983 The VNF Heat **MUST** include
2456 int\_{network-role} as part of the resource ID for any resource ID that is associated with an internal network.
2458 Note that {network-role} must not be a substring of {vm-type}. A
2459 substring of a string is another string that occurs "in". For example,
2460 "oam" is a substring of "oam\_protected". It will cause the
2461 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2462 produce erroneous error messages.
2464 The {network-role} should not contain the string “\_int” or “int\_” or
2465 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2466 ICE Project) process to produce erroneous error messages.
2468 R-58424 The VNF Heat **MUST** use the same case for {network-role} for all parameter names in the
2471 R-21511 The VNF Heat **MUST** use the same case for {network-role} for all Resource IDs in the VNF.
2473 It is recommended that the {network-role} case in the parameter names
2474 matches the {network-role} case in the Resource IDs.
2479 Heat Orchestration Template resources are described in `resources`_
2481 R-59629 The VNF Heat **MUST** have unique resource IDs within the resources section of a Heat
2482 Orchestration Template. This is an OpenStack Requirement.
2484 R-43319 The VNF Heat **MUST** have unique resource IDs
2485 across all modules that compose the VNF,
2486 when a VNF is composed of more than one Heat Orchestration Template
2489 R-54517 The VNF Heat **MUST** include {vm-type} in the resource ID
2490 when a resource is associated with a single {vm-type}.
2492 R-96482 The VNF Heat **MUST** include {network-role} in the resource ID
2493 when a resource is associated with a single external network.
2495 R-98138 The VNF Heat **MUST** include int\_{network-role} in the resource ID
2496 when a resource is associated with a single internal network.
2498 R-82115 The VNF Heat **MUST** include both the {vm-type} and
2499 {network-role} in the resource ID,
2500 when a resource is associated with a single {vm-type} and a single
2503 - The {vm-type} must appear before the {network-role} and must be
2504 separated by an underscore (i.e., {vm-type}\_{network-role}).
2506 - Note that an {index} value may separate the {vm-type} and the
2507 {network-role}. An underscore will separate the three values (i.e.,
2508 {vm-type}\_{index}\_{network-role}).
2510 R-82551 The VNF Heat **MUST** include both the {vm-type} and
2511 int\_{network-role} in the resource ID,
2512 when a resource is associated with a single {vm-type} and a single
2515 - The {vm-type} must appear before the int\_{network-role} and must be
2516 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2518 - Note that an {index} value may separate the {vm-type} and the
2519 int\_{network-role}. An underscore will separate the three values
2520 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2522 When a resource is associated with more than one {vm-type} and/or more
2523 than one network, the resource ID
2525 - must not contain the {vm-type} and/or
2526 {network-role}/int\_{network-role}
2528 - should contain the term “shared” and/or contain text that identifies
2531 R-69287 The VNF Heat **MUST** use only alphanumeric characters and “\_” underscores in the
2532 resource ID. Special characters must not be used.
2534 All {index} values must be zero based. That is, the {index} must start
2535 at zero and increment by one.
2537 The table below provides example OpenStack Heat resource ID for
2538 resources only associated with one {vm-type} and/or one network.
2540 +--------------------------------+------------------------------------------------------------+
2541 | Resource Type | Resource ID Format |
2542 +================================+============================================================+
2543 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2544 +--------------------------------+------------------------------------------------------------+
2545 | OS::Cinder::VolumeAttachment | {vm\_type}\_volumeattachment\_{index} |
2546 +--------------------------------+------------------------------------------------------------+
2547 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2548 +--------------------------------+------------------------------------------------------------+
2549 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2550 +--------------------------------+------------------------------------------------------------+
2551 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2552 +--------------------------------+------------------------------------------------------------+
2553 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2554 +--------------------------------+------------------------------------------------------------+
2555 | OS::Neutron::Port | {vm\_type}\_{index}\_{network\_role}\_{index}\_port |
2556 +--------------------------------+------------------------------------------------------------+
2557 | | {vm\_type}\_{index}\_int\_{network\_role}\_{index}\_port |
2558 +--------------------------------+------------------------------------------------------------+
2559 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2560 +--------------------------------+------------------------------------------------------------+
2561 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2562 +--------------------------------+------------------------------------------------------------+
2563 | OS::Nova::Server | {vm\_type}\_{index} |
2564 +--------------------------------+------------------------------------------------------------+
2565 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2566 +--------------------------------+------------------------------------------------------------+
2567 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2568 +--------------------------------+------------------------------------------------------------+
2570 Table 1: Example OpenStack Heat Resource ID
2572 The table below provides example Contrail Heat resource ID for resources
2573 only associated with one {vm-type} and/or one network.
2575 +-------------------------------------------+---------------------------------------------+
2576 | Resource Type | Resource ID Format |
2577 +===========================================+=============================================+
2578 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\_{network\_role}\_RII |
2579 +-------------------------------------------+---------------------------------------------+
2580 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2581 +-------------------------------------------+---------------------------------------------+
2582 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2583 +-------------------------------------------+---------------------------------------------+
2584 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2585 +-------------------------------------------+---------------------------------------------+
2586 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2587 +-------------------------------------------+---------------------------------------------+
2588 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2589 +-------------------------------------------+---------------------------------------------+
2590 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2591 +-------------------------------------------+---------------------------------------------+
2592 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2593 +-------------------------------------------+---------------------------------------------+
2595 Table 2: Example Contrail Heat resource ID
2597 Resource: OS::Nova::Server - Parameters
2598 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2600 The resource OS::Nova::Server manages the running virtual machine (VM)
2601 instance within an OpenStack cloud. (See
2602 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2604 Four properties of this resource must follow the ONAP parameter naming
2605 convention. The four properties are:
2613 4. availability\_zone
2615 The table below provides a summary. The sections that follow provides
2618 Note that the {vm\_type} must be identical across all four property
2619 parameters for a given OS::Nova::Server resource.
2621 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2622 | Resource OS::Nova::Server |
2623 +=============================+===============================+==================+==============================+=================================+
2624 | Property Name | ONAP Parameter Name | Parameter Type | Parameter Value Generation | ONAP Parameter Classification |
2625 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2626 | image | {vm-type}\_image\_name | string | Environment File | ONAP Constant |
2627 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2628 | flavor | {vm-type}\_flavor\_name | string | Environment File | ONAP Constant |
2629 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2630 | name | {vm-type}\_name\_{index} | string | ONAP | ONAP Orchestration |
2631 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2632 | | {vm-type}\_names | CDL | ONAP | ONAP Orchestration |
2633 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2634 | availability\_zone | availability\_zone\_{index} | string | ONAP | ONAP Orchestration |
2635 +-----------------------------+-------------------------------+------------------+------------------------------+---------------------------------+
2637 Table 3 Resource Property Parameter Names
2642 The parameter associated with the property image is an ONAP Constant
2645 The parameters must be named {vm-type}\_image\_name in the Heat
2646 Orchestration Template.
2648 R-71152 The VNF Heat **MUST** declare as type: string the parameter for property image.
2650 R-91125 The VNF Heat **MUST** enumerate the parameter for property image in the Heat Orchestration Template
2653 R-57282 The VNF Heat **MUST** have a separate parameter for image for
2654 Each VM type (i.e., {vm-type})
2655 even if more than one {vm-type} shares the same image. This provides
2656 maximum clarity and flexibility.
2658 *Example Parameter Definition*
2660 .. code-block:: yaml
2663 {vm-type}_image_name:
2665 description: {vm-type} server image
2670 The parameter associated with the property flavor is an ONAP Constant
2673 The parameters must be named {vm-type}\_flavor\_name in the Heat
2674 Orchestration Template.
2676 R-50436 The VNF Heat **MUST** declare the parameter property for flavor as type: string.
2678 R-69431 The VNF Heat **MUST** enumerate the parameter for property flavor in the Heat Orchestration Template
2681 R-40499 The VNF Heat **MUST** have a separate parameter for flavor for each VM type
2682 (i.e., {vm-type}) even if more than one {vm-type} shares the same flavor. This
2683 provides maximum clarity and flexibility.
2685 *Example Parameter Definition*
2687 .. code-block:: yaml
2690 {vm-type}_flavor_name:
2692 description: {vm-type} flavor
2697 The parameter associated with the property name is an ONAP Orchestration
2700 The parameter value is provided to the Heat template by ONAP.
2702 R-22838 The VNF Heat **MUST NOT** enumerate the parameter for property name
2703 in the environment file.
2705 R-51430 The VNF Heat **MUST** declare the parameter for property name as type: string or type:
2706 comma\_delimited\_list
2708 If the parameter is declared as type:string, the parameter must be named
2709 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2710 at zero and increments by one.
2712 If the parameter is declared as type:comma\_delimited\_list, the
2713 parameter must be named as {vm-type}\_names
2715 Each element in the VM Name list should be assigned to successive
2716 instances of that VM type.
2718 If a VNF contains more than three instances of a given {vm-type}, the
2719 comma\_delimited\_list form of the parameter name (i.e.,
2720 {vm-type}\_names) should be used to minimize the number of unique
2721 parameters defined in the Heat.
2723 *Example: Parameter Definition*
2725 .. code-block:: yaml
2729 type: comma_delimited_list
2730 description: VM Names for {vm-type} VMs
2731 {vm-type}_name_{index}:
2733 description: VM Name for {vm-type} VM {index}
2735 *Example: comma\_delimited\_list*
2737 In this example, the {vm-type} has been defined as “lb” for load
2740 .. code-block:: yaml
2744 type: comma_delimited_list
2745 description: VM Names for lb VMs
2749 type: OS::Nova::Server
2751 name: { get_param: [lb_names, 0] }
2755 type: OS::Nova::Server
2757 name: { get_param: [lb_names, 1] }
2760 *Example: fixed-index*
2762 In this example, the {vm-type} has been defined as “lb” for load
2765 .. code-block:: yaml
2770 description: VM Name for lb VM 0
2774 description: VM Name for lb VM 1
2778 type: OS::Nova::Server
2780 name: { get_param: lb_name_0 }
2784 type: OS::Nova::Server
2786 name: { get_param: lb_name_1 }
2789 Contrail Issue with Values for OS::Nova::Server Property Name
2790 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2792 The Contrail GUI has a limitation displaying special characters. The
2793 issue is documented in
2794 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2795 recommended that special characters be avoided. However, if special
2796 characters must be used, the only special characters supported are:
2798 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2800 Property: availability\_zone
2801 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2803 The parameter associated with the property availability\_zone is an ONAP
2804 Orchestration parameter.
2806 The parameter value is provided to the Heat template by ONAP. The
2807 parameter must not be enumerated in the environment file.
2809 R-98450 The VNF Heat **MUST** name the parameter availability\_zone\_{index} in the Heat
2810 Orchestration Template.
2812 R-13561 The VNF Heat **MUST** start the {index} at zero.
2814 R-60204 The VNF Heat **MUST** increment the {index} by one.
2816 R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name.
2818 The parameter must be declared as type: string
2820 The parameter must not be declared as type: comma\_delimited\_list
2825 The example below depicts part of a Heat Orchestration Template that
2826 uses the four OS::Nova::Server properties discussed in this section.
2828 In the Heat Orchestration Template below, four Virtual Machines
2829 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2830 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2831 parameter associated with the property name is a comma\_delimited\_list
2832 for dns and a string for oam.
2834 .. code-block:: yaml
2839 description: dns server image
2842 description: dns server flavor
2844 type: comma_delimited_list
2845 description: dns server names
2848 description: oam server image
2851 description: oam server flavor
2854 description: oam server name 0
2857 description: oam server name 1
2858 availability_zone_0:
2860 description: availability zone ID or Name
2861 availability_zone_1:
2863 description: availability zone ID or Name
2867 type: OS::Nova::Server
2869 name: { get_param: [ dns_names, 0 ] }
2870 image: { get_param: dns_image_name }
2871 flavor: { get_param: dns_flavor_name }
2872 availability_zone: { get_param: availability_zone_0 }
2876 type: OS::Nova::Server
2878 name: { get_param: [ dns_names, 1 ] }
2879 image: { get_param: dns_image_name }
2880 flavor: { get_param: dns_flavor_name }
2881 availability_zone: { get_param: availability_zone_1 }
2885 type: OS::Nova::Server
2887 name: { get_param: oam_name_0 }
2888 image: { get_param: oam_image_name }
2889 flavor: { get_param: oam_flavor_name }
2890 availability_zone: { get_param: availability_zone_0 }
2894 type: OS::Nova::Server
2896 name: { get_param: oam_name_1 }
2897 image: { get_param: oam_image_name }
2898 flavor: { get_param: oam_flavor_name }
2899 availability_zone: { get_param: availability_zone_1 }
2902 Resource: OS::Nova::Server – Metadata Parameters
2903 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2905 The resource OS::Nova::Server has an OpenStack optional property
2906 metadata. The metadata property is mandatory for ONAP Heat Orchestration
2907 Templates; it must be included.
2909 R-17020 The VNF Heat **MUST** include the following three mandatory metadata parameters for an
2910 OS::Nova::Server resource:
2918 ONAP allows the following three optional metadata parameters for an
2919 OS::Nova::Server resource. They may be included
2925 Note that the metadata parameters do not and must not contain {vm-type}
2928 When Metadata parameters are past into a nested heat template, the
2929 parameter names must not change.
2931 The table below provides a summary. The sections that follow provides
2934 +---------------------------+------------------+----------------------+------------------------------+
2935 | Metadata Parameter Name | Parameter Type | Mandatory/Optional | Parameter Value Generation |
2936 +===========================+==================+======================+==============================+
2937 | vnf\_id | string | Mandatory | ONAP |
2938 +---------------------------+------------------+----------------------+------------------------------+
2939 | vf\_module\_id | string | Mandatory | ONAP |
2940 +---------------------------+------------------+----------------------+------------------------------+
2941 | vnf\_name | string | Mandatory | ONAP |
2942 +---------------------------+------------------+----------------------+------------------------------+
2943 | vf\_module\_name | string | Optional | ONAP |
2944 +---------------------------+------------------+----------------------+------------------------------+
2945 | vm\_role | string | Optional | YAML or Environment File |
2946 +---------------------------+------------------+----------------------+------------------------------+
2947 +---------------------------+------------------+----------------------+------------------------------+
2949 Table 4: ONAP Metadata
2954 The vnf\_id parameter is mandatory; it must be included in the Heat
2955 Orchestration Template.
2957 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
2958 UUID that is the vnf\_id and supplies it to the Heat Orchestration
2959 Template at orchestration time.
2961 The parameter must be declared as type: string
2963 R-55218 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_id.
2965 R-20856 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_id in environment file.
2967 *Example Parameter Definition*
2969 .. code-block:: yaml
2974 description: Unique ID for this VNF instance
2979 The vf\_module\_id parameter is mandatory; it must be included in the
2980 Heat Orchestration Template.
2982 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
2983 generates the UUID that is the vf\_module\_id and supplies it to the
2984 Heat Orchestration Template at orchestration time.
2986 The parameter must be declared as type: string
2988 R-98374 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vf\_module\_id.
2990 R-72871 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vf\_module\_id in environment file.
2992 *Example Parameter Definition*
2994 .. code-block:: yaml
2999 description: Unique ID for this VNF module instance
3004 The vnf\_name parameter is mandatory; it must be included in the Heat
3005 Orchestration Template.
3007 The vnf\_name parameter value will be generated and/or assigned by ONAP
3008 and supplied to the Heat Orchestration Template by ONAP at orchestration
3011 The parameter must be declared as type: string
3013 R-44318 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_name.
3015 R-36542 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_name in the environment file.
3017 *Example Parameter Definition*
3019 .. code-block:: yaml
3024 description: Unique name for this VNF instance
3029 The vf\_module\_name parameter is optional; it may be included in the
3030 Heat Orchestration Template.
3032 The vf\_module\_name parameter is the name of the name of the Heat stack
3033 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3034 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3035 needs to be specified as part of the orchestration process.
3037 The parameter must be declared as type: string
3039 Parameter constraints must not be defined.
3041 The parameter must not be enumerated in the Heat environment file.
3043 *Example Parameter Definition*
3045 .. code-block:: yaml
3050 description: Unique name for this VNF Module instance
3055 The vm\_role parameter is optional; it may be included in the Heat
3056 Orchestration Template.
3058 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3059 system and available for use by other ONAP components and/or north bound
3062 The vm\_role values must be either
3064 - hard-coded into the Heat Orchestration Template or
3066 - enumerated in the environment file.
3068 Defining the vm\_role as the {vm-type} is a recommended convention
3070 The parameter must be declared as type: string
3072 Parameter constraints must not be defined.
3074 *Example Parameter Definition*
3076 .. code-block:: yaml
3081 description: Unique role for this VM
3083 *Example Resource Definition: Hard Coded*
3085 In this example, the {vm-role} is hard coded in the Heat Orchestration
3088 .. code-block:: yaml
3092 type: OS::Nova::Server
3098 *Example Resource Definition: get\_param*
3100 In this example, the {vm-role} is enumerated in the environment file.
3102 .. code-block:: yaml
3106 type: OS::Nova::Server
3110 vm_role: { get_param: vm_role }
3115 The example below depicts part of a Heat Orchestration Template that
3116 uses the five of the OS::Nova::Server metadata parameter discussed in
3117 this section. The {vm-type} has been defined as lb for load balancer.
3119 .. code-block:: yaml
3124 description: VM Name for lb VM 0
3127 description: Unique name for this VNF instance
3130 description: Unique ID for this VNF instance
3133 description: Unique name for this VNF Module instance
3136 description: Unique ID for this VNF Module instance
3139 description: Unique role for this VM
3144 type: OS::Nova::Server
3146 name: { get_param: lb_name_0 }
3149 vnf_name: { get_param: vnf_name }
3150 vnf_id: { get_param: vnf_id }
3151 vf_module_name: { get_param: vf_module_name }
3152 vf_module_id: { get_param: vf_module_id }
3155 Resource: OS::Neutron::Port - Parameters
3156 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3158 The resource OS::Neutron::Port is for managing Neutron ports (See
3159 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3164 Four properties of the resource OS::Neutron::Port that must follow the
3165 ONAP parameter naming convention. The four properties are:
3169 2. fixed\_ips, ip\_address
3171 3. fixed\_ips, subnet\_id
3173 4. allowed\_address\_pairs, ip\_address
3175 The parameters associated with these properties may reference an
3176 external network or internal network. External networks and internal
3177 networks are defined in `Networking`_.
3182 When the parameter references an external network
3184 - R-72050 The VNF Heat **MUST** contain {network-role} in the parameter name
3186 - the parameter must not be enumerated in the Heat environment file
3188 - the parameter is classified as an ONAP Orchestration Parameter
3190 +----------------------------------------+-----------------------------------------------+--------------------------+
3191 | Property Name | ONAP Parameter Name | Parameter Type |
3192 +========================================+===============================================+==========================+
3193 | network | {network-role}\_net\_id | string |
3194 +----------------------------------------+-----------------------------------------------+--------------------------+
3195 | | {network-role}\_net\_name | string |
3196 +----------------------------------------+-----------------------------------------------+--------------------------+
3197 | fixed\_ips, ip\_address | {vm-type}\_{network-role}\_ip\_{index} | string |
3198 +----------------------------------------+-----------------------------------------------+--------------------------+
3199 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3200 +----------------------------------------+-----------------------------------------------+--------------------------+
3201 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3202 +----------------------------------------+-----------------------------------------------+--------------------------+
3203 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3204 +----------------------------------------+-----------------------------------------------+--------------------------+
3205 | fixed\_ips, subnet | {network-role}\_subnet\_id | string |
3206 +----------------------------------------+-----------------------------------------------+--------------------------+
3207 | | {network-role}\_v6\_subnet\_id | string |
3208 +----------------------------------------+-----------------------------------------------+--------------------------+
3209 | allowed\_address\_pairs, ip\_address | {vm-type}\_{network-role}\_floating\_ip | string |
3210 +----------------------------------------+-----------------------------------------------+--------------------------+
3211 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
3212 +----------------------------------------+-----------------------------------------------+--------------------------+
3213 | | {vm-type}\_{network-role}\_ip\_{index} | string |
3214 +----------------------------------------+-----------------------------------------------+--------------------------+
3215 | | {vm-type}\_{network-role}\_ips | comma\_delimited\_list |
3216 +----------------------------------------+-----------------------------------------------+--------------------------+
3217 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
3218 +----------------------------------------+-----------------------------------------------+--------------------------+
3219 | | {vm-type}\_{network-role}\_v6\_ips | comma\_delimited\_list |
3220 +----------------------------------------+-----------------------------------------------+--------------------------+
3222 Table 5: OS::Neutron::Port Resource Property Parameters (External
3228 When the parameter references an internal network
3230 - R-57576 The VNF Heat **MUST** contain int\_{network-role} in the parameter name.
3232 - the parameter may be enumerated in the environment file.
3234 +----------------------------------------+----------------------------------------------------+--------------------------+
3235 | Property | Parameter Name for Internal Networks | Parameter Type |
3236 +========================================+====================================================+==========================+
3237 | network | int\_{network-role}\_net\_id | string |
3238 +----------------------------------------+----------------------------------------------------+--------------------------+
3239 | | int\_{network-role}\_net\_name | string |
3240 +----------------------------------------+----------------------------------------------------+--------------------------+
3241 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3242 +----------------------------------------+----------------------------------------------------+--------------------------+
3243 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3244 +----------------------------------------+----------------------------------------------------+--------------------------+
3245 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3246 +----------------------------------------+----------------------------------------------------+--------------------------+
3247 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3248 +----------------------------------------+----------------------------------------------------+--------------------------+
3249 | fixed\_ips, subnet | int\_{network-role}\_subnet\_id | string |
3250 +----------------------------------------+----------------------------------------------------+--------------------------+
3251 | | int\_{network-role}\_v6\_subnet\_id | string |
3252 +----------------------------------------+----------------------------------------------------+--------------------------+
3253 | allowed\_address\_pairs, ip\_address | {vm-type}\_int\_{network-role}\_floating\_ip | string |
3254 +----------------------------------------+----------------------------------------------------+--------------------------+
3255 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
3256 +----------------------------------------+----------------------------------------------------+--------------------------+
3257 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
3258 +----------------------------------------+----------------------------------------------------+--------------------------+
3259 | | {vm-type}\_int\_{network-role}\_ips | comma\_delimited\_list |
3260 +----------------------------------------+----------------------------------------------------+--------------------------+
3261 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
3262 +----------------------------------------+----------------------------------------------------+--------------------------+
3263 | | {vm-type}\_int\_{network-role}\_v6\_ips | comma\_delimited\_list |
3264 +----------------------------------------+----------------------------------------------------+--------------------------+
3266 Table 6: Port Resource Property Parameters (Internal Networks)
3271 The property networks in the resource OS::Neutron::Port must be
3272 referenced by Neutron Network ID, a UUID value, or by the network name
3273 defined in OpenStack.
3278 R-93272 The VNF Heat **MUST** adhere to the following parameter naming
3279 convention in the Heat Orchestration Template, when the parameter associated with the property network is referencing
3280 an “external” network:
3282 - {network-role}\_net\_id for the Neutron network ID
3284 - {network-role}\_net\_name for the network name in OpenStack
3286 The parameter must be declared as type: string
3288 The parameter must not be enumerated in the Heat environment file.
3290 *Example Parameter Definition*
3292 .. code-block:: yaml
3295 {network-role}_net_id:
3297 description: Neutron UUID for the {network-role} network
3298 {network-role}_net_name:
3300 description: Neutron name for the {network-role} network
3302 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3303 that has only one subnet*
3305 In this example, the {network-role} has been defined as oam to represent
3306 an oam network and the {vm-type} has been defined as lb for load
3307 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3308 to assign IP addresses.
3310 .. code-block:: yaml
3315 description: Neutron UUID for the oam network
3319 type: OS::Neutron::Port
3320 network: { get_param: oam_net_id }
3325 R-65373 The VNF Heat **MUST** adhere to the following parameter naming
3326 convention, when the parameter associated with the property network is referencing
3327 an “internal” network:
3329 - int\_{network-role}\_net\_id for the Neutron network ID
3331 - int\_{network-role}\_net\_name for the network name in OpenStack
3333 The parameter must be declared as type: string
3335 The assumption is that internal networks are created in the base module.
3336 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3337 Base Module Output Parameter) to the incremental modules. In the
3338 incremental modules, it will be defined as input parameter.
3340 *Example Parameter Definition*
3342 .. code-block:: yaml
3345 int_{network-role}_net_id:
3347 description: Neutron UUID for the {network-role} network
3348 int_{network-role}_net_name:
3350 description: Neutron name for the {network-role} network
3352 Property: fixed\_ips, Map Property: subnet\_id
3353 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3355 The property fixed\_ips is used to assign IPs to a port. The Map
3356 Property subnet\_id specifies the subnet the IP is assigned from.
3358 The property fixed\_ips and Map Property subnet\_id must be used if a
3359 Cloud (i.e., DHCP) IP address assignment is being requested and the
3360 Cloud IP address assignment is targeted at a specific subnet when two or
3363 The property fixed\_ips and Map Property subnet\_id should not be used
3364 if all IP assignments are fixed, or if the Cloud IP address assignment
3365 does not target a specific subnet or there is only one subnet.
3367 Note that DHCP assignment of IP addresses is also referred to as cloud
3368 assigned IP addresses.
3370 Subnet of an External Networks
3371 +++++++++++++++++++++++++++++++
3373 R-47716 The VNF Heat **MUST** adhere to the following parameter naming convention
3374 for the property fixed\_ips and Map Property subnet\_id parameter,
3375 when the parameter is referencing a subnet of an “external” network.
3377 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3379 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3381 The parameter must be declared as type: string
3383 The parameter must not be enumerated in the Heat environment file.
3385 *Example Parameter Definition*
3387 .. code-block:: yaml
3390 {network-role}_subnet_id:
3392 description: Neutron subnet UUID for the {network-role} network
3394 {network-role}_v6_subnet_id:
3396 description: Neutron subnet UUID for the {network-role} network
3398 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3399 that has two or more subnets subnet:*
3401 In this example, the {network-role} has been defined as oam to represent
3402 an oam network and the {vm-type} has been defined as lb for load
3403 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3404 to assign IP addresses.
3406 .. code-block:: yaml
3411 description: Neutron UUID for the oam network
3415 description: Neutron subnet UUID for the oam network
3419 type: OS::Neutron::Port
3420 network: { get_param: oam_net_id }
3422 - subnet_id: { get_param: oam_subnet_id }
3424 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3425 address assigned to a network that has at least one IPv4 subnet and one
3428 In this example, the {network-role} has been defined as oam to represent
3429 an oam network and the {vm-type} has been defined as lb for load
3432 .. code-block:: yaml
3437 description: Neutron UUID for the oam network
3441 description: Neutron subnet UUID for the oam network
3445 description: Neutron subnet UUID for the oam network
3449 type: OS::Neutron::Port
3451 network: { get_param: oam_net_id }
3453 - subnet_id: { get_param: oam_subnet_id }
3454 - subnet_id: { get_param: oam_v6_subnet_id }
3459 R-20106 The VNF Heat **MUST** adhere to the following naming convention for
3460 the property fixed\_ips and Map Property subnet\_id parameter,
3461 when the parameter is referencing the subnet of an “internal” network:
3463 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3465 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3467 The parameter must be declared as type: string
3469 The assumption is that internal networks are created in the base module.
3470 The Neutron subnet network ID will be passed as an output parameter
3471 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3472 the incremental modules, it will be defined as input parameter.
3474 *Example Parameter Definition*
3476 .. code-block:: yaml
3479 int_{network-role}_subnet_id:
3481 description: Neutron subnet UUID for the {network-role} network
3483 int_{network-role}_v6_subnet_id:
3485 description: Neutron subnet UUID for the {network-role} network
3487 Property: fixed\_ips, Map Property: ip\_address
3488 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3490 The property fixed\_ips is used to assign IPs to a port. The Map
3491 Property ip\_address specifies the IP address to be assigned to the
3494 The property fixed\_ips and Map Property ip\_address must be used when
3495 statically assigning one or more IP addresses to a port. This is also
3496 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3497 the IP address assignment.
3499 An IP address is assigned to a port on a VM (referenced by {vm-type})
3500 that is connected to an external network (referenced by {network-role})
3501 or internal network (referenced by int\_{network-role}).
3503 R-41177 The VNF Heat **MUST** include {vm-type} and {network-role} in the parameter name,
3504 when a SDN-C IP assignment is made to a port connected to an external network.
3506 When a SDN-C IP assignment is made to a port connected to an internal
3507 network, the parameter name must contain {vm-type} and
3508 int\_{network-role}.
3510 IP Address Assignments on External Networks
3511 ++++++++++++++++++++++++++++++++++++++++++++
3513 When the property fixed\_ips and Map Property ip\_address is used to
3514 assign IP addresses to an external network, the parameter name is
3515 dependent on the parameter type (comma\_delimited\_list or string) and
3516 IP address type (IPv4 or IPv6).
3518 R-84898 The VNF Heat **MUST** adhere to the following naming convention,
3519 when the parameter for property fixed\_ips and Map Property ip\_address
3520 is declared type: comma\_delimited\_list:
3522 - {vm-type}\_{network-role}\_ips for IPv4 address
3524 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3526 Each element in the IP list should be assigned to successive instances
3527 of {vm-type} on {network-role}.
3529 The parameter must not be enumerated in the Heat environment file.
3531 *Example Parameter Definition*
3533 .. code-block:: yaml
3537 {vm-type}_{network-role}_ips:
3538 type: comma_delimited_list
3539 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3541 {vm-type}_{network-role}_v6_ips:
3542 type: comma_delimited_list
3543 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3545 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3546 Assignments to an external network*
3548 In this example, the {network-role} has been defined as oam to represent
3549 an oam network and the {vm-type} has been defined as db for database.
3551 .. code-block:: yaml
3556 description: Neutron UUID for a oam network
3559 type: comma_delimited_list
3560 description: Fixed IPv4 assignments for db VMs on the oam network
3563 type: comma_delimited_list
3564 description: Fixed IPv6 assignments for db VMs on the oam network
3568 type: OS::Neutron::Port
3569 network: { get_param: oam_net_id }
3570 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3573 type: OS::Neutron::Port
3575 network: { get_param: oam_net_id }
3577 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3578 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3580 R-34960 The VNF Heat **MUST** adhere to the following
3582 when the parameter for property fixed\_ips and Map Property ip\_address
3583 is declared type: string:
3585 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3587 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3589 The value for {index} must start at zero (0) and increment by one.
3591 The parameter must not be enumerated in the Heat environment file.
3593 *Example Parameter Definition*
3595 .. code-block:: yaml
3598 {vm-type}_{network-role}_ip_{index}:
3600 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3602 {vm-type}_{network-role}_v6_ip_{index}:
3604 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3606 *Example: string parameters for IPv4 and IPv6 Address Assignments to an external network*
3608 In this example, the {network-role} has been defined as “oam” to
3609 represent an oam network and the {vm-type} has been defined as “db” for
3612 .. code-block:: yaml
3617 description: Neutron UUID for an OAM network
3621 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3625 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3629 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3633 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3637 type: OS::Neutron::Port
3639 network: { get_param: oam_net_id }
3640 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3643 type: OS::Neutron::Port
3645 network: { get_param: oam_net_id }
3647 - “ip_address”: {get_param: db_oam_ip_1}}]
3648 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3650 IP Address Assignment on Internal Networks
3651 ++++++++++++++++++++++++++++++++++++++++++++
3653 When the property fixed\_ips and Map Property ip\_address is used to
3654 assign IP addresses to an internal network, the parameter name is
3655 dependent on the parameter type (comma\_delimited\_list or string) and
3656 IP address type (IPv4 or IPv6).
3658 R-62584 The VNF Heat **MUST** adhere to
3659 the following naming convention,
3660 when the parameter for property fixed\_ips and Map Property ip\_address
3661 is declared type: comma\_delimited\_list:
3663 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3665 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3667 Each element in the IP list should be assigned to successive instances
3668 of {vm-type} on {network-role}.
3670 The parameter must be enumerated in the Heat environment file. Since an
3671 internal network is local to the VNF, IP addresses can be re-used at
3674 *Example Parameter Definition*
3676 .. code-block:: yaml
3680 {vm-type}_int_{network-role}_ips:
3681 type: comma_delimited_list
3682 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3684 {vm-type}_int_{network-role}_v6_ips:
3685 type: comma_delimited_list
3686 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3688 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3689 Assignments to an internal network*
3691 In this example, the {network-role} has been defined as oam\_int to
3692 represent an oam network internal to the vnf. The role oam\_int was
3693 picked to differentiate from an external oam network with a
3694 {network-role} of oam. The {vm-type} has been defined as db for
3697 .. code-block:: yaml
3702 description: Neutron UUID for the oam internal network
3705 type: comma_delimited_list
3706 description: Fixed IPv4 assignments for db VMs on the oam internal network
3708 db_int_oam_int_v6_ips:
3709 type: comma_delimited_list
3710 description: Fixed IPv6 assignments for db VMs on the oam internal network
3714 type: OS::Neutron::Port
3716 network: { get_param: int_oam_int_net_id }
3717 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3720 type: OS::Neutron::Port
3722 network: { get_param: int_oam_int_net_id }
3724 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3725 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3727 R-29256 The VNF Heat **MUST** must adhere to the following
3729 when the parameter for property fixed\_ips and Map Property ip\_address
3730 is declared type: string:
3732 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3734 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3736 The value for {index} must start at zero (0) and increment by one.
3738 The parameter must be enumerated in the Heat environment file. Since an
3739 internal network is local to the VNF, IP addresses can be re-used at
3742 *Example Parameter Definition*
3744 .. code-block:: yaml
3748 {vm-type}_int_{network-role}_ip_{index}:
3750 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3752 {vm-type}_int_{network-role}_v6_ip_{index}:
3754 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3756 *Example: string parameters for IPv4 and IPv6 Address Assignments to an internal network*
3758 In this example, the {network-role} has been defined as oam\_int to
3759 represent an oam network internal to the vnf. The role oam\_int was
3760 picked to differentiate from an external oam network with a
3761 {network-role} of oam. The {vm-type} has been defined as db for
3764 .. code-block:: yaml
3769 description: Neutron UUID for an OAM internal network
3773 description: Fixed IPv4 assignment for db VM on the oam_int network
3777 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3781 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3785 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3789 type: OS::Neutron::Port
3791 network: { get_param: int_oam_int_net_id }
3792 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3795 type: OS::Neutron::Port
3797 network: { get_param: int_oam_int_net_id }
3799 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3800 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3802 Property: allowed\_address\_pairs, Map Property: ip\_address
3803 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3805 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3806 allows the user to specify a mac\_address and/or ip\_address that will
3807 pass through a port regardless of subnet. This enables the use of
3808 protocols such as VRRP, which floats an IP address between two instances
3809 to enable fast data plane failover. The map property ip\_address
3810 specifies the IP address.
3812 The allowed\_address\_pairs is an optional property. It is not required.
3814 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3815 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3816 and {network-role}/int\_{network-role} combination.
3818 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3819 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3820 and {network-role}/int\_{network-role} combination.
3822 Note that the management of these IP addresses (i.e. transferring
3823 ownership between active and standby VMs) is the responsibility of the
3826 Note that these parameters are **not** intended to represent Neutron
3827 “Floating IP” resources, for which OpenStack manages a pool of public IP
3828 addresses that are mapped to specific VM ports. In that case, the
3829 individual VMs are not even aware of the public IPs, and all assignment
3830 of public IPs to VMs is via OpenStack commands. ONAP does not support
3831 Neutron-style Floating IPs.
3836 R-61282 The VNF Heat **MUST**
3837 adhere to the following naming convention for the property
3838 allowed\_address\_pairs and Map Property ip\_address parameter,
3839 when the parameter is referencing an “external” network:
3841 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3843 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3845 The parameter must be declared as type: string
3847 The parameter must not be enumerated in the Heat environment file.
3849 *Example Parameter Definition*
3851 .. code-block:: yaml
3855 {vm-type}_{network-role}_floating_ip:
3857 description: VIP for {vm-type} VMs on the {network-role} network
3859 {vm-type}_{network-role}_floating_v6_ip:
3861 description: VIP for {vm-type} VMs on the {network-role} network
3865 In this example, the {network-role} has been defined as oam to represent
3866 an oam network and the {vm-type} has been defined as db for database.
3868 .. code-block:: yaml
3873 description: Neutron UUID for the oam network
3876 type: comma_delimited_list
3877 description: Fixed IPs for db VMs on the oam network
3881 description: VIP IP for db VMs on the oam network
3885 type: OS::Neutron::Port
3887 network: { get_param: oam_net_id }
3888 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
3889 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3892 type: OS::Neutron::Port
3894 network: { get_param: oam_net_id }
3895 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
3896 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
3901 R-16805 The VNF Heat **MUST** adhere to the following naming convention for the property
3902 allowed\_address\_pairs and Map Property ip\_address parameter
3903 when the parameter is referencing an “internal” network.
3905 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
3907 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
3909 The parameter must be declared as type: string
3911 The parameter must be enumerated in the Heat environment file.
3913 *Example Parameter Definition*
3915 .. code-block:: yaml
3919 {vm-type}_int_{network-role}_floating_ip:
3921 description: VIP for {vm-type} VMs on the int_{network-role} network
3923 {vm-type}_int_{network-role}_floating_v6_ip:
3925 description: VIP for {vm-type} VMs on the int_{network-role} network
3927 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
3928 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3930 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
3931 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
3933 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
3934 one allowed address pair IPv6 address per {vm-type} and {network-role}
3937 If there is a need for multiple allowed address pair IPs for a given
3938 {vm-type} and {network-role} combination within a VNF, then the
3939 parameter names defined for the property fixed\_ips and Map Property
3940 ip\_address should be used with the allowed\_address\_pairs property.
3941 The examples below illustrate this.
3943 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
3945 In this example, there are two administrative VM pairs. Each pair has
3946 one VIP. The {network-role} has been defined as oam to represent an oam
3947 network and the {vm-type} has been defined as admin for an
3950 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
3951 VIP, [admin\_oam\_ips,2]
3953 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
3954 VIP, [admin\_oam\_ips,5]
3956 .. code-block:: yaml
3961 description: Neutron UUID for the oam network
3963 type: comma_delimited_list
3964 description: Fixed IP assignments for admin VMs on the oam network
3969 type: OS::Neutron::Port
3971 network: { get_param: oam_net_id }
3972 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
3973 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3976 type: OS::Neutron::Port
3978 network: { get_param: oam_net_id }
3979 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
3980 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
3983 type: OS::Neutron::Port
3985 network: { get_param: oam_net_id }
3986 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
3987 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3990 type: OS::Neutron::Port
3992 network: { get_param: oam_net_id }
3993 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
3994 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
3996 *Example: A VNF has two load balancers. The pair of load balancers share
3999 In this example, there is one load balancer pairs. The pair has two
4000 VIPs. The {network-role} has been defined as oam to represent an oam
4001 network and the {vm-type} has been defined as lb for a load balancer VM.
4003 .. code-block:: yaml
4007 type: OS::Neutron::Port
4009 network: { get_param: oam_net_id }
4010 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
4011 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4014 type: OS::Neutron::Port
4016 network: { get_param: oam_net_id }
4017 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
4018 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4020 As a general rule, provide the fixed IPs for the VMs indexed first in
4021 the CDL and then the VIPs as shown in the examples above.
4023 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
4024 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4026 The following items must be taken into consideration when designing Heat
4027 Orchestration Templates that expect ONAP’s SDN-C to assign
4028 allowed\_address\_pair IP addresses via automation.
4030 The VMs must be of the same {vm-type}.
4032 The VMs must be created in the same module (base or incremental).
4034 Resource Property “name”
4035 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4037 The parameter naming convention of the property name for the resource
4038 OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
4040 This section provides the requirements how the property name for non
4041 OS::Nova::Server resources must be defined when the property is used.
4042 Not all resources require the property name (e.g., it is optional) and
4043 some resources do not support the property.
4045 R-85734 The VNF Heat **MUST** use the intrinsic function str\_replace
4046 in conjunction with the ONAP supplied metadata parameter
4047 vnf\_name to generate a unique value,
4048 when the property name for a non OS::Nova::Server resources is defined
4049 in a Heat Orchestration Template.
4051 This prevents the enumeration of a
4052 unique value for the property name in a per instance environment file.
4056 - In most cases, only the use of the metadata value vnf\_name is
4057 required to create a unique property name
4059 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4060 may also be used in the str\_replace construct to generate a unique
4061 name when the vnf\_name does not provide uniqueness
4063 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4065 .. code-block:: yaml
4069 type: OS::Neutron::SecurityGroup
4071 description: vDNS security group
4074 template: VNF_NAME_sec_grp_DNS
4076 VNF_NAME: {get_param: vnf_name}
4080 *Example: Property name for resource* OS::Cinder::Volume
4082 .. code-block:: yaml
4086 type: OS::Cinder::Volume
4088 description: Cinder Volume
4091 template: VNF_NAME_STACK_NAME_dns_volume
4093 VNF_NAME: {get_param: vnf_name}
4094 STACK_NAME: { get_param: 'OS::stack_name' }
4097 Contrail Issue with Values for the Property Name
4098 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4100 The Contrail GUI has a limitation displaying special characters. The
4101 issue is documented in
4102 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4103 recommended that special characters be avoided. However, if special
4104 characters must be used, note that for the following resources:
4118 the only special characters supported are:
4120 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4122 ONAP Output Parameter Names
4123 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4125 ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
4127 ONAP Base Module Output Parameters:
4128 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4130 ONAP Base Module Output Parameters do not have an explicit naming
4131 convention. The parameter name must contain {vm-type} and {network-role}
4134 ONAP Volume Template Output Parameters:
4135 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4137 ONAP Base Module Output Parameters do not have an explicit naming
4138 convention. The parameter name must contain {vm-type} when appropriate.
4140 Predefined Output Parameters
4141 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4143 ONAP currently defines one predefined output parameter the OAM
4144 Management IP Addresses.
4146 OAM Management IP Addresses
4147 +++++++++++++++++++++++++++++
4149 A VNF may have a management interface for application controllers to
4150 interact with and configure the VNF. Typically, this will be via a
4151 specific VM that performs a VNF administration function. The IP address
4152 of this interface must be captured and inventoried by ONAP. The IP
4153 address might be a VIP if the VNF contains an HA pair of management VMs,
4154 or may be a single IP address assigned to one VM.
4156 The Heat template may define either (or both) of the following Output
4157 parameters to identify the management IP address.
4159 - oam\_management\_v4\_address
4161 - oam\_management\_v6\_address
4165 - The use of this output parameters are optional.
4167 - The Management IP Address should be defined only once per VNF, so it
4168 must only appear in one Module template
4170 - If a fixed IP for the admin VM is passed as an input parameter, it
4171 may be echoed in the output parameters. In this case, a IPv4 and/or
4172 IPv6 parameter must be defined in the parameter section of the YAML
4173 Heat template. The parameter maybe named oam\_management\_v4\_address
4174 and/or oam\_management\_v6\_address or may be named differently.
4176 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4177 from the resource attributes. In this case,
4178 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4179 not be defined in the parameter section of the YAML Heat template.
4181 *Example: SDN-C Assigned IP Address echoed as*
4182 oam\_management\_v4\_address
4184 .. code-block:: yaml
4189 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
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 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4203 security_groups: [{ get_param: security_group }]
4206 type: OS::Nova::Server
4208 name: { get_param: admin_names }
4209 image: { get_param: admin_image_name }
4210 flavor: { get_param: admin_flavor_name }
4211 availability_zone: { get_param: availability_zone_0 }
4213 - port: { get_resource: admin_oam_net_0_port }
4215 vnf_id: { get_param: vnf_id }
4216 vf_module_id: { get_param: vf_module_id }
4217 vnf_name: {get_param: vnf_name }
4219 oam_management_v4_address:
4220 value: {get_param: admin_oam_ip_0 }
4222 *Example: Cloud Assigned IP Address output as*
4223 oam\_management\_v4\_address
4225 .. code-block:: yaml
4230 admin_oam_net_0_port:
4231 type: OS::Neutron::Port
4235 template: VNF_NAME_admin_oam_net_0_port
4237 VNF_NAME: {get_param: vnf_name}
4238 network: { get_param: oam_net_id }
4239 security_groups: [{ get_param: security_group }]
4242 type: OS::Nova::Server
4244 name: { get_param: admin_names }
4245 image: { get_param: admin_image_name }
4246 flavor: { get_param: admin_flavor_name }
4247 availability_zone: { get_param: availability_zone_0 }
4249 - port: { get_resource: admin_oam_net_0_port }
4251 vnf_id: { get_param: vnf_id }
4252 vf_module_id: { get_param: vf_module_id }
4253 vnf_name: {get_param: vnf_name }
4256 oam_management_v4_address:
4257 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4259 Contrail Resource Parameters
4260 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4262 ONAP requires the parameter names of certain Contrail Resources to
4263 follow specific naming conventions. This section provides these
4266 Contrail Network Parameters
4267 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4269 Contrail based resources may require references to a Contrail network
4270 using the network FQDN.
4275 When the parameter associated with the Contrail Network is referencing
4276 an “external” network, the parameter must adhere to the following naming
4277 convention in the Heat Orchestration Template
4279 - {network-role}\_net\_fqdn
4281 The parameter must be declared as type: string
4283 The parameter must not be enumerated in the Heat environment file.
4285 *Example: Parameter declaration*
4287 .. code-block:: yaml
4290 {network-role}_net_fqdn:
4292 description: Contrail FQDN for the {network-role} network
4294 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4295 Reference to a Network FQDN.*
4297 In this example, the {network-role} has been defined as oam to represent
4298 an oam network and the {vm-type} has been defined as fw for firewall.
4299 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4300 virtual\_network\_refs references a contrail network FQDN.
4302 .. code-block:: yaml
4305 type: OS::ContrailV2::VirtualMachineInterface
4309 template: VM_NAME_virtual_machine_interface_1
4311 VM_NAME: { get_param: fw_name_0 }
4312 virtual_machine_interface_properties:
4313 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4314 virtual_network_refs:
4315 - get_param: oam_net_fqdn
4316 security_group_refs:
4317 - get_param: fw_sec_grp_id
4319 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4320 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4322 The parameter associated with the resource
4323 OS::ContrailV2::InterfaceRouteTable property
4324 interface\_route\_table\_routes, map property
4325 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4328 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4329 in the Heat Orchestration Template.
4331 The parameter must be declared as type: json
4333 The parameter supports IP addresses in the format:
4335 1. Host IP Address (e.g., 10.10.10.10)
4337 2. CIDR Notation format (e.g., 10.0.0.0/28)
4339 The parameter must not be enumerated in the Heat environment file.
4341 *Example Parameter Definition*
4343 .. code-block:: yaml
4346 {vm-type}_{network-role}_route_prefixes:
4348 description: JSON list of Contrail Interface Route Table route prefixes
4352 .. code-block:: yaml
4357 description: Unique name for this VF instance
4358 fw_int_fw_route_prefixes:
4360 description: prefix for the ServiceInstance InterfaceRouteTable
4361 int_fw_dns_trusted_interface_type:
4363 description: service_interface_type for ServiceInstance
4366 type: OS::ContrailV2::InterfaceRouteTable
4367 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4371 template: VNF_NAME_interface_route_table
4373 VNF_NAME: { get_param: vnf_name }
4374 interface_route_table_routes:
4375 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4376 service_instance_refs:
4377 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4378 service_instance_refs_data:
4379 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4381 Parameter Names in Contrail Resources
4382 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4384 Contrail Heat resource properties will use, when appropriate, the same
4385 naming convention as OpenStack Heat resources. For example, the resource
4386 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4387 convention is identical to properties in OS::Neutron::Port.
4389 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4390 instance\_ip\_address*
4392 The property instance\_ip\_address uses the same parameter naming
4393 convention as the property fixed\_ips and Map Property ip\_address in
4394 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4395 Address. The {network-role} has been defined as oam\_protected to
4396 represent an oam protected network and the {vm-type} has been defined as
4399 .. code-block:: yaml
4401 CMD_FW_OAM_PROTECTED_RII:
4402 type: OS::ContrailV2::InstanceIp
4404 - FW_OAM_PROTECTED_RVMI
4406 virtual_machine_interface_refs:
4407 - get_resource: FW_OAM_PROTECTED_RVMI
4408 virtual_network_refs:
4409 - get_param: oam_protected_net_fqdn
4410 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4412 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4415 The property instance\_ip\_address uses the same parameter naming
4416 convention as the property fixed\_ips and Map Property subnet\_id in
4417 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4418 Address. The {network-role} has been defined as “oam\_protected” to
4419 represent an oam protected network and the {vm-type} has been defined as
4422 .. code-block:: yaml
4424 CMD_FW_SGI_PROTECTED_RII:
4425 type: OS::ContrailV2::InstanceIp
4427 - FW_OAM_PROTECTED_RVMI
4429 virtual_machine_interface_refs:
4430 - get_resource: FW_OAM_PROTECTED_RVMI
4431 virtual_network_refs:
4432 - get_param: oam_protected_net_fqdn
4433 subnet_uuid: { get_param: oam_protected_subnet_id }
4435 Cinder Volume Templates
4436 ^^^^^^^^^^^^^^^^^^^^^^^^
4438 ONAP supports the independent deployment of a Cinder volume via separate
4439 Heat Orchestration Templates, the Cinder Volume module. This allows the
4440 volume to persist after VNF deletion so that they can be reused on
4441 another instance (e.g., during a failover activity).
4443 A Base Module or Incremental Module may have a corresponding volume
4444 module. Use of separate volume modules is optional. A Cinder volume may
4445 be embedded within the Base Module or Incremental Module if persistence
4448 R-47788 The VNF Heat **MUST** have a 1:1 scope of a cinder volume module,
4449 when it exists, with the Base Module or Incremental Module
4451 A single volume module must create only the volumes
4452 required by a single Incremental module or Base module.
4454 The following rules apply to independent volume Heat templates:
4456 - Cinder volumes must be created in a separate Heat Orchestration
4457 Template from the Base Module or Incremental Module.
4459 - A single Cinder volume module must include all Cinder volumes
4460 needed by the Base/Incremental module.
4462 - R-79531 The VNF Heat **MUST** define “outputs” in the volume template for each Cinder volume
4463 resource universally unique identifier (UUID) (i.e. ONAP Volume
4464 Template Output Parameters).
4466 - The VNF Incremental Module or Base Module must define input
4467 parameters that match each Volume output parameter (i.e., ONAP Volume
4468 Template Output Parameters).
4470 - ONAP will supply the volume template outputs automatically to the
4471 bases/incremental template input parameters.
4473 - Volume modules may utilize nested Heat templates.
4475 *Examples: Volume Template*
4477 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4478 creates an independent Cinder volume for a VM in the module
4479 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4480 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4481 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4482 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4483 output statement and provides the value to the incremental module.
4485 Note that the example below is not a complete Heat Orchestration
4486 Template. The {vm-type} has been defined as “lb” for load balancer
4488 incremental\_volume.yaml
4490 .. code-block:: yaml
4501 type: OS::Cinder::Volume
4505 template: VNF_NAME_volume_0
4507 VNF_NAME: { get_param: vnf_name }
4508 size: {get_param: dns_volume_size_0}
4513 value: {get_resource: dns_volume_0}
4519 .. code-block:: yaml
4530 type: OS::Nova::Server
4532 name: {get_param: dns_name_0}
4537 type: OS::Cinder::VolumeAttachment
4539 instance_uuid: { get_resource: lb_0 }
4540 volume_id: { get_param: lb_volume_id_0 }
4542 ONAP Support of Environment Files
4543 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4545 The use of an environment file in OpenStack is optional. In ONAP, it is
4548 R-86285 The VNF Heat **MUST** have a
4549 corresponding environment file, even if no parameters are required to be
4552 (Note that ONAP, the open source version of ONAP, does not
4553 programmatically enforce the use of an environment file.)
4555 R-67205 The VNF Heat **MUST** have a corresponding
4556 environment file for a Base Module.
4558 R-35727 The VNF Heat **MUST** have a
4559 corresponding environment file for an Incremental module.
4561 R-22656 The VNF Heat **MUST** have a corresponding environment file for a Cinder Volume Module.
4563 A nested heat template must not have an environment file; OpenStack does
4566 The environment file must contain parameter values for the ONAP
4567 Orchestration Constants and VNF Orchestration Constants. These
4568 parameters are identical across all instances of a VNF type, and
4569 expected to change infrequently. The ONAP Orchestration Constants are
4570 associated with OS::Nova::Server image and flavor properties (See
4571 `Property: image`_ and `Property: flavor`_). Examples of VNF Orchestration Constants are the networking
4572 parameters associated with an internal network (e.g., private IP ranges)
4573 and Cinder volume sizes.
4575 The environment file must not contain parameter values for parameters
4576 that are instance specific (ONAP Orchestration Parameters, VNF
4577 Orchestration Parameters). These parameters are supplied to the Heat by
4578 ONAP at orchestration time.
4580 SDC Treatment of Environment Files
4581 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4583 Parameter values enumerated in the environment file are used by SDC as
4584 the default value. However, the SDC user may use the SDC GUI to
4585 overwrite the default values in the environment file.
4587 SDC generates a new environment file for distribution to MSO based on
4588 the uploaded environment file and the user provided GUI updates. The
4589 user uploaded environment file is discarded when the new file is
4590 created. Note that if the user did not change any values via GUI
4591 updates, the SDC generated environment file will contain the same values
4592 as the uploaded file.
4594 Use of Environment Files when using OpenStack “heat stack-create” CLI
4595 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4597 When ONAP is instantiating the Heat Orchestration Template, certain
4598 parameter must not be enumerated in the environment file. This document
4599 provides the details of what parameters should not be enumerated.
4601 If the Heat Orchestration Template is to be instantiated from the
4602 OpenStack Command Line Interface (CLI) using the command “heat
4603 stack-create”, all parameters must be enumerated in the environment
4606 Heat Template Constructs
4607 ^^^^^^^^^^^^^^^^^^^^^^^^^
4609 Nested Heat Templates
4610 ~~~~~~~~~~~~~~~~~~~~~~~
4612 ONAP supports nested Heat templates per the OpenStack specifications.
4613 Nested templates may be suitable for larger VNFs that contain many
4614 repeated instances of the same VM type(s). A common usage pattern is to
4615 create a nested template for each {vm-type} along with its supporting
4616 resources. The VNF module may then reference these component templates
4617 either statically by repeated definition or dynamically by using the
4618 resource OS::Heat::ResourceGroup.
4620 Nested Heat Template Requirements
4621 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4623 ONAP supports nested Heat Orchestration Templates. A Base Module,
4624 Incremental Module, and Cinder Volume Module may use nested heat.
4626 A Heat Orchestration Template may reference the nested heat statically
4627 by repeated definition.
4629 A Heat Orchestration Template may reference the nested heat dynamically
4630 using the resource OS::Heat::ResourceGroup.
4632 A Heat Orchestration template must have no more than three levels of
4633 nesting. ONAP supports a maximum of three levels.
4635 Nested heat templates must be referenced by file name. The use of
4636 resource\_registry in the environment file is not supported and must not
4639 R-89868 The VNF Heat **MUST** have unique file names within the scope
4640 of the VNF for a nested heat yaml file.
4642 R-52530 The VNF Heat **MUST NOT** use a directory hierarchy for nested templates. All
4643 templates must be in a single, flat directory (per VNF).
4645 A nested heat template may be used by any module within a given VNF.
4649 - Constrains must not be defined for any parameter enumerated in a
4650 nested heat template.
4652 - R-11041 The VNF Heat **MUST** have the resource calling the nested yaml file pass
4653 in as properties all parameters defined in nested yaml file.
4655 - R-61183 The VNF Heat **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
4658 - With nested templates, outputs are required to expose any resource
4659 properties of the child templates to the parent template. Those would
4660 not explicitly be declared as parameters but simply referenced as
4661 get\_attribute targets against the “parent” resource.
4663 Nested Heat Template Example: Static
4664 ++++++++++++++++++++++++++++++++++++++
4668 .. code-block:: yaml
4674 dns_image_name: { get_param: dns_image_name }
4675 dns_flavor_name: { get_param: dns_flavor_name }
4676 availability_zone: { get_param: availability_zone_0 }
4677 security_group: { get_param: DNS_shared_sec_grp_id }
4678 oam_net_id: { get_param: oam_protected_net_id }
4679 dns_oam_ip: { get_param: dns_oam_ip_0 }
4680 dns_name: { get_param: dns_name_0 }
4681 vnf_name: { get_param: vnf_name }
4682 vnf_id: { get_param: vnf_id }
4683 vf_module_id: {get_param: vf_module_id}
4688 dns_image_name: { get_param: dns_image_name }
4689 dns_flavor_name: { get_param: dns_flavor_name }
4690 availability_zone: { get_param: availability_zone_1 }
4691 security_group: { get_param: DNS_shared_sec_grp_id }
4692 oam_net_id: { get_param: oam_protected_net_id }
4693 dns_oam_ip: { get_param: dns_oam_ip_1 }
4694 dns_name: { get_param: dns_name_1 }
4695 vnf_name: { get_param: vnf_name }
4696 vnf_id: { get_param: vnf_id }
4697 vf_module_id: {get_param: vf_module_id}
4701 .. code-block:: yaml
4704 type: OS::Neutron::Port
4708 template: VNF_NAME_dns_oam_port
4710 VNF_NAME: {get_param: vnf_name}
4711 network: { get_param: oam_net_id }
4712 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4713 security_groups: [{ get_param: security_group }]
4716 type: OS::Nova::Server
4718 name: { get_param: dns_names }
4719 image: { get_param: dns_image_name }
4720 flavor: { get_param: dns_flavor_name }
4721 availability_zone: { get_param: availability_zone }
4723 - port: { get_resource: dns_oam_0_port }
4725 vnf_id: { get_param: vnf_id }
4726 vf_module_id: { get_param: vf_module_id }
4727 vnf_name {get_param: vnf_name }
4729 Use of Heat ResourceGroup
4730 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4732 The OS::Heat::ResourceGroup is a useful Heat element for creating
4733 multiple instances of a given resource or collection of resources.
4734 Typically, it is used with a nested Heat template, to create, for
4735 example, a set of identical OS::Nova::Server resources plus their
4736 related OS::Neutron::Port resources via a single resource in a master
4739 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4740 template that creates multiple instances of the same VM type.
4742 However, there are important caveats to be aware of:
4744 ResourceGroup does not deal with structured parameters
4745 (comma-delimited-list and json) as one might typically expect. In
4746 particular, when using a list-based parameter, where each list element
4747 corresponds to one instance of the ResourceGroup, it is not possible to
4748 use the intrinsic “loop variable” %index% in the ResourceGroup
4751 For instance, the following is **not** valid Heat for ResourceGroup:
4753 .. code-block:: yaml
4755 type: OS::Heat::ResourceGroup
4757 type: my_nested_vm_template.yaml
4759 name: {get_param: [vm_name_list, %index%]}
4761 Although this appears to use the nth entry of the vm\_name\_list list
4762 for the nth element of the ResourceGroup, it will in fact result in a
4763 Heat exception. When parameters are provided as a list (one for each
4764 element of a ResourceGroup), you must pass the complete parameter to the
4765 nested template along with the current index as separate parameters.
4767 Below is an example of an **acceptable** Heat Syntax for a
4770 .. code-block:: yaml
4772 type: OS::Heat::ResourceGroup
4774 type: my_nested_vm_template.yaml
4776 names: {get_param: vm_name_list}
4779 You can then reference within the nested template as:
4781 { get\_param: [names, {get\_param: index} ] }
4783 ResourceGroup Property count
4784 +++++++++++++++++++++++++++++
4786 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4787 (even if the value is one) and that the value must be enumerated in the
4788 environment file. This is required for ONAP to build the TOSCA model for
4791 .. code-block:: yaml
4793 type: OS::Heat::ResourceGroup
4795 count: { get_param: count }
4798 type: my_nested_vm_template.yaml
4800 names: {get_param: vm_name_list}
4803 Availability Zone and ResourceGroups
4804 +++++++++++++++++++++++++++++++++++++
4806 The resource OS::Heat::ResourceGroup and the property availability\_zone
4807 has been an “issue” with a few VNFs since ONAP only supports
4808 availability\_zone as a string parameter and not a
4809 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4810 to create Virtual Machines in more than one availability zone.
4812 There are numerous solutions to this issue. Below are two suggested
4815 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4816 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4817 availability\_zones by using the intrinsic function list\_join.
4819 .. code-block:: yaml
4822 type: OS::Heat::ResourceGroup
4824 count: { get_param: node_count }
4830 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4834 .. code-block:: yaml
4837 avaialability_zones:
4838 type: comma_delimited_list
4843 type: OS::Nova::Server
4845 name: { get_param: [ dns_names, get_param: index ] }
4846 image: { get_param: dns_image_name }
4847 flavor: { get_param: dns_flavor_name }
4848 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
4851 **Option 2:** Create a resource group per availability zone. A separate
4852 OS::Heat::ResourceGroup is created for each availability zone.
4855 ^^^^^^^^^^^^^^^^^^^^
4857 Heat templates *should not* reference any HTTP-based resource
4858 definitions, any HTTP-based nested configurations, or any HTTP-based
4861 - During orchestration, ONAP *should not* retrieve any such resources
4862 from external/untrusted/unknown sources.
4864 - VNF images should not contain such references in user-data or other
4865 configuration/operational scripts that are specified via Heat or
4866 encoded into the VNF image itself.
4868 *Note:* HTTP-based references are acceptable if the HTTP-based reference
4869 is accessing information with the VM private/internal network.
4871 Heat Files Support (get\_file)
4872 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4874 Heat Templates may contain the inclusion of text files into Heat
4875 templates via the Heat get\_file directive. This may be used, for
4876 example, to define a common “user-data” script, or to inject files into
4877 a VM on startup via the “personality” property.
4879 Support for Heat Files is subject to the following limitations:
4881 R-76718 The VNF Heat **MUST** reference the get\_files targets in Heat templates by file
4882 name, and the corresponding files should be delivered to ONAP along
4883 with the Heat templates.
4885 R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
4887 R-62177 The VNF Heat **MUST** have unique file names for the included
4888 files within the scope of the VNF.
4890 R-87848 The VNF Heat **MUST** have all included files in a single, flat
4891 directory per VNF. ONAP does not support a directory hierarchy.
4893 - Included files may be used by all Modules within a given VNF.
4895 - get\_file directives may be used in both non-nested and nested
4901 When Nova Servers are created via Heat templates, they may be passed a
4902 “keypair” which provides an ssh key to the ‘root’ login on the newly
4903 created VM. This is often done so that an initial root key/password does
4904 not need to be hard-coded into the image.
4906 Key pairs are unusual in OpenStack, because they are the one resource
4907 that is owned by an OpenStack User as opposed to being owned by an
4908 OpenStack Tenant. As a result, they are usable only by the User that
4909 created the keypair. This causes a problem when a Heat template attempts
4910 to reference a keypair by name, because it assumes that the keypair was
4911 previously created by a specific ONAP user ID.
4913 When a keypair is assigned to a server, the SSH public-key is
4914 provisioned on the VMs at instantiation time. They keypair itself is not
4915 referenced further by the VM (i.e. if the keypair is updated with a new
4916 public key, it would only apply to subsequent VMs created with that
4919 Due to this behavior, the recommended usage of keypairs is in a more
4920 generic manner which does not require the pre-requisite creation of a
4921 keypair. The Heat should be structured in such a way as to:
4923 - Pass a public key as a parameter value instead of a keypair name
4925 - Create a new keypair within the VNF Heat templates (in the base
4926 module) for use within that VNF
4928 By following this approach, the end result is the same as pre-creating
4929 the keypair using the public key – i.e., that public key will be
4930 provisioned in the new VM. However, this recommended approach also makes
4931 sure that a known public key is supplied (instead of having OpenStack
4932 generate a public/private pair to be saved and tracked outside of ONAP).
4933 It also removes any access/ownership issues over the created keypair.
4935 The public keys may be enumerated as a VNF Orchestration Constant in the
4936 environment file (since it is public, it is not a secret key), or passed
4937 at run-time as instance-specific parameters. ONAP will never
4938 automatically assign a public/private key pair.
4940 *Example (create keypair with an existing ssh public-key for {vm-type}
4941 of lb (for load balancer)):*
4943 .. code-block:: yaml
4953 type: OS::Nova::Keypair
4957 template: VNF_NAME_key_pair
4959 VNF_NAME: { get_param: vnf_name }
4960 public_key: {get_param: lb_ssh_public_key}
4961 save_private_key: false
4966 OpenStack allows a tenant to create Security groups and define rules
4967 within the security groups.
4969 Security groups, with their rules, may either be created in the Heat
4970 Orchestration Template or they can be pre-created in OpenStack and
4971 referenced within the Heat template via parameter(s). There can be a
4972 different approach for security groups assigned to ports on internal
4973 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
4974 there can be a common security group across all VMs for a specific
4975 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
4978 Anti-Affinity and Affinity Rules
4979 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4981 Anti-affinity or affinity rules are supported using normal OpenStack
4982 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
4983 created for each VM type to prevent them from residing on the same host,
4984 but they can be applied to multiple VM types to extend the
4985 affinity/anti-affinity across related VM types as well.
4989 In this example, the {network-role} has been defined as oam to represent
4990 an oam network and the {vm-type} have been defined as lb for load
4991 balancer and db for database.
4993 .. code-block:: yaml
4997 type: OS::Nova::ServerGroup
5002 $vnf_name: {get_param: vnf_name}
5003 template: $vnf_name-server_group1
5008 type: OS::Nova::ServerGroup
5013 $vnf_name: {get_param: vnf_name}
5014 template: $vnf_name-server_group2
5019 type: OS::Nova::Server
5023 group: {get_resource: db_server_group}
5026 type: OS::Nova::Server
5030 group: {get_resource: db_server_group}
5033 type: OS::Nova::Server
5037 group: {get_resource: lb_server_group}
5039 Resource Data Synchronization
5040 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5042 For cases where synchronization is required in the orchestration of Heat
5043 resources, two approaches are recommended:
5045 - Standard Heat depends\_on property for resources
5047 - Assures that one resource completes before the dependent resource
5050 - Definition of completeness to OpenStack may not be sufficient
5051 (e.g., a VM is considered complete by OpenStack when it is ready
5052 to be booted, not when the application is up and running).
5054 - Use of Heat Notifications
5056 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5059 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5061 - Dependent resource define depends\_on in the
5062 OS::Heat::WaitCondition resource.
5064 *Example: “depends\_on” case*
5066 In this example, the {network-role} has been defined as oam to represent
5067 an oam network and the {vm-type} has been defined as oam to represent an
5070 .. code-block:: yaml
5074 type: OS::Nova::Server
5076 name: {get_param: [oam_ names, 0]}
5077 image: {get_param: oam_image_name}
5078 flavor: {get_param: oam_flavor_name}
5079 availability_zone: {get_param: availability_zone_0}
5081 - port: {get_resource: oam01_port_0}
5082 - port: {get_resource: oam01_port_1}
5084 scheduler_hints: {group: {get_resource: oam_servergroup}}
5085 user_data_format: RAW
5088 type: OS::Neutron::Port
5090 network: {get_resource: oam_net_name}
5091 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5092 security_groups: [{get_resource: oam_security_group}]
5095 type: OS::Neutron::Port
5097 network: {get_param: oam_net_name}
5098 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5099 security_groups: [{get_resource: oam_security_group}]
5101 oam_01_vol_attachment:
5102 type: OS::Cinder::VolumeAttachment
5103 depends_on: oam_server_01
5105 volume_id: {get_param: oam_vol_1}
5106 mountpoint: /dev/vdb
5107 instance_uuid: {get_resource: oam_server_01}
5110 ^^^^^^^^^^^^^^^^^^^^
5112 VNF/VM parameters may include availability zone IDs for VNFs that
5113 require high availability.
5115 The Heat must comply with the following requirements to specific
5116 availability zone IDs:
5118 - The Heat template should spread Nova and Cinder resources across the
5119 availability zones as desired
5121 Post Orchestration & VNF Configuration
5122 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5124 Heat templates should contain a minimum amount of post-orchestration
5125 configuration data. For instance, *do not* embed complex user-data
5126 scripts in the template with large numbers of configuration parameters
5127 to the Heat template.
5129 - VNFs may provide configuration APIs for use after VNF creation. Such
5130 APIs will be invoked via application and/or SDN controllers.
5132 *Note:* It is important to follow this convention to the extent possible
5133 even in the short-term as of the long-term direction.
5135 VNFM Driver Development Steps
5136 -----------------------------------------------------------
5138 Refer to the ONAP documentation for VNF Provider instructions on integrating
5139 vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
5142 1. Use the VNF SDK tools to design the VNF with TOSCA models to output
5143 the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
5144 validated and tested.
5146 2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
5147 is a microservice providing a translation interface from VF-C to
5148 the vendor-specific VNFM. The interface definitions of vendor-specific VNFM adaptors are supplied by
5149 the VNF Providers themselves.
5151 Creating Vendor-Specific VNFM Adaptor Microservices
5152 ------------------------------------------------------------------------------------------------
5154 VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific VNFM to ONAP, a
5155 vendor-specific VNFM adaptor is added to ONAP implementing the interface of the vendor-specific VNFM.
5157 A vendor-specific VNFM adaptor is a microservice with a unique name and an appointed
5158 port. When started up, the vendor-specific VNFM adaptor microservice is automatically registered to the
5159 Microservices Bus (MSB). The following RESTful example describes the scenario of
5160 registering a vendor-specific VNFM adaptor to MSB:
5162 .. code-block:: java
5164 POST /api/microservices/v1/services
5166 "serviceName": "catalog",
5168 "url": "/api/catalog/v1",
5173 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob