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 | tosca.nodes.nfv.Cpd | tosca.nodes.Root|
143 | Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root|
144 +---------------------+------------------------------------+-----------------+
145 | VduCpd (internal | tosca.nodes.nfv.VduCpd | tosca.nodes.\ |
146 | connection point) | | nfv.Cpd |
147 +---------------------+------------------------------------+-----------------+
148 | VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root|
149 | (Virtual Link) | | |
150 +---------------------+------------------------------------+-----------------+
151 | VnfExtCpd (External | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root|
152 | Connection Point) | | |
153 +---------------------+------------------------------------+-----------------+
154 | Virtual Storage | | |
155 +---------------------+------------------------------------+-----------------+
156 | Virtual Compute | | |
157 +---------------------+------------------------------------+-----------------+
158 | Software Image | | |
159 +---------------------+------------------------------------+-----------------+
160 | Deployment Flavour | | |
161 +---------------------+------------------------------------+-----------------+
162 | Scaling Aspect | | |
163 +---------------------+------------------------------------+-----------------+
164 | Element Group | | |
165 +---------------------+------------------------------------+-----------------+
166 | Instantiation | | |
168 +---------------------+------------------------------------+-----------------+
171 +--------------------------------------------------------------------+
172 | +--------------------------------------------------------------+ |
173 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
175 | | description: VNFD TOSCA file demo | |
179 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
181 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
183 | | | **node\_types: | |
184 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
185 | | derived\_from:** tosca.nodes.nfv.VNF | |
186 | | | **requirements: | |
187 | | **- **sriov\_plane: | |
188 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
189 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
190 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
191 | +--------------------------------------------------------------+ |
192 +====================================================================+
193 +--------------------------------------------------------------------+
198 1. SR-IOV Passthrought
200 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
203 +------------------------------------------------+
212 | tosca\_name: SRIOV\_Port |
216 | virtual\_network\_interface\_requirements: |
220 | support\_mandatory: false |
222 | description: sriov |
230 | description: sriov port |
232 | layer\_protocol: ipv4 |
236 | - virtual\_binding: |
238 | capability: virtual\_binding |
244 | type: tosca.relationships.nfv.VirtualBindsTo |
248 | node: tosca.nodes.Root |
250 | type: tosca.nodes.nfv.VduCpd |
252 | substitution\_mappings: |
262 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
263 +------------------------------------------------+
267 Definitions of mem\_page\_size as one property shall be added to
268 Properties and set the value to large if one VDU node supports
269 huagepages. Here is an example.
271 +----------------------------------+
280 | tosca\_name: Huge\_pages\_demo |
284 | mem\_page\_size:large |
285 +==================================+
286 +----------------------------------+
290 Likewise, we shall add definitions of numa to
291 requested\_additional\_capabilities if we wand VUD nodes to support
292 NUMA. Here is an example.
294 +-------------------------------------------------+
295 | topology\_template: |
303 | virtual\_compute: |
309 | numa\_enabled: true |
311 | virtual\_mem\_size: 2 GB |
313 | requested\_additional\_capabilities: |
317 | support\_mandatory: true |
319 | requested\_additional\_capability\_name: numa |
321 | target\_performance\_parameters: |
323 | hw:numa\_nodes: "2" |
325 | hw:numa\_cpus.0: "0,1" |
327 | hw:numa\_mem.0: "1024" |
329 | hw:numa\_cpus.1: "2,3,4,5" |
331 | hw:numa\_mem.1: "1024" |
332 +-------------------------------------------------+
336 Definitions of Hyper-Theading are necessary as one of
337 requested\_additional\_capabilities of one VUD node if that node
338 supports Hyper-Theading. Here is an example.
340 +-------------------------------------------------------------+
341 | topology\_template: |
349 | virtual\_compute: |
355 | numa\_enabled: true |
357 | virtual\_mem\_size: 2 GB |
359 | requested\_additional\_capabilities: |
361 | hyper\_threading: |
363 | support\_mandatory: true |
365 | requested\_additional\_capability\_name: hyper\_threading |
367 | target\_performance\_parameters: |
369 | hw:cpu\_sockets : "2" |
371 | hw:cpu\_threads : "2" |
373 | hw:cpu\_cores : "2" |
375 | hw:cpu\_threads\_policy: "isolate" |
376 +-------------------------------------------------------------+
380 Definitions of ovs\_dpdk are necessary as one of
381 requested\_additional\_capabilities of one VUD node if that node
382 supports dpdk. Here is an example.
384 +------------------------------------------------------+
385 | topology\_template: |
393 | virtual\_compute: |
399 | numa\_enabled: true |
401 | virtual\_mem\_size: 2 GB |
403 | requested\_additional\_capabilities: |
407 | support\_mandatory: true |
409 | requested\_additional\_capability\_name: ovs\_dpdk |
411 | target\_performance\_parameters: |
413 | sw:ovs\_dpdk: "true" |
414 +------------------------------------------------------+
416 NFV TOSCA Type Definition
417 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
419 tosca.capabilites.nfv.VirtualCompute
420 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
422 +---------------------------+-----------------------------------------+
423 | **Shorthand Name** | VirtualCompute |
424 +===========================+=========================================+
425 | **Type Qualified Name** | tosca: VirtualCompute |
426 +---------------------------+-----------------------------------------+
427 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
428 +---------------------------+-----------------------------------------+
429 | **derived from** | tosca.nodes.Root |
430 +---------------------------+-----------------------------------------+
435 +---------------+---------+---------------+------------+----------------------+
436 | Name | Required| Type | Constraints| Description |
437 +===============+=========+===============+============+======================+
438 | request\ | No | tosca.\ | | Describes additional |
439 | _additional\ | | datatypes.\ | | capability for a |
440 | _capabilities | | nfv.Requested\| | particular VDU. |
441 | | | Additional\ | | |
442 | | | Capability | | |
443 +---------------+---------+---------------+------------+----------------------+
444 | virtual\ | yes | tosca.\ | | Describes virtual |
445 | _memory | | datatypes.\ | | memory of the |
446 | | | nfv.Virtual\ | | virtualized compute. |
448 +---------------+---------+---------------+------------+----------------------+
449 | virtual\ | yes | tosca.\ | | Describes virtual |
450 | _cpu | | datatypes.\ | | CPU(s) of the |
451 | | | nfv.Virtual\ | | virtualized compute. |
453 +---------------+---------+---------------+------------+----------------------+
455 +---------------+---------+---------------+------------+----------------------+
460 +-----------------------------------------------------------+
461 | tosca.capabilities.nfv.VirtualCompute: |
463 | derived\_from: tosca.capabilities.Root |
467 | requested\_additional\_capabilities: |
473 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
479 | type: tosca.datatypes.nfv.VirtualMemory |
485 | type: tosca.datatypes.nfv.VirtualCpu |
488 +-----------------------------------------------------------+
490 tosca.nodes.nfv.VDU.Compute
491 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
493 The NFV Virtualization Deployment Unit (VDU) compute node type
494 represents a VDU entity which it describes the deployment and
495 operational behavior of a VNF component (VNFC), as defined by **[ETSI
498 +-----------------------+-------------------------------+
499 | Shorthand Name | VDU.Compute |
500 +=======================+===============================+
501 | Type Qualified Name | tosca:VDU.Compute |
502 +-----------------------+-------------------------------+
503 | Type URI | tosca.nodes.nfv.VDU.Compute |
504 +-----------------------+-------------------------------+
505 | derived\_from | tosca.nodes.Compute |
506 +-----------------------+-------------------------------+
519 +------------+--------------------+------------+------------------------------+
520 | Name | Type | Constraints| Description |
521 +============+====================+============+==============================+
522 | virtual\ | tosca.\ | | Describes virtual compute |
523 | _compute | capabilities.nfv.\ | | resources capabilities. |
524 | | VirtualCompute | | |
525 +------------+--------------------+------------+------------------------------+
526 | monitoring\| tosca.\ | None | Monitoring parameter, which |
527 | _parameter | capabilities.nfv.\ | | can be tracked for a VNFC |
528 | | Metric | | based on this VDU |
530 | | | | Examples include: |
531 | | | | memory-consumption, |
532 | | | | CPU-utilisation, |
533 | | | | bandwidth-consumption, VNFC |
534 | | | | downtime, etc. |
535 +------------+--------------------+------------+------------------------------+
536 | Virtual\ | tosca.\ | | Defines ability of |
537 | _binding | capabilities.nfv.\ | | VirtualBindable |
538 | | VirtualBindable | | |
540 | | editor note: need | | |
541 | | to create a | | |
542 | | capability type | | |
543 +------------+--------------------+------------+------------------------------+
548 +-----------------------------------------------------------------------------+
549 | tosca.nodes.nfv.VDU.Compute: |
551 | derived\_from: tosca.nodes.Compute |
569 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
577 | nfvi\_constraints: |
587 | configurable\_properties: |
593 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
599 | private\_address: |
601 | status: deprecated |
605 | status: deprecated |
609 | status: deprecated |
613 | status: deprecated |
617 | virtual\_compute: |
619 | type: tosca.capabilities.nfv.VirtualCompute |
621 | virtual\_binding: |
623 | type: tosca.capabilities.nfv.VirtualBindable |
625 | #monitoring\_parameter: |
627 | # modeled as ad hoc (named) capabilities in VDU node template |
633 | # cpu\_load: tosca.capabilities.nfv.Metric |
635 | # memory\_usage: tosca.capabilities.nfv.Metric |
637 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile|
639 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__|
641 | valid\_source\_types: |
642 | [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
644 | occurrences: [0,UNBOUNDED] |
648 | occurrences: [0,0] |
652 | occurrences: [0,0] |
655 | #Editor note: FFS. How this capabilities should be used in NFV Profile |
657 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
661 | occurrences: [0,UNBOUND] |
665 | - virtual\_storage: |
667 | capability: tosca.capabilities.nfv.VirtualStorage |
669 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
671 | node: tosca.nodes.nfv.VDU.VirtualStorage |
673 | occurences: [ 0, UNBOUNDED ] |
675 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
677 | occurrences: [0,0] |
685 | type: tosca.artifacts.nfv.SwImage |
686 +-----------------------------------------------------------------------------+
691 +--------+---------+----------------+------------+------------------------+
692 | Name | Required| Type | Constraints| Description |
693 +========+=========+================+============+========================+
694 | SwImage| Yes | tosca.\ | | Describes the software |
695 | | | artifacts.nfv.\| | image which is directly|
696 | | | SwImage | | realizing this virtual |
698 +--------+---------+----------------+------------+------------------------+
706 ~~~~~~~~~~~~~~~~~~~~~
708 The TOSCA Cpd node represents network connectivity to a compute resource
709 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
710 used as parent for the various Cpd types.
712 +-----------------------+-----------------------+
713 | Shorthand Name | Cpd |
714 +=======================+=======================+
715 | Type Qualified Name | tosca:Cpd |
716 +-----------------------+-----------------------+
717 | Type URI | tosca.nodes.nfv.Cpd |
718 +-----------------------+-----------------------+
724 +--------+------------+--------+---------------+---------------+
725 | Name | Required | Type | Constraints | Description |
726 +========+============+========+===============+===============+
727 +--------+------------+--------+---------------+---------------+
742 +----------------------------------------------------------------------+
743 | tosca.nodes.nfv.Cpd: |
745 | derived\_from: tosca.nodes.Root |
755 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
759 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
765 | - valid\_values: [ root, leaf ] |
781 | type: tosca.datatype.nfv.AddressData |
784 +----------------------------------------------------------------------+
786 Additional Requirement
787 +++++++++++++++++++++++
791 tosca.nodes.nfv.VduCpd
792 ~~~~~~~~~~~~~~~~~~~~~~~
794 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
795 network connectivity between a VNFC instance (based on this VDU) and an
796 internal VL as defined by [ETSI GS NFV-IFA 011].
798 +-----------------------+--------------------------+
799 | Shorthand Name | VduCpd |
800 +=======================+==========================+
801 | Type Qualified Name | tosca: VduCpd |
802 +-----------------------+--------------------------+
803 | Type URI | tosca.nodes.nfv.VduCpd |
804 +-----------------------+--------------------------+
810 +-----------------+---------+---------------+------------+--------------------+
811 | Name | Required| Type | Constraints| Description |
812 +=================+=========+===============+============+====================+
813 | bitrate\ | no | integer | | Bitrate requirement|
814 | _requirement | | | | on this connection |
816 +-----------------+---------+---------------+------------+--------------------+
817 | virtual\ | | Virtual\ | | Specifies |
818 | _network\ | no | Network\ | | requirements on a |
819 | _interface_\ | | Interface\ | | virtual network |
820 | requirements | | Requirements\ | | realising the CPs |
821 | | | | | instantiated from |
823 +-----------------+---------+---------------+------------+--------------------+
833 +----------+---------+--------------------+------------+----------------------+
834 | Name | Required| Type | Constraints| Description |
835 +==========+=========+====================+============+======================+
836 | virtual\ | yes | tosca.\ | | Describe the |
837 | _binding | | capabilities.nfv.\ | | requirement for |
838 | | | VirtualBindable\ | | binding with VDU |
839 +----------+---------+--------------------+------------+----------------------+
840 | virtual\ | no | tosca.\ | | Describes the |
841 | _link | | capabilities.nfv.\ | | requirements for |
842 | | | VirtualLinkable | | linking to virtual |
844 +----------+---------+--------------------+------------+----------------------+
849 +----------------------------------------------------------------+
850 | tosca.nodes.nfv.VduCpd: |
852 | derived\_from: tosca.nodes.nfv.Cpd |
856 | bitrate\_requirement: |
862 | virtual\_network\_interface\_requirements |
868 | type: VirtualNetworkInterfaceRequirements |
876 | capability: tosca.capabilities.nfv.VirtualLinkable |
878 | relationship: tosca.relationships.nfv.VirtualLinksTo |
880 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
882 | capability: tosca.capabilities.nfv.VirtualBindable |
884 | relationship: tosca.relationships.nfv.VirtualBindsTo |
886 | node: tosca.nodes.nfv.VDU |
887 +----------------------------------------------------------------+
889 tosca.nodes.nfv.VDU.VirtualStorage
890 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
892 The NFV VirtualStorage node type represents a virtual storage entity
893 which it describes the deployment and operational behavior of a virtual
894 storage resources, as defined by **[ETSI NFV IFA011].**
896 **[editor note]** open issue: should NFV profile use the current storage
897 model as described in YAML 1.1. Pending on Shitao proposal (see
898 NFVIFA(17)000110 discussion paper)
900 **[editor note]** new relationship type as suggested in Matt
901 presentation. Slide 8. With specific rules of “valid\_target\_type”
903 +---------------------------+--------------------------------------+
904 | **Shorthand Name** | VirtualStorage |
905 +===========================+======================================+
906 | **Type Qualified Name** | tosca: VirtualStorage |
907 +---------------------------+--------------------------------------+
908 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
909 +---------------------------+--------------------------------------+
910 | **derived\_from** | tosca.nodes.Root |
911 +---------------------------+--------------------------------------+
913 tosca.artifacts.nfv.SwImage
914 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
916 +---------------------------+------------------------------------+
917 | **Shorthand Name** | SwImage |
918 +===========================+====================================+
919 | **Type Qualified Name** | tosca:SwImage |
920 +---------------------------+------------------------------------+
921 | **Type URI** | tosca.artifacts.nfv.SwImage |
922 +---------------------------+------------------------------------+
923 | **derived\_from** | tosca.artifacts.Deployment.Image |
924 +---------------------------+------------------------------------+
929 +-----------------+---------+----------+------------+-------------------------+
930 | Name | Required| Type | Constraints| Description |
931 +=================+=========+==========+============+=========================+
932 | name | yes | string | | Name of this software |
934 +-----------------+---------+----------+------------+-------------------------+
935 | version | yes | string | | Version of this software|
937 +-----------------+---------+----------+------------+-------------------------+
938 | checksum | yes | string | | Checksum of the software|
939 | | | | | image file |
940 +-----------------+---------+----------+------------+-------------------------+
941 | container\ | yes | string | | The container format |
942 | _format | | | | describes the container |
943 | | | | | file format in which |
944 | | | | | software image is |
945 | | | | | provided. |
946 +-----------------+---------+----------+------------+-------------------------+
947 | disk\_format | yes | string | | The disk format of a |
948 | | | | | software image is the |
949 | | | | | format of the underlying|
950 | | | | | disk image |
951 +-----------------+---------+----------+------------+-------------------------+
952 | min\_disk | yes | scalar-\ | | The minimal disk size |
953 | | | unit.size| | requirement for this |
954 | | | | | software image. |
955 +-----------------+---------+----------+------------+-------------------------+
956 | min\_ram | no | scalar-\ | | The minimal RAM |
957 | | | unit.size| | requirement for this |
958 | | | | | software image. |
959 +-----------------+---------+----------+------------+-------------------------+
960 | Size | yes | scalar-\ | | The size of this |
961 | | | unit.size| | software image |
962 +-----------------+---------+----------+------------+-------------------------+
963 | sw\_image | yes | string | | A reference to the |
964 | | | | | actual software image |
965 | | | | | within VNF Package, or |
967 +-----------------+---------+----------+------------+-------------------------+
968 | operating\ | no | string | | Identifies the operating|
969 | _system | | | | system used in the |
970 | | | | | software image. |
971 +-----------------+---------+----------+------------+-------------------------+
972 | supported\ | no | list | | Identifies the |
973 | _virtualization\| | | | virtualization |
974 | _enviroment | | | | environments (e.g. |
975 | | | | | hypervisor) compatible |
976 | | | | | with this software image|
977 +-----------------+---------+----------+------------+-------------------------+
982 +-----------------------------------------------------+
983 | tosca.artifacts.nfv.SwImage: |
985 | derived\_from: tosca.artifacts.Deployment.Image |
987 | properties or metadata: |
1011 | container\_format: |
1025 | type: scalar-unit.size # Number |
1031 | type: scalar-unit.size # Number |
1037 | type: scalar-unit.size # Number |
1047 | operating\_system: |
1053 | supported\_virtualisation\_environments: |
1062 +-----------------------------------------------------+
1067 openovnf\_\_vOpenNAT.yaml
1068 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1070 +-------------------------------------------------------------+
1073 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1075 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1077 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1079 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1081 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1083 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1085 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1087 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1089 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1091 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1093 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1095 | - openonfv\_\_tosca.capabilities.Container.yaml |
1097 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1099 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1101 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1103 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1105 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1107 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1109 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1113 | vnfProductName: openNAT |
1115 | vnfdVersion: 1.0.0 |
1117 | vnfProvider: intel |
1121 | csarVersion: 1.0.0 |
1123 | vnfdId: openNAT-1.0 |
1125 | csarProvider: intel |
1127 | vnfProductInfoDescription: openNAT |
1135 | localizationLanguage: '[english, chinese]' |
1139 | defaultLocalizationLanguage: english |
1141 | vnfProductInfoName: openNAT |
1143 | vnfSoftwareVersion: 1.0.0 |
1145 | topology\_template: |
1147 | node\_templates: |
1155 | file: /swimages/xenial-snat.qcow2 |
1157 | type: tosca.artifacts.nfv.SwImage |
1161 | name: vNatVNFImage |
1165 | checksum: "5000" |
1167 | container\_format: bare |
1169 | disk\_format: qcow2 |
1171 | min\_disk: 10 GB |
1177 | sw\_image: /swimages/xenial-snat.qcow2 |
1179 | operating\_system: unbantu |
1183 | tosca\_name: vdu\_vNat |
1187 | virtual\_compute: |
1191 | virtual\_memory: |
1193 | numa\_enabled: true |
1195 | virtual\_mem\_size: 2 GB |
1197 | requested\_additional\_capabilities: |
1201 | support\_mandatory: true |
1203 | requested\_additional\_capability\_name: numa |
1205 | target\_performance\_parameters: |
1207 | hw:numa\_nodes: "2" |
1209 | hw:numa\_cpus.0: "0,1" |
1211 | hw:numa\_mem.0: "1024" |
1213 | hw:numa\_cpus.1: "2,3,4,5" |
1215 | hw:numa\_mem.1: "1024" |
1217 | hyper\_threading: |
1219 | support\_mandatory: true |
1221 | requested\_additional\_capability\_name: hyper\_threading |
1223 | target\_performance\_parameters: |
1225 | hw:cpu\_sockets : "2" |
1227 | hw:cpu\_threads : "2" |
1229 | hw:cpu\_cores : "2" |
1231 | hw:cpu\_threads\_policy: "isolate" |
1235 | support\_mandatory: true |
1237 | requested\_additional\_capability\_name: ovs\_dpdk |
1239 | target\_performance\_parameters: |
1241 | sw:ovs\_dpdk: "true" |
1245 | cpu\_architecture: X86 |
1247 | num\_virtual\_cpu: 2 |
1251 | configurable\_properties: |
1255 | additional\_vnfc\_configurable\_properties: |
1261 | descrption: the virtual machine of vNat |
1269 | - virtual\_storage: |
1271 | capability: virtual\_storage |
1273 | node: vNAT\_Storage |
1279 | location: /mnt/volume\_0 |
1281 | type: tosca.relationships.nfv.VDU.AttachedTo |
1283 | - local\_storage: |
1285 | node: tosca.nodes.Root |
1287 | type: tosca.nodes.nfv.VDU.Compute |
1293 | tosca\_name: SRIOV\_Port |
1297 | virtual\_network\_interface\_requirements: |
1301 | support\_mandatory: false |
1303 | description: sriov |
1311 | description: sriov port |
1313 | layer\_protocol: ipv4 |
1317 | - virtual\_binding: |
1319 | capability: virtual\_binding |
1325 | type: tosca.relationships.nfv.VirtualBindsTo |
1327 | - virtual\_link: |
1329 | node: tosca.nodes.Root |
1331 | type: tosca.nodes.nfv.VduCpd |
1337 | tosca\_name: vNAT\_Storage |
1341 | id: vNAT\_Storage |
1343 | size\_of\_storage: 10 GB |
1345 | rdma\_enabled: false |
1347 | type\_of\_storage: volume |
1349 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1351 | substitution\_mappings: |
1361 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1363 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1364 +-------------------------------------------------------------+
1366 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1367 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1369 +------------------------------------------------------------+
1372 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1376 | tosca.nodes.nfv.VDU.VirtualStorage: |
1380 | virtual\_storage: |
1382 | type: tosca.capabilities.nfv.VirtualStorage |
1384 | derived\_from: tosca.nodes.Root |
1392 | size\_of\_storage: |
1402 | type\_of\_storage: |
1406 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1407 +------------------------------------------------------------+
1409 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1410 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1412 +-----------------------------------------------------------------+
1415 | tosca.datatypes.nfv.L3AddressData: |
1419 | number\_of\_ip\_address: |
1425 | ip\_address\_assignment: |
1429 | ip\_address\_type: |
1433 | - valid\_values: |
1443 | floating\_ip\_activated: |
1447 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1457 | support\_mandatory: |
1475 | tosca.datatype.nfv.AddressData: |
1483 | - valid\_values: |
1491 | l2\_address\_data: |
1495 | type: tosca.datatypes.nfv.L2AddressData |
1497 | l3\_address\_data: |
1501 | type: tosca.datatypes.nfv.L3AddressData |
1503 | tosca.datatypes.nfv.L2AddressData: {} |
1507 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1509 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1513 | tosca.nodes.nfv.VduCpd: |
1515 | derived\_from: tosca.nodes.Root |
1519 | virtual\_network\_interface\_requirements: |
1523 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1533 | - valid\_values: |
1543 | bitrate\_requirement: |
1555 | layer\_protocol: |
1559 | - valid\_values: |
1579 | type: tosca.datatype.nfv.AddressData |
1587 | - virtual\_binding: |
1589 | capability: tosca.capabilities.nfv.VirtualBindable |
1597 | - virtual\_link: |
1599 | capability: tosca.capabilities.nfv.VirtualBindable |
1607 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1608 +-----------------------------------------------------------------+
1610 .. |image1| image:: Image1.png
1613 .. |image2| image:: Image2.png
1627 Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
1628 Markup Language) is a human friendly data serialization standard for all
1629 programming languages. See http://www.yaml.org/.
1631 Heat Orchestration Template Format
1632 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1634 Heat Orchestration templates must be defined in YAML.
1638 - Tabs are NOT allowed, use spaces ONLY.
1640 - R-43125 The VNF Heat **MUST** indent properties and lists with 1 or
1643 - All Resource IDs and resource property parameters are case-sensitive.
1644 (e.g., "ThIs", is not the same as "thiS")
1646 Heat Orchestration Template Structure
1647 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1649 Heat Orchestration template structure follows the following format, as
1650 defined by OpenStack at
1651 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html.
1653 .. code-block:: yaml
1655 heat_template_version: <date>
1658 # a description of the template
1661 # a declaration of input parameter groups and order
1664 # declaration of input parameters
1667 # declaration of template resources
1670 # declaration of output parameters
1673 # declaration of conditions
1676 R-67888 The VNF Heat **MUST** contain the following
1679 - heat\_template\_version:
1687 Heat Orchestration templates for ONAP may contain the following
1690 - parameter\_groups:
1694 heat\_template\_version
1695 ++++++++++++++++++++++++
1697 This section is ONAP mandatory. The heat\_template\_version must be set
1698 to a date that is supported by the OpenStack environment.
1703 R-39402 The VNF Heat **MUST** contain the description section.
1708 This ONAP optional section allows for specifying how the input
1709 parameters should be grouped and the order to provide the parameters in.
1714 R-35414 The VNF Heat **MUST** contain the parameter section.
1716 This section allows for
1717 specifying input parameters that must be provided when instantiating
1718 the template. Each parameter is specified in a separated nested block
1719 with the name of the parameters defined in the first line and additional
1720 attributes (e.g., type, label) defined as nested elements.
1722 R-90279 The VNF Heat **MUST** use in a resource all parameters declared in
1723 a template except for the parameters for the OS::Nova::Server property
1724 availability\_zone. See `Property: availability\_zone`_. for more details on
1727 .. code-block:: yaml
1731 type: <string | number | json | comma_delimited_list | boolean>
1732 label: <human-readable name of the parameter>
1733 description: <description of the parameter>
1734 default: <default value for parameter>
1735 hidden: <true | false>
1737 <parameter constraints>
1738 immutable: <true | false>
1742 - The name of the parameter.
1744 - ONAP requires that the param name must contain only alphanumeric
1745 characters and “\_” underscores. Special characters must not be
1750 - The type of the parameter. Supported types are string, number,
1751 comma\_delimited\_list, json and boolean.
1753 - R-28657 The VNF Heat **MUST** provide the attribute 'type' on
1754 parameters per the OpenStack Heat Orchestration Template standard.
1758 - A human readable name for the parameter.
1760 - This attribute is optional.
1764 - A human readable description for the parameter.
1766 - R-44001 The VNF Heat **MUST** provide the attribute 'description'
1767 on parameters. (Note that this attribute is OpenStack optional.)
1771 - A default value for the parameter.
1773 - R-90526 The VNF Heat **MUST NOT** use the attribute 'default'.
1774 If a parameter has a default value, it must be provided in
1775 the environment file. (Note that this attribute is OpenStack
1780 - Defines whether the parameters should be hidden when a user
1781 requests information about a stack created from the template. This
1782 attribute can be used to hide passwords specified as parameters.
1784 - This attribute is optional and defaults to false.
1788 - A list of constraints to apply. The constraints block of a
1789 parameter definition defines additional validation constraints
1790 that apply to the value of the parameter. The parameter values
1791 provided in the Heat Orchestration Template are validated against
1792 the constraints at instantiation time. The constraints are defined
1793 as a list with the following syntax
1797 - <constraint type>: <constraint definition>
1799 description: <constraint description>
1801 - constraint type: Type of constraint to apply.
1803 - constraint definition: The actual constraint, depending on the
1806 - description: A description of the constraint. The text is presented
1807 to the user when the value the user defines violates the constraint.
1808 If omitted, a default validation message is presented to the user.
1809 This attribute is optional.
1811 - R-88863 The VNF Heat **MUST** have a constraint of range or
1812 allowed\_values for a parameter type 'number'.
1814 - range: The range constraint applies to parameters of type number.
1815 It defines a lower and upper limit for the numeric value of the
1816 parameter. The syntax of the range constraint is
1818 range: { min: <lower limit>, max: <upper limit> }
1820 It is possible to define a range constraint with only a lower limit
1823 - allowed\_values: The allowed\_values constraint applies to parameters
1824 of type string or number. It specifies a set of possible values for a
1825 parameter. At deployment time, the user-provided value for the
1826 respective parameter must match one of the elements of the list. The
1827 syntax of the allowed\_values constraint is
1829 allowed\_values: [ <value>, <value>, ... ]
1831 Alternatively, the following YAML list notation can be used
1841 - Other <constraint type> are optional, they may be used (e.g., length,
1842 modulo, allowed\_pattern, custom\_constraint, allowed\_values (for
1845 - Note that constrains must not be defined for any parameter enumerated
1846 in a nested heat template.
1848 - Some ONAP parameters must never have constraints defined. See
1849 `ONAP Resource ID and Parameter Naming Convention`_ for the
1850 use cases where these exceptions exist.
1854 - Defines whether the parameter is updatable. Stack update fails, if
1855 this is set to true and the parameter value is changed.
1857 - This attribute is optional and defaults to false.
1862 R-23664 The VNF Heat **MUST** have a resources: section with the
1863 declaration of at least one resource.
1866 contains the declaration of the single resources of the template. This
1867 section with at least one resource must be defined in the Heat
1868 Orchestration Template, or the template would not create any resources
1869 when being instantiated.
1871 Each resource is defined as a separate block in the resources section
1872 with the following syntax.
1874 .. code-block:: yaml
1878 type: <resource type>
1880 <property name>: <property value>
1882 <resource specific metadata>
1883 depends\_on: <resource ID or list of ID>
1884 update\_policy: <update policy>
1885 deletion\_policy: <deletion policy>
1886 external\_id: <external resource ID>
1887 condition: <condition name or expression or boolean>
1891 - A resource ID that must be unique within the resources section of
1892 the Heat Orchestration Template.
1894 - R-16447 The VNF Heat **MUST** have unique resource IDs across all Heat
1895 Orchestration Templates that compose the VNF. This requirement
1896 also applies when a VNF is composed of more than one Heat
1897 Orchestration Template (see ONAP VNF Modularity Overview).
1899 - The naming convention for a resource ID is provided in `Resource IDs`_.
1903 - The resource type, such as OS::Nova::Server or OS::Neutron::Port.
1904 Note that the type may specify a nested heat file. This attribute
1909 - A list of resource-specific properties. The property value can be
1910 provided in place, or via a function (e.g., Intrinsic functions).
1911 This section is optional.
1913 - The naming convention for property parameters is provided in
1914 `ONAP Resource ID and Parameter Naming Convention`_.
1918 - Resource-specific metadata. This section is optional, except for
1919 the resource OS::Nova::Server. See `Resource: OS::Nova::Server - Parameters`_.
1921 - R-97199 The VNF Heat **MUST** use the metadata property for
1922 OS::Nova::Server resource type.
1926 - Dependencies of the resource on one or more resources of the
1927 template. This attribute is optional. See
1928 `Resource Data Synchronization`_ for additional details.
1932 - Update policy for the resource, in the form of a nested
1933 dictionary. Whether update policies are supported and what the
1934 exact semantics are depends on the type of the current resource.
1935 This attribute is optional.
1939 - Deletion policy for the resource. The allowed deletion policies
1940 are Delete, Retain, and Snapshot. Beginning with
1941 heat\_template\_version 2016-10-14, the lowercase equivalents
1942 delete, retain, and snapshot are also allowed. This attribute is
1943 optional; the default policy is to delete the physical resource
1944 when deleting a resource from the stack.
1948 - Allows for specifying the resource\_id for an existing external
1949 (to the stack) resource. External resources cannot depend on other
1950 resources, but we allow other resources to depend on external
1951 resource. This attribute is optional. Note: when this is
1952 specified, properties will not be used for building the resource
1953 and the resource is not managed by Heat. This is not possible to
1954 update that attribute. Also, resource won’t be deleted by heat
1955 when stack is deleted.
1959 - Condition for the resource. The condition decides whether to
1960 create the resource or not. This attribute is optional.
1965 This ONAP optional section allows for specifying output parameters
1966 available to users once the template has been instantiated. If the
1967 section is specified, it will need to adhere to specific requirements.
1968 See `ONAP Parameter Classifications Overview`_ and
1969 `ONAP Output Parameter Names`_ for additional details.
1971 Environment File Format
1972 ^^^^^^^^^^^^^^^^^^^^^^^^
1974 The environment file is a yaml text file.
1975 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1977 The environment file can contain the following sections:
1979 - parameters: A list of key/value pairs.
1981 - resource\_registry: Definition of custom resources.
1983 - parameter\_defaults: Default parameters passed to all template
1986 - encrypted\_parameters: List of encrypted parameters.
1988 - event\_sinks: List of endpoints that would receive stack events.
1990 - parameter\_merge\_strategies: Merge strategies for merging parameters
1991 and parameter defaults from the environment file.
1993 R-03324 The VNF Heat **MUST** contain the following sections in the
1998 Environment files for ONAP may contain the following sections:
2000 - resource\_registry:
2002 - parameter\_defaults:
2004 - encrypted\_parameters:
2008 - parameter\_merge\_strategies:
2010 The use of an environment file in OpenStack is optional. In ONAP, it is
2011 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
2012 corresponding environment file, even if no parameters are enumerated in
2013 the mandatory parameter section.
2015 (Note that ONAP, the open source version of ONAP, does not
2016 programmatically enforce the use of an environment file.)
2018 SDC Treatment of Environment Files
2019 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2021 Parameter values enumerated in the environment file are used by SDC as
2022 the default value. However, the SDC user may use the SDC GUI to
2023 overwrite the default values in the environment file.
2025 SDC generates a new environment file for distribution to MSO based on
2026 the uploaded environment file and the user provided GUI updates. The
2027 user uploaded environment file is discarded when the new file is
2030 ONAP has requirements for what parameters must be enumerated in the
2031 environment file and what parameter must not be enumerated in the
2032 environment file. See `ONAP Parameter Classifications Overview`_ and
2033 `ONAP Resource ID and Parameter Naming Convention`_ for more details.
2035 Nested Heat Orchestration Templates Overview
2036 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2038 ONAP supports nested Heat Orchestration Templates per OpenStack
2041 A Base Module may utilize nested templates.
2043 An Incremental Module may utilize nested templates.
2045 A Cinder Volume Module may utilize nested templates.
2047 A nested template must not define parameter constraints in the parameter
2050 Nested templates may be suitable for larger VNFs that contain many
2051 repeated instances of the same VM type(s). A common usage pattern is to
2052 create a nested template for each VM type along with its supporting
2053 resources. The Heat Orchestration Template may then reference these
2054 nested templates either statically (by repeated definition) or
2055 dynamically (via OS::Heat::ResourceGroup).
2057 See `Nested Heat Templates`_ for additional details.
2059 ONAP Heat Orchestration Template Filenames
2060 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2062 In order to enable ONAP to understand the relationship between Heat
2063 files, the following Heat file naming convention must be utilized.
2065 In the examples below, <text> represents any alphanumeric string that
2066 must not contain any special characters and must not contain the word
2072 R-19473 The VNF Heat **MUST** include “base” in the filename for the
2075 R-81339 The VNF Heat **MUST** match one of the following options for
2076 the base module file name:
2078 - base\_<text>.y[a]ml
2080 - <text>\_base.y[a]ml
2084 - <text>\_base\_<text>.y[a]ml
2086 R-91342 The VNF Heat **MUST** name the base module’s corresponding
2087 environment file to be identical to the base module with “.y[a]ml”
2088 replaced with “.env”.
2091 ~~~~~~~~~~~~~~~~~~~~~
2093 There is no explicit naming convention for the incremental modules.
2094 As noted above, <text> represents any alphanumeric string.
2096 R-87247 The VNF Heat **MUST NOT** use any special characters or the
2097 word “base” in the name of the incremental module.
2101 R-94509 The VNF Heat **MUST** name the incremental module’s
2102 corresponding environment file to be identical to the incremental
2103 module with “.y[a]ml” replaced with “.env”.
2105 To clearly identify the incremental module, it is recommended to use the
2106 following naming options for modules:
2108 - module\_<text>.y[a]ml
2110 - <text>\_module.y[a]ml
2114 Cinder Volume Modules
2115 ~~~~~~~~~~~~~~~~~~~~~~~
2117 R-82732 The VNF Heat **MUST** name the Cinder volume module file name
2118 to be the same as the corresponding module it is supporting (base
2119 module or incremental module) with “\_volume” appended.
2121 - <base module name>\_volume.y[a]ml
2123 - <incremental module name>\_volume.y[a]ml
2125 R-31141 The VNF Heat **MUST** name the volume module’s corresponding
2126 environment file to be identical to the volume module with “.y[a]ml”
2127 replaced with “.env”.
2132 There is no explicit naming convention for nested Heat files with the
2133 following exceptions; the name should contain “nest”.
2135 R-76057 The VNF Heat **MUST NOT** use special characters
2136 or the word “base” in the file name for the nested template.
2138 As noted above, <text> represents any alphanumeric string.
2142 Nested Heat files do not have corresponding environment files, per
2143 OpenStack specifications.
2145 R-18224 The VNF Heat **MUST** pass in as properties all parameter values
2146 associated with the nested heat file in the resource definition defined
2147 in the parent heat template.
2149 ONAP Parameter Classifications Overview
2150 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2152 In order for ONAP to support workflow automation, Heat Orchestration
2153 Template resource property parameters must adhere to specific naming
2154 conventions and requirements.
2156 Broadly, ONAP categorizes parameters into four categories:
2158 1. ONAP metadata parameters
2160 2. Instance specific parameters
2162 3. Constant parameters
2164 4. Output parameters.
2166 ONAP Metadata Parameters
2167 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2169 There are both mandatory and optional ONAP metadata parameters
2170 associated with the resource OS::Nova::Server.
2172 - ONAP metadata parameters must not have parameter constraints defined.
2174 - Both mandatory and optional (if specified) ONAP metadata parameter
2175 names must follow the ONAP metadata parameter naming convention.
2177 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on
2178 the metadata parameters.
2180 Instance specific parameters
2181 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2183 The instance specific parameters are VNF instance specific. The value of
2184 the parameter will be different for every instance of a VNF (e.g., IP
2185 address). The instance specific parameters are subdivided into two
2186 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2189 ONAP Orchestration Parameters
2190 +++++++++++++++++++++++++++++++
2192 ONAP Orchestration Parameters are per instance parameters where the
2193 value is assigned via ONAP automation. (Note that in some cases,
2194 automation is currently not available and the value is loaded into ONAP
2195 prior to instantiation.)
2197 - ONAP orchestration parameters must not be enumerated in the
2200 - When the ONAP orchestration parameter type is set to number, the
2201 parameter must have constraints for range and/or allowed\_values.
2203 - Parameter constraints for ONAP orchestration parameters are optional
2204 for all parameter types other than number. If constraints are
2205 specified, they must adhere to the OpenStack specifications.
2207 - The ONAP orchestration parameter names must follow the ONAP
2208 orchestration parameter naming convention.
2209 `ONAP Resource ID and Parameter Naming Convention`_
2210 provides additional details.
2212 VNF Orchestration Parameters
2213 +++++++++++++++++++++++++++++
2215 VNF Orchestration Parameters are per instance parameters where the
2216 values are assigned manually. They are not supported by ONAP automation.
2217 The per instance values are loaded into ONAP prior to VNF instantiation.
2219 - VNF orchestration parameters must not be enumerated in the
2222 - When the VNF orchestration parameter type is set to number, the
2223 parameter must have constraints for range or allowed\_values.
2225 - Parameter constraints for VNF orchestration parameters are optional
2226 for all parameter types other than number. If constraints are
2227 specified, they must adhere to the OpenStack specifications.
2229 - The VNF orchestration parameter names should follow the VNF
2230 orchestration parameter naming convention.
2231 `ONAP Resource ID and Parameter Naming Convention`_
2232 provides additional details.
2235 ~~~~~~~~~~~~~~~~~~~~~
2237 The constant parameters are parameters that remain constant across many
2238 VNF instances (e.g., image, flavor). The constant parameters are
2239 subdivided into two categories: **ONAP Constant Parameters** and
2240 **VNF Constant Parameters.**
2242 ONAP Constant Parameters
2243 ++++++++++++++++++++++++++
2245 - ONAP Constant Parameters must be enumerated in the environment file.
2246 These parameter values are not assigned by ONAP.
2248 - When the ONAP Constant Parameter type is set to number, the parameter
2249 must have constraints for range and/or allowed\_values.
2251 - Parameter constraints for ONAP constant parameters are optional for
2252 all parameter types other than number. If constraints are specified,
2253 they must adhere to the OpenStack specifications.
2255 - The ONAP Constant Parameter names must follow the ONAP orchestration
2256 parameter naming convention.
2257 `ONAP Resource ID and Parameter Naming Convention`_
2258 provides additional details.
2260 VNF Constant Parameters
2261 ++++++++++++++++++++++++
2263 - VNF Constant Parameters must be enumerated in the environment file.
2264 These parameter values are not assigned by ONAP.
2266 - When the VNF Constant Parameters type is set to number, the parameter
2267 must have constraints for range and/or allowed\_values.
2269 - Parameter constraints for ONAP constant parameters are optional for
2270 all parameter types other than number. If constraints are specified,
2271 they must adhere to the OpenStack specifications.
2273 - The VNF Constant Parameters names should follow the ONAP
2274 orchestration parameter naming convention.
2275 `ONAP Resource ID and Parameter Naming Convention`_
2276 provides additional details.
2281 The output parameters are parameters defined in the output section of a
2282 Heat Orchestration Template. The ONAP output parameters are subdivided
2283 into three categories:
2285 1. ONAP Base Module Output Parameters
2287 2. ONAP Volume Module Output Parameters
2289 3. ONAP Predefined Output Parameters.
2291 ONAP Base Module Output Parameters
2292 ++++++++++++++++++++++++++++++++++++
2294 ONAP Base Module Output Parameters are declared in the outputs: section
2295 of the base module Heat Orchestration Template. A Base Module Output
2296 Parameter is available as an input parameter (i.e., declared in the
2297 “parameters:” section) to all incremental modules in the VNF.
2299 - A Base Module Output Parameter may be used as an input parameter in
2300 an incremental module.
2302 - The Output parameter name and type must match the input parameter
2303 name and type unless the Output parameter is of the type
2304 comma\_delimited\_list.
2306 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2307 a collection of UUIDs from a Resource Group), then the
2308 corresponding input parameter must be declared as type json and
2309 not a comma\_delimited\_list, which is actually a string value
2310 with embedded commas.
2312 - When a Base Module Output Parameter is declared as an input parameter
2313 in an incremental module Heat Orchestration Template, parameter
2314 constraints must not be declared.
2316 Additional details on ONAP Base Module Output Parameters are provided in
2317 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2319 ONAP Volume Module Output Parameters
2320 ++++++++++++++++++++++++++++++++++++++
2322 The volume template output parameters are only available for the module
2323 (base or add on) that the volume is associated with.
2325 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2326 section of the Cinder volume module Heat Orchestration Template
2328 - An ONAP Volume Module Output Parameter is available as an input
2329 parameter (i.e., declared in the parameters: section) only for the
2330 module (base or incremental) that the Cinder volume module is
2333 - R-07443 The VNF Heat **MUST** match the Output parameter name and type with
2334 the input parameter name and type unless the Output parameter is of the
2335 type comma\_delimited\_list.
2337 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2338 collection of UUIDs from a Resource Group), then the corresponding
2339 input parameter must be declared as type json and not a
2340 comma\_delimited\_list, which is actually a string value with
2343 - When an ONAP Volume Module Output Parameter is declared as an input
2344 parameter in a base module or incremental module, parameter
2345 constraints must not be declared.
2347 Additional details on ONAP Base Module Output Parameters are provided in
2348 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2350 ONAP Predefined Output Parameters
2351 +++++++++++++++++++++++++++++++++++
2353 ONAP will look for a small set of pre-defined Heat output parameters to
2354 capture resource attributes for inventory in ONAP. These output
2355 parameters are optional and are specified in `OAM Management IP Addresses`_.
2357 Support of heat stack update
2358 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2360 VNF Heat Orchestration Templates must not be designed to utilize the
2361 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2362 does not support the use of heat stack-update command for scaling.
2364 It is important to note that ONAP only supports heat stack-update for
2370 ONAP defines two types of networks: External Networks and Internal
2373 ONAP defines an external network in relation to the VNF and not with
2374 regard to the Network Cloud site. External networks may also be referred
2375 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2377 - VMs in another VNF or
2379 - an external gateway or router
2381 ONAP defines an internal network in relation to the VNF and not with
2382 regard to the Network Cloud site. Internal networks may also be referred
2383 to as “intra-VNF” networks or “private” networks. An internal network
2384 only connects VMs in a single VNF. It must not connect to other VNFs or
2385 an external gateway or router.
2390 VNF Heat Orchestration Templates must not include any resources for
2391 external networks connected to the VNF. External networks must be
2392 orchestrated separately, as independent, stand-alone VNF Heat
2393 Orchestration Templates, so they can be shared by multiple VNFs and
2394 managed independently.
2396 When the external network is created, it must be assigned a unique
2397 {network-role}. The {network-role} should describe the network (e.g.,
2398 oam). The {network-role} while unique to the LCP, can repeat across
2401 An External Network may be a Neutron Network or a Contrail Network
2403 R-23983 The VNF **MUST** pass the external networks into the VNF Heat
2404 Orchestration Templates as parameters.
2406 - Neutron Network-id (UUID)
2408 - Neutron Network subnet ID (UUID)
2410 - Contrail Network Fully Qualified Domain Name (FQDN)
2412 ONAP enforces a naming convention for parameters associated with
2413 external networks. `ONAP Resource ID and Parameter Naming Convention`_
2414 provides additional details.
2416 Parameter values associated with an external network will be generated
2417 and/or assigned by ONAP at orchestration time. Parameter values
2418 associated with an external network must not be enumerated in the
2419 environment file. `ONAP Resource ID and Parameter Naming Convention`_
2420 provides additional details.
2422 VNFs may use **Cloud assigned IP addresses** or
2423 **ONAP SDN-C assigned IP addresses**
2424 when attaching VMs to an external network
2426 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2428 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2431 - Note that Neutron Floating IPs must not be used. ONAP does not
2432 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2434 - ONAP supports the property allowed\_address\_pairs in the resource
2435 OS::Neutron:Port and the property
2436 virtual\_machine\_interface\_allowed\_address\_pairs in
2437 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2438 of a virtual IP (VIP) address to a set of VMs.
2440 R-63345 The VNF Heat **MUST** pass the appropriate external
2441 network IDs into nested VM templates when nested Heat is used.
2446 R-35666 The VNF Heat **MUST** include the resource(s) to
2447 create the internal network. The internal network must be either a
2448 Neutron Network or a Contrail Network.
2450 R-86972 The VNF Heat **MUST** create internal networks in the Base
2451 Module, in the modular approach, with their resource IDs exposed as outputs
2452 (i.e., ONAP Base Module Output Parameters) for use by all incremental
2453 modules. If the Network resource ID is required in the base template,
2454 then a get\_resource must be used.
2456 R-68936 The VNF Heat **SHOULD** assign a unique
2457 {network-role} in the context of the VNF, when the internal network is
2458 created. `ONAP Resource ID and Parameter Naming Convention`_ provides
2461 VNFs may use **Cloud assigned IP addresses** or
2462 **predetermined static IPs** when attaching VMs to an internal network.
2464 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2466 - A predetermined static IP address is enumerated in the Heat
2467 environment file. Since an internal network is local to the VNF, IP
2468 addresses can be re-used at every VNF instance.
2470 - Note that Neutron Floating IPs must not be used. ONAP does not
2471 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2473 - ONAP supports the property allowed\_address\_pairs in the resource
2474 OS::Neutron:Port and the property
2475 virtual\_machine\_interface\_allowed\_address\_pairs in
2476 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2477 of a virtual IP (VIP) address to a set of VMs.
2479 ONAP does not programmatically enforce a naming convention for
2480 parameters for internal network. However, a naming convention is
2481 provided that must be followed.
2482 `ONAP Resource ID and Parameter Naming Convention`_
2483 provides additional details.
2485 ONAP Resource ID and Parameter Naming Convention
2486 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2488 This section provides the ONAP naming requirements for
2492 2. Resource Property Parameters
2497 R-01455 The VNF Heat **MUST** assign a VNF unique
2498 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2499 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2500 it does not have to be globally unique across all VNFs that ONAP
2503 R-82481 The VNF Heat **MUST** include {vm-type} as part of the parameter name
2504 for any parameter that is associated with a unique Virtual Machine type.
2506 R-66729 The VNF Heat **MUST** include {vm-type} as part of the resource ID
2507 for any resource ID that is associated with a unique Virtual Machine type in
2510 Note that {vm-type} must not be a substring of {network-role}. A
2511 substring of a string is another string that occurs "in". For example,
2512 "oam" is a substring of "oam\_protected". It will cause the
2513 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2514 produce erroneous error messages.
2516 The {vm-type} should not contain the string “\_int” or “int\_” or
2517 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2518 ICE Project) process to produce erroneous error messages.
2520 R-32394 The VNF Heat **MUST** use the same case for {vm-type} for all
2521 parameter names in the VNF.
2523 R-46839 The VNF Heat **MUST** use the same case for {vm-type} for all
2524 Resource IDs in the VNF.
2526 It is recommended that the {vm-type} case in the parameter names matches
2527 the {vm-type} case in the Resource IDs.
2529 There are two exceptions to the above rules:
2531 1. R-05008 The VNF Heat **MUST NOT** be prefixed with a common
2532 {vm-type} identifier for the six ONAP Metadata parameters.
2533 They are *vnf\_name*, *vnf\_id*, *vf\_module\_id*, *vf\_module\_name,
2534 vm\_role*. The ONAP Metadata parameters are described in
2535 `Resource: OS::Nova::Server – Metadata Parameters`_.
2537 2. R-15422 The VNF Heat **MUST NOT** be prefixed with a common {vm-type}
2538 identifier the parameter referring to the OS::Nova::Server property
2539 availability\_zone . availability\_zone is described in `Property: availability_zone`_.
2544 The assignment of a {network-role} is discussed in `Networking`_.
2546 R-21330 The VNF Heat **MUST** include the {network-role} as part of the
2547 parameter name for any parameter that is associated with an external network.
2549 R-11168 The VNF Heat **MUST** include the {network-role} as part of the
2550 resource ID for any resource ID that is associated with an external network
2553 R-84322 The VNF Heat **MUST** include int\_{network-role} as part of the
2554 parameter name for any parameter that is associated with an internal network.
2556 R-96983 The VNF Heat **MUST** include int\_{network-role} as part of the
2557 resource ID for any resource ID that is associated with an internal network.
2559 Note that {network-role} must not be a substring of {vm-type}. A
2560 substring of a string is another string that occurs "in". For example,
2561 "oam" is a substring of "oam\_protected". It will cause the
2562 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2563 produce erroneous error messages.
2565 The {network-role} should not contain the string “\_int” or “int\_” or
2566 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2567 ICE Project) process to produce erroneous error messages.
2569 R-58424 The VNF Heat **MUST** use the same case for {network-role} for
2570 all parameter names in the VNF.
2572 R-21511 The VNF Heat **MUST** use the same case for {network-role} for
2573 all Resource IDs in the VNF.
2575 It is recommended that the {network-role} case in the parameter names
2576 matches the {network-role} case in the Resource IDs.
2581 Heat Orchestration Template resources are described in `resources`_
2583 R-59629 The VNF Heat **MUST** have unique resource IDs within the
2584 resources section of a Heat Orchestration Template. This is an
2585 OpenStack Requirement.
2587 R-43319 The VNF Heat **MUST** have unique resource IDs
2588 across all modules that compose the VNF,
2589 when a VNF is composed of more than one Heat Orchestration Template
2592 R-54517 The VNF Heat **MUST** include {vm-type} in the resource ID
2593 when a resource is associated with a single {vm-type}.
2595 R-96482 The VNF Heat **MUST** include {network-role} in the resource ID
2596 when a resource is associated with a single external network.
2598 R-98138 The VNF Heat **MUST** include int\_{network-role} in the resource ID
2599 when a resource is associated with a single internal network.
2601 R-82115 The VNF Heat **MUST** include both the {vm-type} and
2602 {network-role} in the resource ID,
2603 when a resource is associated with a single {vm-type} and a single
2606 - The {vm-type} must appear before the {network-role} and must be
2607 separated by an underscore (i.e., {vm-type}\_{network-role}).
2609 - Note that an {index} value may separate the {vm-type} and the
2610 {network-role}. An underscore will separate the three values (i.e.,
2611 {vm-type}\_{index}\_{network-role}).
2613 R-82551 The VNF Heat **MUST** include both the {vm-type} and
2614 int\_{network-role} in the resource ID,
2615 when a resource is associated with a single {vm-type} and a single
2618 - The {vm-type} must appear before the int\_{network-role} and must be
2619 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2621 - Note that an {index} value may separate the {vm-type} and the
2622 int\_{network-role}. An underscore will separate the three values
2623 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2625 When a resource is associated with more than one {vm-type} and/or more
2626 than one network, the resource ID
2628 - must not contain the {vm-type} and/or
2629 {network-role}/int\_{network-role}
2631 - should contain the term “shared” and/or contain text that identifies
2634 R-69287 The VNF Heat **MUST** use only alphanumeric characters and “\_”
2635 underscores in the resource ID. Special characters must not be used.
2637 All {index} values must be zero based. That is, the {index} must start
2638 at zero and increment by one.
2640 The table below provides example OpenStack Heat resource ID for
2641 resources only associated with one {vm-type} and/or one network.
2643 +-----------------------------+--------------------------------------+
2644 | Resource Type | Resource ID Format |
2645 +=============================+======================================+
2646 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2647 +-----------------------------+--------------------------------------+
2648 | OS::Cinder::VolumeAttachment| {vm\_type}\_volumeattachment\_{index}|
2649 +-----------------------------+--------------------------------------+
2650 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2651 +-----------------------------+--------------------------------------+
2652 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2653 +-----------------------------+--------------------------------------+
2654 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2655 +-----------------------------+--------------------------------------+
2656 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2657 +-----------------------------+--------------------------------------+
2658 | OS::Neutron::Port | {vm\_type}\_{index}\ |
2659 | | _{network\_role}\_{index}\_port |
2660 +-----------------------------+--------------------------------------+
2661 | | {vm\_type}\_{index}\ |
2662 | | _int\_{network\_role}\_{index}\_port |
2663 +-----------------------------+--------------------------------------+
2664 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2665 +-----------------------------+--------------------------------------+
2666 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2667 +-----------------------------+--------------------------------------+
2668 | OS::Nova::Server | {vm\_type}\_{index} |
2669 +-----------------------------+--------------------------------------+
2670 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2671 +-----------------------------+--------------------------------------+
2672 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2673 +-----------------------------+--------------------------------------+
2675 Table 1: Example OpenStack Heat Resource ID
2677 The table below provides example Contrail Heat resource ID for resources
2678 only associated with one {vm-type} and/or one network.
2680 +-------------------------------------------+---------------------------------+
2681 | Resource Type | Resource ID Format |
2682 +===========================================+=================================+
2683 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\ |
2684 | | _{network\_role}\_RII |
2685 +-------------------------------------------+---------------------------------+
2686 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2687 +-------------------------------------------+---------------------------------+
2688 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2689 +-------------------------------------------+---------------------------------+
2690 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2691 +-------------------------------------------+---------------------------------+
2692 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2693 +-------------------------------------------+---------------------------------+
2694 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2695 +-------------------------------------------+---------------------------------+
2696 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2697 +-------------------------------------------+---------------------------------+
2698 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2699 +-------------------------------------------+---------------------------------+
2701 Table 2: Example Contrail Heat resource ID
2703 Resource: OS::Nova::Server - Parameters
2704 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2706 The resource OS::Nova::Server manages the running virtual machine (VM)
2707 instance within an OpenStack cloud. (See
2708 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2710 Four properties of this resource must follow the ONAP parameter naming
2711 convention. The four properties are:
2719 4. availability\_zone
2721 The table below provides a summary. The sections that follow provides
2724 Note that the {vm\_type} must be identical across all four property
2725 parameters for a given OS::Nova::Server resource.
2727 +----------------------------------------------------------------------------+
2728 | Resource OS::Nova::Server |
2729 +--------------+----------------+----------+----------------+----------------+
2730 | Property Name| ONAP Parameter | Parameter| Parameter Value| ONAP Parameter |
2731 | | Name | Type | Generation | Classification |
2732 +==============+================+==========+================+================+
2733 | image | {vm-type}\ | string | Environment | ONAP |
2734 | | _image\_name | string | File | Constant |
2735 +--------------+----------------+----------+----------------+----------------+
2736 | flavor | {vm-type}\ | string | Environment | ONAP |
2737 | | _flavor\_name | | File | Constant |
2738 +--------------+----------------+----------+----------------+----------------+
2739 | name | {vm-type}\ | string | ONAP | ONAP |
2740 | | _name\_{index} | | | Orchestration |
2741 +--------------+----------------+----------+----------------+----------------+
2742 | | {vm-type}\ | CDL | ONAP | ONAP |
2743 | | _names | | | Orchestration |
2744 +--------------+----------------+----------+----------------+----------------+
2745 | availability\| availability\ | string | ONAP | ONAP |
2746 | _zone | _zone\_{index} | | | Orchestration |
2747 +--------------+----------------+----------+----------------+----------------+
2749 Table 3 Resource Property Parameter Names
2754 The parameter associated with the property image is an ONAP Constant
2757 The parameters must be named {vm-type}\_image\_name in the Heat
2758 Orchestration Template.
2760 R-71152 The VNF Heat **MUST** declare as type: string the parameter
2763 R-91125 The VNF Heat **MUST** enumerate the parameter for property
2764 image in the Heat Orchestration Template environment file.
2766 R-57282 The VNF Heat **MUST** have a separate parameter for image for
2767 Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares
2768 the same image. This provides maximum clarity and flexibility.
2770 *Example Parameter Definition*
2772 .. code-block:: yaml
2775 {vm-type}_image_name:
2777 description: {vm-type} server image
2782 The parameter associated with the property flavor is an ONAP Constant
2785 The parameters must be named {vm-type}\_flavor\_name in the Heat
2786 Orchestration Template.
2788 R-50436 The VNF Heat **MUST** declare the parameter property for
2789 flavor as type: string.
2791 R-69431 The VNF Heat **MUST** enumerate the parameter for property
2792 flavor in the Heat Orchestration Template environment file.
2794 R-40499 The VNF Heat **MUST** have a separate parameter for flavor for each
2795 VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same
2796 flavor. This provides maximum clarity and flexibility.
2798 *Example Parameter Definition*
2800 .. code-block:: yaml
2803 {vm-type}_flavor_name:
2805 description: {vm-type} flavor
2810 The parameter associated with the property name is an ONAP Orchestration
2813 The parameter value is provided to the Heat template by ONAP.
2815 R-22838 The VNF Heat **MUST NOT** enumerate the parameter for property name
2816 in the environment file.
2818 R-51430 The VNF Heat **MUST** declare the parameter for property name as
2819 type: string or type: comma\_delimited\_list
2821 If the parameter is declared as type:string, the parameter must be named
2822 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2823 at zero and increments by one.
2825 If the parameter is declared as type:comma\_delimited\_list, the
2826 parameter must be named as {vm-type}\_names
2828 Each element in the VM Name list should be assigned to successive
2829 instances of that VM type.
2831 If a VNF contains more than three instances of a given {vm-type}, the
2832 comma\_delimited\_list form of the parameter name (i.e.,
2833 {vm-type}\_names) should be used to minimize the number of unique
2834 parameters defined in the Heat.
2836 *Example: Parameter Definition*
2838 .. code-block:: yaml
2842 type: comma_delimited_list
2843 description: VM Names for {vm-type} VMs
2844 {vm-type}_name_{index}:
2846 description: VM Name for {vm-type} VM {index}
2848 *Example: comma\_delimited\_list*
2850 In this example, the {vm-type} has been defined as “lb” for load
2853 .. code-block:: yaml
2857 type: comma_delimited_list
2858 description: VM Names for lb VMs
2862 type: OS::Nova::Server
2864 name: { get_param: [lb_names, 0] }
2868 type: OS::Nova::Server
2870 name: { get_param: [lb_names, 1] }
2873 *Example: fixed-index*
2875 In this example, the {vm-type} has been defined as “lb” for load
2878 .. code-block:: yaml
2883 description: VM Name for lb VM 0
2887 description: VM Name for lb VM 1
2891 type: OS::Nova::Server
2893 name: { get_param: lb_name_0 }
2897 type: OS::Nova::Server
2899 name: { get_param: lb_name_1 }
2902 Contrail Issue with Values for OS::Nova::Server Property Name
2903 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2905 The Contrail GUI has a limitation displaying special characters. The
2906 issue is documented in
2907 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2908 recommended that special characters be avoided. However, if special
2909 characters must be used, the only special characters supported are:
2911 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2913 Property: availability\_zone
2914 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2916 The parameter associated with the property availability\_zone is an ONAP
2917 Orchestration parameter.
2919 The parameter value is provided to the Heat template by ONAP. The
2920 parameter must not be enumerated in the environment file.
2922 R-98450 The VNF Heat **MUST** name the parameter availability\_zone\_{index}
2923 in the Heat Orchestration Template.
2925 R-13561 The VNF Heat **MUST** start the {index} at zero.
2927 R-60204 The VNF Heat **MUST** increment the {index} by one.
2929 R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name.
2931 The parameter must be declared as type: string
2933 The parameter must not be declared as type: comma\_delimited\_list
2938 The example below depicts part of a Heat Orchestration Template that
2939 uses the four OS::Nova::Server properties discussed in this section.
2941 In the Heat Orchestration Template below, four Virtual Machines
2942 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2943 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2944 parameter associated with the property name is a comma\_delimited\_list
2945 for dns and a string for oam.
2947 .. code-block:: yaml
2952 description: dns server image
2955 description: dns server flavor
2957 type: comma_delimited_list
2958 description: dns server names
2961 description: oam server image
2964 description: oam server flavor
2967 description: oam server name 0
2970 description: oam server name 1
2971 availability_zone_0:
2973 description: availability zone ID or Name
2974 availability_zone_1:
2976 description: availability zone ID or Name
2980 type: OS::Nova::Server
2982 name: { get_param: [ dns_names, 0 ] }
2983 image: { get_param: dns_image_name }
2984 flavor: { get_param: dns_flavor_name }
2985 availability_zone: { get_param: availability_zone_0 }
2989 type: OS::Nova::Server
2991 name: { get_param: [ dns_names, 1 ] }
2992 image: { get_param: dns_image_name }
2993 flavor: { get_param: dns_flavor_name }
2994 availability_zone: { get_param: availability_zone_1 }
2998 type: OS::Nova::Server
3000 name: { get_param: oam_name_0 }
3001 image: { get_param: oam_image_name }
3002 flavor: { get_param: oam_flavor_name }
3003 availability_zone: { get_param: availability_zone_0 }
3007 type: OS::Nova::Server
3009 name: { get_param: oam_name_1 }
3010 image: { get_param: oam_image_name }
3011 flavor: { get_param: oam_flavor_name }
3012 availability_zone: { get_param: availability_zone_1 }
3015 Resource: OS::Nova::Server – Metadata Parameters
3016 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3018 The resource OS::Nova::Server has an OpenStack optional property
3019 metadata. The metadata property is mandatory for ONAP Heat Orchestration
3020 Templates; it must be included.
3022 R-17020 The VNF Heat **MUST** include the following three mandatory
3023 metadata parameters for an OS::Nova::Server resource:
3031 ONAP allows the following three optional metadata parameters for an
3032 OS::Nova::Server resource. They may be included
3038 Note that the metadata parameters do not and must not contain {vm-type}
3041 When Metadata parameters are past into a nested heat template, the
3042 parameter names must not change.
3044 The table below provides a summary. The sections that follow provides
3047 +-------------------+----------+-------------------+----------------+
3048 | Metadata Parameter| Parameter| Mandatory/Optional| Parameter Value|
3049 | Name | Type | | Generation |
3050 +===================+==========+===================+================+
3051 | vnf\_id | string | Mandatory | ONAP |
3052 +-------------------+----------+-------------------+----------------+
3053 | vf\_module\_id | string | Mandatory | ONAP |
3054 +-------------------+----------+-------------------+----------------+
3055 | vnf\_name | string | Mandatory | ONAP |
3056 +-------------------+----------+-------------------+----------------+
3057 | vf\_module\_name | string | Optional | ONAP |
3058 +-------------------+----------+-------------------+----------------+
3059 | vm\_role | string | Optional | YAML or |
3060 | | | | Environment |
3062 +-------------------+----------+-------------------+----------------+
3064 Table 4: ONAP Metadata
3069 The vnf\_id parameter is mandatory; it must be included in the Heat
3070 Orchestration Template.
3072 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
3073 UUID that is the vnf\_id and supplies it to the Heat Orchestration
3074 Template at orchestration time.
3076 The parameter must be declared as type: string
3078 R-55218 The VNF Heat **MUST NOT** have parameter constraints defined
3079 for the OS::Nova::Server metadata parameter vnf\_id.
3081 R-20856 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
3082 metadata parameter vnf\_id in environment file.
3084 *Example Parameter Definition*
3086 .. code-block:: yaml
3091 description: Unique ID for this VNF instance
3096 The vf\_module\_id parameter is mandatory; it must be included in the
3097 Heat Orchestration Template.
3099 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
3100 generates the UUID that is the vf\_module\_id and supplies it to the
3101 Heat Orchestration Template at orchestration time.
3103 The parameter must be declared as type: string
3105 R-98374 The VNF Heat **MUST NOT** have parameter constraints
3106 defined for the OS::Nova::Server metadata parameter vf\_module\_id.
3108 R-72871 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
3109 metadata parameter vf\_module\_id in environment file.
3111 *Example Parameter Definition*
3113 .. code-block:: yaml
3118 description: Unique ID for this VNF module instance
3123 The vnf\_name parameter is mandatory; it must be included in the Heat
3124 Orchestration Template.
3126 The vnf\_name parameter value will be generated and/or assigned by ONAP
3127 and supplied to the Heat Orchestration Template by ONAP at orchestration
3130 The parameter must be declared as type: string
3132 R-44318 The VNF Heat **MUST NOT** have parameter constraints defined
3133 for the OS::Nova::Server metadata parameter vnf\_name.
3135 R-36542 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
3136 metadata parameter vnf\_name in the environment file.
3138 *Example Parameter Definition*
3140 .. code-block:: yaml
3145 description: Unique name for this VNF instance
3150 The vf\_module\_name parameter is optional; it may be included in the
3151 Heat Orchestration Template.
3153 The vf\_module\_name parameter is the name of the name of the Heat stack
3154 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3155 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3156 needs to be specified as part of the orchestration process.
3158 The parameter must be declared as type: string
3160 Parameter constraints must not be defined.
3162 The parameter must not be enumerated in the Heat environment file.
3164 *Example Parameter Definition*
3166 .. code-block:: yaml
3171 description: Unique name for this VNF Module instance
3176 The vm\_role parameter is optional; it may be included in the Heat
3177 Orchestration Template.
3179 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3180 system and available for use by other ONAP components and/or north bound
3183 The vm\_role values must be either
3185 - hard-coded into the Heat Orchestration Template or
3187 - enumerated in the environment file.
3189 Defining the vm\_role as the {vm-type} is a recommended convention
3191 The parameter must be declared as type: string
3193 Parameter constraints must not be defined.
3195 *Example Parameter Definition*
3197 .. code-block:: yaml
3202 description: Unique role for this VM
3204 *Example Resource Definition: Hard Coded*
3206 In this example, the {vm-role} is hard coded in the Heat Orchestration
3209 .. code-block:: yaml
3213 type: OS::Nova::Server
3219 *Example Resource Definition: get\_param*
3221 In this example, the {vm-role} is enumerated in the environment file.
3223 .. code-block:: yaml
3227 type: OS::Nova::Server
3231 vm_role: { get_param: vm_role }
3236 The example below depicts part of a Heat Orchestration Template that
3237 uses the five of the OS::Nova::Server metadata parameter discussed in
3238 this section. The {vm-type} has been defined as lb for load balancer.
3240 .. code-block:: yaml
3245 description: VM Name for lb VM 0
3248 description: Unique name for this VNF instance
3251 description: Unique ID for this VNF instance
3254 description: Unique name for this VNF Module instance
3257 description: Unique ID for this VNF Module instance
3260 description: Unique role for this VM
3265 type: OS::Nova::Server
3267 name: { get_param: lb_name_0 }
3270 vnf_name: { get_param: vnf_name }
3271 vnf_id: { get_param: vnf_id }
3272 vf_module_name: { get_param: vf_module_name }
3273 vf_module_id: { get_param: vf_module_id }
3276 Resource: OS::Neutron::Port - Parameters
3277 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3279 The resource OS::Neutron::Port is for managing Neutron ports (See
3280 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3285 Four properties of the resource OS::Neutron::Port that must follow the
3286 ONAP parameter naming convention. The four properties are:
3290 2. fixed\_ips, ip\_address
3292 3. fixed\_ips, subnet\_id
3294 4. allowed\_address\_pairs, ip\_address
3296 The parameters associated with these properties may reference an
3297 external network or internal network. External networks and internal
3298 networks are defined in `Networking`_.
3303 When the parameter references an external network
3305 - R-72050 The VNF Heat **MUST** contain {network-role} in the parameter name
3307 - the parameter must not be enumerated in the Heat environment file
3309 - the parameter is classified as an ONAP Orchestration Parameter
3311 +----------------------+---------------------------+--------------------------+
3312 | Property Name | ONAP Parameter Name | Parameter Type |
3313 +======================+===========================+==========================+
3314 | network | {network-role}\_net\_id | string |
3315 | +---------------------------+--------------------------+
3316 | | {network-role}\_net\_name | string |
3317 +----------------------+---------------------------+--------------------------+
3318 | fixed\_ips, | {vm-type}\_{network-role}\| string |
3319 | ip\_address | _ip\_{index} | |
3320 | +---------------------------+--------------------------+
3321 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3323 | +---------------------------+--------------------------+
3324 | | {vm-type}\_{network-role}\| string |
3325 | | _v6\_ip\_{index} | |
3326 | +---------------------------+--------------------------+
3327 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3329 +----------------------+---------------------------+--------------------------+
3330 | fixed\_ips, subnet | {network-role}\ | string |
3332 | +---------------------------+--------------------------+
3333 | | {network-role}\ | string |
3334 | | _v6\_subnet\_id | |
3335 +----------------------+---------------------------+--------------------------+
3336 | allowed\_address | {vm-type}\_{network-role}\| string |
3337 | \_pairs, ip\_address | _floating\_ip | |
3338 | +---------------------------+--------------------------+
3339 | | {vm-type}\_{network-role}\| string |
3340 | | _floating\_v6\_ip | |
3341 | +---------------------------+--------------------------+
3342 | | {vm-type}\_{network-role}\| string |
3343 | | _ip\_{index} | |
3344 | +---------------------------+--------------------------+
3345 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3347 | +---------------------------+--------------------------+
3348 | | {vm-type}\_{network-role}\| string |
3349 | | _v6\_ip\_{index} | |
3350 | +---------------------------+--------------------------+
3351 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3353 +----------------------+---------------------------+--------------------------+
3355 Table 5: OS::Neutron::Port Resource Property Parameters (External
3361 When the parameter references an internal network
3363 - R-57576 The VNF Heat **MUST** contain int\_{network-role}
3364 in the parameter name.
3366 - the parameter may be enumerated in the environment file.
3368 +-------------------------+--------------------------------+-----------------+
3369 | Property | Parameter Name for | Parameter Type |
3370 | | Internal Networks | |
3371 +=========================+================================+=================+
3372 | network | int\_{network-role}\ | string |
3374 | +--------------------------------+-----------------+
3375 | | int\_{network-role}\ | string |
3377 +-------------------------+--------------------------------+-----------------+
3378 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\| string |
3379 | | _ip\_{index} | |
3380 | +--------------------------------+-----------------+
3381 | | {vm-type}\_int\_{network-role}\| comma\ |
3382 | | _ips | _delimited\_list|
3383 | +--------------------------------+-----------------+
3384 | | {vm-type}\_int\_{network-role}\| string |
3385 | | _v6\_ip\_{index} | |
3386 | +--------------------------------+-----------------+
3387 | | {vm-type}\_int\_{network-role}\| comma\ |
3388 | | _v6\_ips | _delimited\_list|
3389 +-------------------------+--------------------------------+-----------------+
3390 | fixed\_ips, subnet | int\_{network-role}\ | string |
3392 | +--------------------------------+-----------------+
3393 | | int\_{network-role}\ | string |
3394 | | _v6\_subnet\_id | |
3395 +-------------------------+--------------------------------+-----------------+
3396 | allowed\_address\_pairs,| {vm-type}\_int\_{network-role}\| string |
3397 | ip\_address | _floating\_ip | |
3398 | +--------------------------------+-----------------+
3399 | | {vm-type}\_int\_{network-role}\| string |
3400 | | _floating\_v6\_ip | |
3401 | +--------------------------------+-----------------+
3402 | | {vm-type}\_int\_{network-role}\| string |
3403 | | _ip\_{index} | |
3404 | +--------------------------------+-----------------+
3405 | | {vm-type}\_int\_{network-role}\| comma\ |
3406 | | _ips | _delimited\_list|
3407 | +--------------------------------+-----------------+
3408 | | {vm-type}\_int\_{network-role}\| string |
3409 | | _v6\_ip\_{index} | |
3410 | +--------------------------------+-----------------+
3411 | | {vm-type}\_int\_{network-role}\| comma\ |
3412 | | _v6\_ips | _delimited\_list|
3413 +-------------------------+--------------------------------+-----------------+
3415 Table 6: Port Resource Property Parameters (Internal Networks)
3420 The property networks in the resource OS::Neutron::Port must be
3421 referenced by Neutron Network ID, a UUID value, or by the network name
3422 defined in OpenStack.
3427 R-93272 The VNF Heat **MUST** adhere to the following parameter naming
3428 convention in the Heat Orchestration Template, when the parameter
3429 associated with the property network is referencing an “external” network:
3431 - {network-role}\_net\_id for the Neutron network ID
3433 - {network-role}\_net\_name for the network name in OpenStack
3435 The parameter must be declared as type: string
3437 The parameter must not be enumerated in the Heat environment file.
3439 *Example Parameter Definition*
3441 .. code-block:: yaml
3444 {network-role}_net_id:
3446 description: Neutron UUID for the {network-role} network
3447 {network-role}_net_name:
3449 description: Neutron name for the {network-role} network
3451 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3452 that has only one subnet*
3454 In this example, the {network-role} has been defined as oam to represent
3455 an oam network and the {vm-type} has been defined as lb for load
3456 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3457 to assign IP addresses.
3459 .. code-block:: yaml
3464 description: Neutron UUID for the oam network
3468 type: OS::Neutron::Port
3469 network: { get_param: oam_net_id }
3474 R-65373 The VNF Heat **MUST** adhere to the following parameter naming
3475 convention, when the parameter associated with the property network is
3476 referencing an “internal” network:
3478 - int\_{network-role}\_net\_id for the Neutron network ID
3480 - int\_{network-role}\_net\_name for the network name in OpenStack
3482 The parameter must be declared as type: string
3484 The assumption is that internal networks are created in the base module.
3485 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3486 Base Module Output Parameter) to the incremental modules. In the
3487 incremental modules, it will be defined as input parameter.
3489 *Example Parameter Definition*
3491 .. code-block:: yaml
3494 int_{network-role}_net_id:
3496 description: Neutron UUID for the {network-role} network
3497 int_{network-role}_net_name:
3499 description: Neutron name for the {network-role} network
3501 Property: fixed\_ips, Map Property: subnet\_id
3502 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3504 The property fixed\_ips is used to assign IPs to a port. The Map
3505 Property subnet\_id specifies the subnet the IP is assigned from.
3507 The property fixed\_ips and Map Property subnet\_id must be used if a
3508 Cloud (i.e., DHCP) IP address assignment is being requested and the
3509 Cloud IP address assignment is targeted at a specific subnet when two or
3512 The property fixed\_ips and Map Property subnet\_id should not be used
3513 if all IP assignments are fixed, or if the Cloud IP address assignment
3514 does not target a specific subnet or there is only one subnet.
3516 Note that DHCP assignment of IP addresses is also referred to as cloud
3517 assigned IP addresses.
3519 Subnet of an External Networks
3520 +++++++++++++++++++++++++++++++
3522 R-47716 The VNF Heat **MUST** adhere to the following parameter naming
3523 convention for the property fixed\_ips and Map Property subnet\_id
3524 parameter, when the parameter is referencing a subnet of an
3527 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3529 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3531 The parameter must be declared as type: string
3533 The parameter must not be enumerated in the Heat environment file.
3535 *Example Parameter Definition*
3537 .. code-block:: yaml
3540 {network-role}_subnet_id:
3542 description: Neutron subnet UUID for the {network-role} network
3544 {network-role}_v6_subnet_id:
3546 description: Neutron subnet UUID for the {network-role} network
3548 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3549 that has two or more subnets subnet:*
3551 In this example, the {network-role} has been defined as oam to represent
3552 an oam network and the {vm-type} has been defined as lb for load
3553 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3554 to assign IP addresses.
3556 .. code-block:: yaml
3561 description: Neutron UUID for the oam network
3565 description: Neutron subnet UUID for the oam network
3569 type: OS::Neutron::Port
3570 network: { get_param: oam_net_id }
3572 - subnet_id: { get_param: oam_subnet_id }
3574 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3575 address assigned to a network that has at least one IPv4 subnet and one
3578 In this example, the {network-role} has been defined as oam to represent
3579 an oam network and the {vm-type} has been defined as lb for load
3582 .. code-block:: yaml
3587 description: Neutron UUID for the oam network
3591 description: Neutron subnet UUID for the oam network
3595 description: Neutron subnet UUID for the oam network
3599 type: OS::Neutron::Port
3601 network: { get_param: oam_net_id }
3603 - subnet_id: { get_param: oam_subnet_id }
3604 - subnet_id: { get_param: oam_v6_subnet_id }
3609 R-20106 The VNF Heat **MUST** adhere to the following naming convention for
3610 the property fixed\_ips and Map Property subnet\_id parameter,
3611 when the parameter is referencing the subnet of an “internal” network:
3613 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3615 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3617 The parameter must be declared as type: string
3619 The assumption is that internal networks are created in the base module.
3620 The Neutron subnet network ID will be passed as an output parameter
3621 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3622 the incremental modules, it will be defined as input parameter.
3624 *Example Parameter Definition*
3626 .. code-block:: yaml
3629 int_{network-role}_subnet_id:
3631 description: Neutron subnet UUID for the {network-role} network
3633 int_{network-role}_v6_subnet_id:
3635 description: Neutron subnet UUID for the {network-role} network
3637 Property: fixed\_ips, Map Property: ip\_address
3638 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3640 The property fixed\_ips is used to assign IPs to a port. The Map
3641 Property ip\_address specifies the IP address to be assigned to the
3644 The property fixed\_ips and Map Property ip\_address must be used when
3645 statically assigning one or more IP addresses to a port. This is also
3646 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3647 the IP address assignment.
3649 An IP address is assigned to a port on a VM (referenced by {vm-type})
3650 that is connected to an external network (referenced by {network-role})
3651 or internal network (referenced by int\_{network-role}).
3653 R-41177 The VNF Heat **MUST** include {vm-type} and {network-role}
3654 in the parameter name, when a SDN-C IP assignment is made to a
3655 port connected to an external network.
3657 When a SDN-C IP assignment is made to a port connected to an internal
3658 network, the parameter name must contain {vm-type} and
3659 int\_{network-role}.
3661 IP Address Assignments on External Networks
3662 ++++++++++++++++++++++++++++++++++++++++++++
3664 When the property fixed\_ips and Map Property ip\_address is used to
3665 assign IP addresses to an external network, the parameter name is
3666 dependent on the parameter type (comma\_delimited\_list or string) and
3667 IP address type (IPv4 or IPv6).
3669 R-84898 The VNF Heat **MUST** adhere to the following naming convention,
3670 when the parameter for property fixed\_ips and Map Property ip\_address
3671 is declared type: comma\_delimited\_list:
3673 - {vm-type}\_{network-role}\_ips for IPv4 address
3675 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3677 Each element in the IP list should be assigned to successive instances
3678 of {vm-type} on {network-role}.
3680 The parameter must not be enumerated in the Heat environment file.
3682 *Example Parameter Definition*
3684 .. code-block:: yaml
3688 {vm-type}_{network-role}_ips:
3689 type: comma_delimited_list
3690 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3692 {vm-type}_{network-role}_v6_ips:
3693 type: comma_delimited_list
3694 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3696 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3697 Assignments to an external network*
3699 In this example, the {network-role} has been defined as oam to represent
3700 an oam network and the {vm-type} has been defined as db for database.
3702 .. code-block:: yaml
3707 description: Neutron UUID for a oam network
3710 type: comma_delimited_list
3711 description: Fixed IPv4 assignments for db VMs on the oam network
3714 type: comma_delimited_list
3715 description: Fixed IPv6 assignments for db VMs on the oam network
3719 type: OS::Neutron::Port
3720 network: { get_param: oam_net_id }
3721 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3724 type: OS::Neutron::Port
3726 network: { get_param: oam_net_id }
3728 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3729 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3731 R-34960 The VNF Heat **MUST** adhere to the following
3733 when the parameter for property fixed\_ips and Map Property ip\_address
3734 is declared type: string:
3736 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3738 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3740 The value for {index} must start at zero (0) and increment by one.
3742 The parameter must not be enumerated in the Heat environment file.
3744 *Example Parameter Definition*
3746 .. code-block:: yaml
3749 {vm-type}_{network-role}_ip_{index}:
3751 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3753 {vm-type}_{network-role}_v6_ip_{index}:
3755 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3757 *Example: string parameters for IPv4 and IPv6 Address Assignments
3758 to an external network*
3760 In this example, the {network-role} has been defined as “oam” to
3761 represent an oam network and the {vm-type} has been defined as “db” for
3764 .. code-block:: yaml
3769 description: Neutron UUID for an OAM network
3773 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3777 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3781 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3785 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3789 type: OS::Neutron::Port
3791 network: { get_param: oam_net_id }
3792 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3795 type: OS::Neutron::Port
3797 network: { get_param: oam_net_id }
3799 - “ip_address”: {get_param: db_oam_ip_1}}]
3800 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3802 IP Address Assignment on Internal Networks
3803 ++++++++++++++++++++++++++++++++++++++++++++
3805 When the property fixed\_ips and Map Property ip\_address is used to
3806 assign IP addresses to an internal network, the parameter name is
3807 dependent on the parameter type (comma\_delimited\_list or string) and
3808 IP address type (IPv4 or IPv6).
3810 R-62584 The VNF Heat **MUST** adhere to
3811 the following naming convention,
3812 when the parameter for property fixed\_ips and Map Property ip\_address
3813 is declared type: comma\_delimited\_list:
3815 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3817 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3819 Each element in the IP list should be assigned to successive instances
3820 of {vm-type} on {network-role}.
3822 The parameter must be enumerated in the Heat environment file. Since an
3823 internal network is local to the VNF, IP addresses can be re-used at
3826 *Example Parameter Definition*
3828 .. code-block:: yaml
3832 {vm-type}_int_{network-role}_ips:
3833 type: comma_delimited_list
3834 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3836 {vm-type}_int_{network-role}_v6_ips:
3837 type: comma_delimited_list
3838 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3840 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3841 Assignments to an internal network*
3843 In this example, the {network-role} has been defined as oam\_int to
3844 represent an oam network internal to the vnf. The role oam\_int was
3845 picked to differentiate from an external oam network with a
3846 {network-role} of oam. The {vm-type} has been defined as db for
3849 .. code-block:: yaml
3854 description: Neutron UUID for the oam internal network
3857 type: comma_delimited_list
3858 description: Fixed IPv4 assignments for db VMs on the oam internal network
3860 db_int_oam_int_v6_ips:
3861 type: comma_delimited_list
3862 description: Fixed IPv6 assignments for db VMs on the oam internal network
3866 type: OS::Neutron::Port
3868 network: { get_param: int_oam_int_net_id }
3869 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3872 type: OS::Neutron::Port
3874 network: { get_param: int_oam_int_net_id }
3876 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3877 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3879 R-29256 The VNF Heat **MUST** must adhere to the following
3881 when the parameter for property fixed\_ips and Map Property ip\_address
3882 is declared type: string:
3884 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3886 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3888 The value for {index} must start at zero (0) and increment by one.
3890 The parameter must be enumerated in the Heat environment file. Since an
3891 internal network is local to the VNF, IP addresses can be re-used at
3894 *Example Parameter Definition*
3896 .. code-block:: yaml
3900 {vm-type}_int_{network-role}_ip_{index}:
3902 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3904 {vm-type}_int_{network-role}_v6_ip_{index}:
3906 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3908 *Example: string parameters for IPv4 and IPv6 Address Assignments
3909 to an internal network*
3911 In this example, the {network-role} has been defined as oam\_int to
3912 represent an oam network internal to the vnf. The role oam\_int was
3913 picked to differentiate from an external oam network with a
3914 {network-role} of oam. The {vm-type} has been defined as db for
3917 .. code-block:: yaml
3922 description: Neutron UUID for an OAM internal network
3926 description: Fixed IPv4 assignment for db VM on the oam_int network
3930 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3934 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3938 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3942 type: OS::Neutron::Port
3944 network: { get_param: int_oam_int_net_id }
3945 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3948 type: OS::Neutron::Port
3950 network: { get_param: int_oam_int_net_id }
3952 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3953 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3955 Property: allowed\_address\_pairs, Map Property: ip\_address
3956 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3958 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3959 allows the user to specify a mac\_address and/or ip\_address that will
3960 pass through a port regardless of subnet. This enables the use of
3961 protocols such as VRRP, which floats an IP address between two instances
3962 to enable fast data plane failover. The map property ip\_address
3963 specifies the IP address.
3965 The allowed\_address\_pairs is an optional property. It is not required.
3967 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3968 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3969 and {network-role}/int\_{network-role} combination.
3971 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3972 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3973 and {network-role}/int\_{network-role} combination.
3975 Note that the management of these IP addresses (i.e. transferring
3976 ownership between active and standby VMs) is the responsibility of the
3979 Note that these parameters are **not** intended to represent Neutron
3980 “Floating IP” resources, for which OpenStack manages a pool of public IP
3981 addresses that are mapped to specific VM ports. In that case, the
3982 individual VMs are not even aware of the public IPs, and all assignment
3983 of public IPs to VMs is via OpenStack commands. ONAP does not support
3984 Neutron-style Floating IPs.
3989 R-61282 The VNF Heat **MUST**
3990 adhere to the following naming convention for the property
3991 allowed\_address\_pairs and Map Property ip\_address parameter,
3992 when the parameter is referencing an “external” network:
3994 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3996 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3998 The parameter must be declared as type: string
4000 The parameter must not be enumerated in the Heat environment file.
4002 *Example Parameter Definition*
4004 .. code-block:: yaml
4008 {vm-type}_{network-role}_floating_ip:
4010 description: VIP for {vm-type} VMs on the {network-role} network
4012 {vm-type}_{network-role}_floating_v6_ip:
4014 description: VIP for {vm-type} VMs on the {network-role} network
4018 In this example, the {network-role} has been defined as oam to represent
4019 an oam network and the {vm-type} has been defined as db for database.
4021 .. code-block:: yaml
4026 description: Neutron UUID for the oam network
4029 type: comma_delimited_list
4030 description: Fixed IPs for db VMs on the oam network
4034 description: VIP IP for db VMs on the oam network
4038 type: OS::Neutron::Port
4040 network: { get_param: oam_net_id }
4041 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
4042 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4045 type: OS::Neutron::Port
4047 network: { get_param: oam_net_id }
4048 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
4049 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4054 R-16805 The VNF Heat **MUST** adhere to the following naming convention
4055 for the property allowed\_address\_pairs and Map Property ip\_address
4056 parameter when the parameter is referencing an “internal” network.
4058 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
4060 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
4062 The parameter must be declared as type: string
4064 The parameter must be enumerated in the Heat environment file.
4066 *Example Parameter Definition*
4068 .. code-block:: yaml
4072 {vm-type}_int_{network-role}_floating_ip:
4074 description: VIP for {vm-type} VMs on the int_{network-role} network
4076 {vm-type}_int_{network-role}_floating_v6_ip:
4078 description: VIP for {vm-type} VMs on the int_{network-role} network
4080 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
4081 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4083 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
4084 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
4086 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
4087 one allowed address pair IPv6 address per {vm-type} and {network-role}
4090 If there is a need for multiple allowed address pair IPs for a given
4091 {vm-type} and {network-role} combination within a VNF, then the
4092 parameter names defined for the property fixed\_ips and Map Property
4093 ip\_address should be used with the allowed\_address\_pairs property.
4094 The examples below illustrate this.
4096 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
4098 In this example, there are two administrative VM pairs. Each pair has
4099 one VIP. The {network-role} has been defined as oam to represent an oam
4100 network and the {vm-type} has been defined as admin for an
4103 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
4104 VIP, [admin\_oam\_ips,2]
4106 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
4107 VIP, [admin\_oam\_ips,5]
4109 .. code-block:: yaml
4114 description: Neutron UUID for the oam network
4116 type: comma_delimited_list
4117 description: Fixed IP assignments for admin VMs on the oam network
4122 type: OS::Neutron::Port
4124 network: { get_param: oam_net_id }
4125 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
4126 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4129 type: OS::Neutron::Port
4131 network: { get_param: oam_net_id }
4132 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
4133 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4136 type: OS::Neutron::Port
4138 network: { get_param: oam_net_id }
4139 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
4140 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4143 type: OS::Neutron::Port
4145 network: { get_param: oam_net_id }
4146 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
4147 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4149 *Example: A VNF has two load balancers. The pair of load balancers share
4152 In this example, there is one load balancer pairs. The pair has two
4153 VIPs. The {network-role} has been defined as oam to represent an oam
4154 network and the {vm-type} has been defined as lb for a load balancer VM.
4156 .. code-block:: yaml
4160 type: OS::Neutron::Port
4162 network: { get_param: oam_net_id }
4163 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
4164 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4167 type: OS::Neutron::Port
4169 network: { get_param: oam_net_id }
4170 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
4171 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4173 As a general rule, provide the fixed IPs for the VMs indexed first in
4174 the CDL and then the VIPs as shown in the examples above.
4176 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
4177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4179 The following items must be taken into consideration when designing Heat
4180 Orchestration Templates that expect ONAP’s SDN-C to assign
4181 allowed\_address\_pair IP addresses via automation.
4183 The VMs must be of the same {vm-type}.
4185 The VMs must be created in the same module (base or incremental).
4187 Resource Property “name”
4188 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4190 The parameter naming convention of the property name for the resource
4191 OS::Nova::Server has been defined in
4192 `Resource: OS::Nova::Server – Metadata Parameters`_.
4194 This section provides the requirements how the property name for non
4195 OS::Nova::Server resources must be defined when the property is used.
4196 Not all resources require the property name (e.g., it is optional) and
4197 some resources do not support the property.
4199 R-85734 The VNF Heat **MUST** use the intrinsic function str\_replace
4200 in conjunction with the ONAP supplied metadata parameter
4201 vnf\_name to generate a unique value,
4202 when the property name for a non OS::Nova::Server resources is defined
4203 in a Heat Orchestration Template.
4205 This prevents the enumeration of a
4206 unique value for the property name in a per instance environment file.
4210 - In most cases, only the use of the metadata value vnf\_name is
4211 required to create a unique property name
4213 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4214 may also be used in the str\_replace construct to generate a unique
4215 name when the vnf\_name does not provide uniqueness
4217 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4219 .. code-block:: yaml
4223 type: OS::Neutron::SecurityGroup
4225 description: vDNS security group
4228 template: VNF_NAME_sec_grp_DNS
4230 VNF_NAME: {get_param: vnf_name}
4234 *Example: Property name for resource* OS::Cinder::Volume
4236 .. code-block:: yaml
4240 type: OS::Cinder::Volume
4242 description: Cinder Volume
4245 template: VNF_NAME_STACK_NAME_dns_volume
4247 VNF_NAME: {get_param: vnf_name}
4248 STACK_NAME: { get_param: 'OS::stack_name' }
4251 Contrail Issue with Values for the Property Name
4252 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4254 The Contrail GUI has a limitation displaying special characters. The
4255 issue is documented in
4256 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4257 recommended that special characters be avoided. However, if special
4258 characters must be used, note that for the following resources:
4272 the only special characters supported are:
4274 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4276 ONAP Output Parameter Names
4277 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4279 ONAP defines three types of Output Parameters as detailed in
4280 `Output Parameters`_.
4282 ONAP Base Module Output Parameters:
4283 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4285 ONAP Base Module Output Parameters do not have an explicit naming
4286 convention. The parameter name must contain {vm-type} and {network-role}
4289 ONAP Volume Template Output Parameters:
4290 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4292 ONAP Base Module Output Parameters do not have an explicit naming
4293 convention. The parameter name must contain {vm-type} when appropriate.
4295 Predefined Output Parameters
4296 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4298 ONAP currently defines one predefined output parameter the OAM
4299 Management IP Addresses.
4301 OAM Management IP Addresses
4302 +++++++++++++++++++++++++++++
4304 A VNF may have a management interface for application controllers to
4305 interact with and configure the VNF. Typically, this will be via a
4306 specific VM that performs a VNF administration function. The IP address
4307 of this interface must be captured and inventoried by ONAP. The IP
4308 address might be a VIP if the VNF contains an HA pair of management VMs,
4309 or may be a single IP address assigned to one VM.
4311 The Heat template may define either (or both) of the following Output
4312 parameters to identify the management IP address.
4314 - oam\_management\_v4\_address
4316 - oam\_management\_v6\_address
4320 - The use of this output parameters are optional.
4322 - The Management IP Address should be defined only once per VNF, so it
4323 must only appear in one Module template
4325 - If a fixed IP for the admin VM is passed as an input parameter, it
4326 may be echoed in the output parameters. In this case, a IPv4 and/or
4327 IPv6 parameter must be defined in the parameter section of the YAML
4328 Heat template. The parameter maybe named oam\_management\_v4\_address
4329 and/or oam\_management\_v6\_address or may be named differently.
4331 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4332 from the resource attributes. In this case,
4333 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4334 not be defined in the parameter section of the YAML Heat template.
4336 *Example: SDN-C Assigned IP Address echoed as*
4337 oam\_management\_v4\_address
4339 .. code-block:: yaml
4344 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4348 admin_oam_net_0_port:
4349 type: OS::Neutron::Port
4353 template: VNF_NAME_admin_oam_net_0_port
4355 VNF_NAME: {get_param: vnf_name}
4356 network: { get_param: oam_net_id }
4357 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4358 security_groups: [{ get_param: security_group }]
4361 type: OS::Nova::Server
4363 name: { get_param: admin_names }
4364 image: { get_param: admin_image_name }
4365 flavor: { get_param: admin_flavor_name }
4366 availability_zone: { get_param: availability_zone_0 }
4368 - port: { get_resource: admin_oam_net_0_port }
4370 vnf_id: { get_param: vnf_id }
4371 vf_module_id: { get_param: vf_module_id }
4372 vnf_name: {get_param: vnf_name }
4374 oam_management_v4_address:
4375 value: {get_param: admin_oam_ip_0 }
4377 *Example: Cloud Assigned IP Address output as*
4378 oam\_management\_v4\_address
4380 .. code-block:: yaml
4385 admin_oam_net_0_port:
4386 type: OS::Neutron::Port
4390 template: VNF_NAME_admin_oam_net_0_port
4392 VNF_NAME: {get_param: vnf_name}
4393 network: { get_param: oam_net_id }
4394 security_groups: [{ get_param: security_group }]
4397 type: OS::Nova::Server
4399 name: { get_param: admin_names }
4400 image: { get_param: admin_image_name }
4401 flavor: { get_param: admin_flavor_name }
4402 availability_zone: { get_param: availability_zone_0 }
4404 - port: { get_resource: admin_oam_net_0_port }
4406 vnf_id: { get_param: vnf_id }
4407 vf_module_id: { get_param: vf_module_id }
4408 vnf_name: {get_param: vnf_name }
4411 oam_management_v4_address:
4412 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4414 Contrail Resource Parameters
4415 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4417 ONAP requires the parameter names of certain Contrail Resources to
4418 follow specific naming conventions. This section provides these
4421 Contrail Network Parameters
4422 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4424 Contrail based resources may require references to a Contrail network
4425 using the network FQDN.
4430 When the parameter associated with the Contrail Network is referencing
4431 an “external” network, the parameter must adhere to the following naming
4432 convention in the Heat Orchestration Template
4434 - {network-role}\_net\_fqdn
4436 The parameter must be declared as type: string
4438 The parameter must not be enumerated in the Heat environment file.
4440 *Example: Parameter declaration*
4442 .. code-block:: yaml
4445 {network-role}_net_fqdn:
4447 description: Contrail FQDN for the {network-role} network
4449 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4450 Reference to a Network FQDN.*
4452 In this example, the {network-role} has been defined as oam to represent
4453 an oam network and the {vm-type} has been defined as fw for firewall.
4454 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4455 virtual\_network\_refs references a contrail network FQDN.
4457 .. code-block:: yaml
4460 type: OS::ContrailV2::VirtualMachineInterface
4464 template: VM_NAME_virtual_machine_interface_1
4466 VM_NAME: { get_param: fw_name_0 }
4467 virtual_machine_interface_properties:
4468 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4469 virtual_network_refs:
4470 - get_param: oam_net_fqdn
4471 security_group_refs:
4472 - get_param: fw_sec_grp_id
4474 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4475 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4477 The parameter associated with the resource
4478 OS::ContrailV2::InterfaceRouteTable property
4479 interface\_route\_table\_routes, map property
4480 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4483 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4484 in the Heat Orchestration Template.
4486 The parameter must be declared as type: json
4488 The parameter supports IP addresses in the format:
4490 1. Host IP Address (e.g., 10.10.10.10)
4492 2. CIDR Notation format (e.g., 10.0.0.0/28)
4494 The parameter must not be enumerated in the Heat environment file.
4496 *Example Parameter Definition*
4498 .. code-block:: yaml
4501 {vm-type}_{network-role}_route_prefixes:
4503 description: JSON list of Contrail Interface Route Table route prefixes
4507 .. code-block:: yaml
4512 description: Unique name for this VF instance
4513 fw_int_fw_route_prefixes:
4515 description: prefix for the ServiceInstance InterfaceRouteTable
4516 int_fw_dns_trusted_interface_type:
4518 description: service_interface_type for ServiceInstance
4521 type: OS::ContrailV2::InterfaceRouteTable
4522 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4526 template: VNF_NAME_interface_route_table
4528 VNF_NAME: { get_param: vnf_name }
4529 interface_route_table_routes:
4530 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4531 service_instance_refs:
4532 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4533 service_instance_refs_data:
4534 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4536 Parameter Names in Contrail Resources
4537 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4539 Contrail Heat resource properties will use, when appropriate, the same
4540 naming convention as OpenStack Heat resources. For example, the resource
4541 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4542 convention is identical to properties in OS::Neutron::Port.
4544 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4545 instance\_ip\_address*
4547 The property instance\_ip\_address uses the same parameter naming
4548 convention as the property fixed\_ips and Map Property ip\_address in
4549 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4550 Address. The {network-role} has been defined as oam\_protected to
4551 represent an oam protected network and the {vm-type} has been defined as
4554 .. code-block:: yaml
4556 CMD_FW_OAM_PROTECTED_RII:
4557 type: OS::ContrailV2::InstanceIp
4559 - FW_OAM_PROTECTED_RVMI
4561 virtual_machine_interface_refs:
4562 - get_resource: FW_OAM_PROTECTED_RVMI
4563 virtual_network_refs:
4564 - get_param: oam_protected_net_fqdn
4565 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4567 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4570 The property instance\_ip\_address uses the same parameter naming
4571 convention as the property fixed\_ips and Map Property subnet\_id in
4572 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4573 Address. The {network-role} has been defined as “oam\_protected” to
4574 represent an oam protected network and the {vm-type} has been defined as
4577 .. code-block:: yaml
4579 CMD_FW_SGI_PROTECTED_RII:
4580 type: OS::ContrailV2::InstanceIp
4582 - FW_OAM_PROTECTED_RVMI
4584 virtual_machine_interface_refs:
4585 - get_resource: FW_OAM_PROTECTED_RVMI
4586 virtual_network_refs:
4587 - get_param: oam_protected_net_fqdn
4588 subnet_uuid: { get_param: oam_protected_subnet_id }
4590 Cinder Volume Templates
4591 ^^^^^^^^^^^^^^^^^^^^^^^^
4593 ONAP supports the independent deployment of a Cinder volume via separate
4594 Heat Orchestration Templates, the Cinder Volume module. This allows the
4595 volume to persist after VNF deletion so that they can be reused on
4596 another instance (e.g., during a failover activity).
4598 A Base Module or Incremental Module may have a corresponding volume
4599 module. Use of separate volume modules is optional. A Cinder volume may
4600 be embedded within the Base Module or Incremental Module if persistence
4603 R-47788 The VNF Heat **MUST** have a 1:1 scope of a cinder volume module,
4604 when it exists, with the Base Module or Incremental Module
4606 A single volume module must create only the volumes
4607 required by a single Incremental module or Base module.
4609 The following rules apply to independent volume Heat templates:
4611 - Cinder volumes must be created in a separate Heat Orchestration
4612 Template from the Base Module or Incremental Module.
4614 - A single Cinder volume module must include all Cinder volumes
4615 needed by the Base/Incremental module.
4617 - R-79531 The VNF Heat **MUST** define “outputs” in the volume
4618 template for each Cinder volume resource universally unique
4619 identifier (UUID) (i.e. ONAP Volume Template Output Parameters).
4621 - The VNF Incremental Module or Base Module must define input
4622 parameters that match each Volume output parameter (i.e., ONAP Volume
4623 Template Output Parameters).
4625 - ONAP will supply the volume template outputs automatically to the
4626 bases/incremental template input parameters.
4628 - Volume modules may utilize nested Heat templates.
4630 *Examples: Volume Template*
4632 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4633 creates an independent Cinder volume for a VM in the module
4634 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4635 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4636 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4637 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4638 output statement and provides the value to the incremental module.
4640 Note that the example below is not a complete Heat Orchestration
4641 Template. The {vm-type} has been defined as “lb” for load balancer
4643 incremental\_volume.yaml
4645 .. code-block:: yaml
4656 type: OS::Cinder::Volume
4660 template: VNF_NAME_volume_0
4662 VNF_NAME: { get_param: vnf_name }
4663 size: {get_param: dns_volume_size_0}
4668 value: {get_resource: dns_volume_0}
4674 .. code-block:: yaml
4685 type: OS::Nova::Server
4687 name: {get_param: dns_name_0}
4692 type: OS::Cinder::VolumeAttachment
4694 instance_uuid: { get_resource: lb_0 }
4695 volume_id: { get_param: lb_volume_id_0 }
4697 ONAP Support of Environment Files
4698 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4700 The use of an environment file in OpenStack is optional. In ONAP, it is
4703 R-86285 The VNF Heat **MUST** have a
4704 corresponding environment file, even if no parameters are required to be
4707 (Note that ONAP, the open source version of ONAP, does not
4708 programmatically enforce the use of an environment file.)
4710 R-67205 The VNF Heat **MUST** have a corresponding
4711 environment file for a Base Module.
4713 R-35727 The VNF Heat **MUST** have a
4714 corresponding environment file for an Incremental module.
4716 R-22656 The VNF Heat **MUST** have a corresponding environment file
4717 for a Cinder Volume Module.
4719 A nested heat template must not have an environment file; OpenStack does
4722 The environment file must contain parameter values for the ONAP
4723 Orchestration Constants and VNF Orchestration Constants. These
4724 parameters are identical across all instances of a VNF type, and
4725 expected to change infrequently. The ONAP Orchestration Constants are
4726 associated with OS::Nova::Server image and flavor properties (See
4727 `Property: image`_ and `Property: flavor`_). Examples of VNF
4728 Orchestration Constants are the networking parameters associated
4729 with an internal network (e.g., private IP ranges) and Cinder
4732 The environment file must not contain parameter values for parameters
4733 that are instance specific (ONAP Orchestration Parameters, VNF
4734 Orchestration Parameters). These parameters are supplied to the Heat by
4735 ONAP at orchestration time.
4737 SDC Treatment of Environment Files
4738 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4740 Parameter values enumerated in the environment file are used by SDC as
4741 the default value. However, the SDC user may use the SDC GUI to
4742 overwrite the default values in the environment file.
4744 SDC generates a new environment file for distribution to MSO based on
4745 the uploaded environment file and the user provided GUI updates. The
4746 user uploaded environment file is discarded when the new file is
4747 created. Note that if the user did not change any values via GUI
4748 updates, the SDC generated environment file will contain the same values
4749 as the uploaded file.
4751 Use of Environment Files when using OpenStack “heat stack-create” CLI
4752 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4754 When ONAP is instantiating the Heat Orchestration Template, certain
4755 parameter must not be enumerated in the environment file. This document
4756 provides the details of what parameters should not be enumerated.
4758 If the Heat Orchestration Template is to be instantiated from the
4759 OpenStack Command Line Interface (CLI) using the command “heat
4760 stack-create”, all parameters must be enumerated in the environment
4763 Heat Template Constructs
4764 ^^^^^^^^^^^^^^^^^^^^^^^^^
4766 Nested Heat Templates
4767 ~~~~~~~~~~~~~~~~~~~~~~~
4769 ONAP supports nested Heat templates per the OpenStack specifications.
4770 Nested templates may be suitable for larger VNFs that contain many
4771 repeated instances of the same VM type(s). A common usage pattern is to
4772 create a nested template for each {vm-type} along with its supporting
4773 resources. The VNF module may then reference these component templates
4774 either statically by repeated definition or dynamically by using the
4775 resource OS::Heat::ResourceGroup.
4777 Nested Heat Template Requirements
4778 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4780 ONAP supports nested Heat Orchestration Templates. A Base Module,
4781 Incremental Module, and Cinder Volume Module may use nested heat.
4783 A Heat Orchestration Template may reference the nested heat statically
4784 by repeated definition.
4786 A Heat Orchestration Template may reference the nested heat dynamically
4787 using the resource OS::Heat::ResourceGroup.
4789 A Heat Orchestration template must have no more than three levels of
4790 nesting. ONAP supports a maximum of three levels.
4792 Nested heat templates must be referenced by file name. The use of
4793 resource\_registry in the environment file is not supported and must not
4796 R-89868 The VNF Heat **MUST** have unique file names within the scope
4797 of the VNF for a nested heat yaml file.
4799 R-52530 The VNF Heat **MUST NOT** use a directory hierarchy for
4800 nested templates. All templates must be in a single, flat directory
4803 A nested heat template may be used by any module within a given VNF.
4807 - Constrains must not be defined for any parameter enumerated in a
4808 nested heat template.
4810 - R-11041 The VNF Heat **MUST** have the resource calling the
4811 nested yaml file pass in as properties all parameters defined
4812 in nested yaml file.
4814 - R-61183 The VNF Heat **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
4817 - With nested templates, outputs are required to expose any resource
4818 properties of the child templates to the parent template. Those would
4819 not explicitly be declared as parameters but simply referenced as
4820 get\_attribute targets against the “parent” resource.
4822 Nested Heat Template Example: Static
4823 ++++++++++++++++++++++++++++++++++++++
4827 .. code-block:: yaml
4833 dns_image_name: { get_param: dns_image_name }
4834 dns_flavor_name: { get_param: dns_flavor_name }
4835 availability_zone: { get_param: availability_zone_0 }
4836 security_group: { get_param: DNS_shared_sec_grp_id }
4837 oam_net_id: { get_param: oam_protected_net_id }
4838 dns_oam_ip: { get_param: dns_oam_ip_0 }
4839 dns_name: { get_param: dns_name_0 }
4840 vnf_name: { get_param: vnf_name }
4841 vnf_id: { get_param: vnf_id }
4842 vf_module_id: {get_param: vf_module_id}
4847 dns_image_name: { get_param: dns_image_name }
4848 dns_flavor_name: { get_param: dns_flavor_name }
4849 availability_zone: { get_param: availability_zone_1 }
4850 security_group: { get_param: DNS_shared_sec_grp_id }
4851 oam_net_id: { get_param: oam_protected_net_id }
4852 dns_oam_ip: { get_param: dns_oam_ip_1 }
4853 dns_name: { get_param: dns_name_1 }
4854 vnf_name: { get_param: vnf_name }
4855 vnf_id: { get_param: vnf_id }
4856 vf_module_id: {get_param: vf_module_id}
4860 .. code-block:: yaml
4863 type: OS::Neutron::Port
4867 template: VNF_NAME_dns_oam_port
4869 VNF_NAME: {get_param: vnf_name}
4870 network: { get_param: oam_net_id }
4871 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4872 security_groups: [{ get_param: security_group }]
4875 type: OS::Nova::Server
4877 name: { get_param: dns_names }
4878 image: { get_param: dns_image_name }
4879 flavor: { get_param: dns_flavor_name }
4880 availability_zone: { get_param: availability_zone }
4882 - port: { get_resource: dns_oam_0_port }
4884 vnf_id: { get_param: vnf_id }
4885 vf_module_id: { get_param: vf_module_id }
4886 vnf_name {get_param: vnf_name }
4888 Use of Heat ResourceGroup
4889 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4891 The OS::Heat::ResourceGroup is a useful Heat element for creating
4892 multiple instances of a given resource or collection of resources.
4893 Typically, it is used with a nested Heat template, to create, for
4894 example, a set of identical OS::Nova::Server resources plus their
4895 related OS::Neutron::Port resources via a single resource in a master
4898 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4899 template that creates multiple instances of the same VM type.
4901 However, there are important caveats to be aware of:
4903 ResourceGroup does not deal with structured parameters
4904 (comma-delimited-list and json) as one might typically expect. In
4905 particular, when using a list-based parameter, where each list element
4906 corresponds to one instance of the ResourceGroup, it is not possible to
4907 use the intrinsic “loop variable” %index% in the ResourceGroup
4910 For instance, the following is **not** valid Heat for ResourceGroup:
4912 .. code-block:: yaml
4914 type: OS::Heat::ResourceGroup
4916 type: my_nested_vm_template.yaml
4918 name: {get_param: [vm_name_list, %index%]}
4920 Although this appears to use the nth entry of the vm\_name\_list list
4921 for the nth element of the ResourceGroup, it will in fact result in a
4922 Heat exception. When parameters are provided as a list (one for each
4923 element of a ResourceGroup), you must pass the complete parameter to the
4924 nested template along with the current index as separate parameters.
4926 Below is an example of an **acceptable** Heat Syntax for a
4929 .. code-block:: yaml
4931 type: OS::Heat::ResourceGroup
4933 type: my_nested_vm_template.yaml
4935 names: {get_param: vm_name_list}
4938 You can then reference within the nested template as:
4940 { get\_param: [names, {get\_param: index} ] }
4942 ResourceGroup Property count
4943 +++++++++++++++++++++++++++++
4945 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4946 (even if the value is one) and that the value must be enumerated in the
4947 environment file. This is required for ONAP to build the TOSCA model for
4950 .. code-block:: yaml
4952 type: OS::Heat::ResourceGroup
4954 count: { get_param: count }
4957 type: my_nested_vm_template.yaml
4959 names: {get_param: vm_name_list}
4962 Availability Zone and ResourceGroups
4963 +++++++++++++++++++++++++++++++++++++
4965 The resource OS::Heat::ResourceGroup and the property availability\_zone
4966 has been an “issue” with a few VNFs since ONAP only supports
4967 availability\_zone as a string parameter and not a
4968 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4969 to create Virtual Machines in more than one availability zone.
4971 There are numerous solutions to this issue. Below are two suggested
4974 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4975 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4976 availability\_zones by using the intrinsic function list\_join.
4978 .. code-block:: yaml
4981 type: OS::Heat::ResourceGroup
4983 count: { get_param: node_count }
4989 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4993 .. code-block:: yaml
4996 avaialability_zones:
4997 type: comma_delimited_list
5002 type: OS::Nova::Server
5004 name: { get_param: [ dns_names, get_param: index ] }
5005 image: { get_param: dns_image_name }
5006 flavor: { get_param: dns_flavor_name }
5007 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
5010 **Option 2:** Create a resource group per availability zone. A separate
5011 OS::Heat::ResourceGroup is created for each availability zone.
5014 ^^^^^^^^^^^^^^^^^^^^
5016 Heat templates *should not* reference any HTTP-based resource
5017 definitions, any HTTP-based nested configurations, or any HTTP-based
5020 - During orchestration, ONAP *should not* retrieve any such resources
5021 from external/untrusted/unknown sources.
5023 - VNF images should not contain such references in user-data or other
5024 configuration/operational scripts that are specified via Heat or
5025 encoded into the VNF image itself.
5027 *Note:* HTTP-based references are acceptable if the HTTP-based reference
5028 is accessing information with the VM private/internal network.
5030 Heat Files Support (get\_file)
5031 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5033 Heat Templates may contain the inclusion of text files into Heat
5034 templates via the Heat get\_file directive. This may be used, for
5035 example, to define a common “user-data” script, or to inject files into
5036 a VM on startup via the “personality” property.
5038 Support for Heat Files is subject to the following limitations:
5040 R-76718 The VNF Heat **MUST** reference the get\_files targets in
5041 Heat templates by file name, and the corresponding files should be
5042 delivered to ONAP along with the Heat templates.
5044 R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
5046 R-62177 The VNF Heat **MUST** have unique file names for the included
5047 files within the scope of the VNF.
5049 R-87848 The VNF Heat **MUST** have all included files in a single, flat
5050 directory per VNF. ONAP does not support a directory hierarchy.
5052 - Included files may be used by all Modules within a given VNF.
5054 - get\_file directives may be used in both non-nested and nested
5060 When Nova Servers are created via Heat templates, they may be passed a
5061 “keypair” which provides an ssh key to the ‘root’ login on the newly
5062 created VM. This is often done so that an initial root key/password does
5063 not need to be hard-coded into the image.
5065 Key pairs are unusual in OpenStack, because they are the one resource
5066 that is owned by an OpenStack User as opposed to being owned by an
5067 OpenStack Tenant. As a result, they are usable only by the User that
5068 created the keypair. This causes a problem when a Heat template attempts
5069 to reference a keypair by name, because it assumes that the keypair was
5070 previously created by a specific ONAP user ID.
5072 When a keypair is assigned to a server, the SSH public-key is
5073 provisioned on the VMs at instantiation time. They keypair itself is not
5074 referenced further by the VM (i.e. if the keypair is updated with a new
5075 public key, it would only apply to subsequent VMs created with that
5078 Due to this behavior, the recommended usage of keypairs is in a more
5079 generic manner which does not require the pre-requisite creation of a
5080 keypair. The Heat should be structured in such a way as to:
5082 - Pass a public key as a parameter value instead of a keypair name
5084 - Create a new keypair within the VNF Heat templates (in the base
5085 module) for use within that VNF
5087 By following this approach, the end result is the same as pre-creating
5088 the keypair using the public key – i.e., that public key will be
5089 provisioned in the new VM. However, this recommended approach also makes
5090 sure that a known public key is supplied (instead of having OpenStack
5091 generate a public/private pair to be saved and tracked outside of ONAP).
5092 It also removes any access/ownership issues over the created keypair.
5094 The public keys may be enumerated as a VNF Orchestration Constant in the
5095 environment file (since it is public, it is not a secret key), or passed
5096 at run-time as instance-specific parameters. ONAP will never
5097 automatically assign a public/private key pair.
5099 *Example (create keypair with an existing ssh public-key for {vm-type}
5100 of lb (for load balancer)):*
5102 .. code-block:: yaml
5112 type: OS::Nova::Keypair
5116 template: VNF_NAME_key_pair
5118 VNF_NAME: { get_param: vnf_name }
5119 public_key: {get_param: lb_ssh_public_key}
5120 save_private_key: false
5125 OpenStack allows a tenant to create Security groups and define rules
5126 within the security groups.
5128 Security groups, with their rules, may either be created in the Heat
5129 Orchestration Template or they can be pre-created in OpenStack and
5130 referenced within the Heat template via parameter(s). There can be a
5131 different approach for security groups assigned to ports on internal
5132 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
5133 there can be a common security group across all VMs for a specific
5134 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
5137 Anti-Affinity and Affinity Rules
5138 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5140 Anti-affinity or affinity rules are supported using normal OpenStack
5141 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
5142 created for each VM type to prevent them from residing on the same host,
5143 but they can be applied to multiple VM types to extend the
5144 affinity/anti-affinity across related VM types as well.
5148 In this example, the {network-role} has been defined as oam to represent
5149 an oam network and the {vm-type} have been defined as lb for load
5150 balancer and db for database.
5152 .. code-block:: yaml
5156 type: OS::Nova::ServerGroup
5161 $vnf_name: {get_param: vnf_name}
5162 template: $vnf_name-server_group1
5167 type: OS::Nova::ServerGroup
5172 $vnf_name: {get_param: vnf_name}
5173 template: $vnf_name-server_group2
5178 type: OS::Nova::Server
5182 group: {get_resource: db_server_group}
5185 type: OS::Nova::Server
5189 group: {get_resource: db_server_group}
5192 type: OS::Nova::Server
5196 group: {get_resource: lb_server_group}
5198 Resource Data Synchronization
5199 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5201 For cases where synchronization is required in the orchestration of Heat
5202 resources, two approaches are recommended:
5204 - Standard Heat depends\_on property for resources
5206 - Assures that one resource completes before the dependent resource
5209 - Definition of completeness to OpenStack may not be sufficient
5210 (e.g., a VM is considered complete by OpenStack when it is ready
5211 to be booted, not when the application is up and running).
5213 - Use of Heat Notifications
5215 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5218 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5220 - Dependent resource define depends\_on in the
5221 OS::Heat::WaitCondition resource.
5223 *Example: “depends\_on” case*
5225 In this example, the {network-role} has been defined as oam to represent
5226 an oam network and the {vm-type} has been defined as oam to represent an
5229 .. code-block:: yaml
5233 type: OS::Nova::Server
5235 name: {get_param: [oam_ names, 0]}
5236 image: {get_param: oam_image_name}
5237 flavor: {get_param: oam_flavor_name}
5238 availability_zone: {get_param: availability_zone_0}
5240 - port: {get_resource: oam01_port_0}
5241 - port: {get_resource: oam01_port_1}
5243 scheduler_hints: {group: {get_resource: oam_servergroup}}
5244 user_data_format: RAW
5247 type: OS::Neutron::Port
5249 network: {get_resource: oam_net_name}
5250 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5251 security_groups: [{get_resource: oam_security_group}]
5254 type: OS::Neutron::Port
5256 network: {get_param: oam_net_name}
5257 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5258 security_groups: [{get_resource: oam_security_group}]
5260 oam_01_vol_attachment:
5261 type: OS::Cinder::VolumeAttachment
5262 depends_on: oam_server_01
5264 volume_id: {get_param: oam_vol_1}
5265 mountpoint: /dev/vdb
5266 instance_uuid: {get_resource: oam_server_01}
5269 ^^^^^^^^^^^^^^^^^^^^
5271 VNF/VM parameters may include availability zone IDs for VNFs that
5272 require high availability.
5274 The Heat must comply with the following requirements to specific
5275 availability zone IDs:
5277 - The Heat template should spread Nova and Cinder resources across the
5278 availability zones as desired
5280 Post Orchestration & VNF Configuration
5281 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5283 Heat templates should contain a minimum amount of post-orchestration
5284 configuration data. For instance, *do not* embed complex user-data
5285 scripts in the template with large numbers of configuration parameters
5286 to the Heat template.
5288 - VNFs may provide configuration APIs for use after VNF creation. Such
5289 APIs will be invoked via application and/or SDN controllers.
5291 *Note:* It is important to follow this convention to the extent possible
5292 even in the short-term as of the long-term direction.
5294 VNFM Driver Development Steps
5295 -----------------------------------------------------------
5297 Refer to the ONAP documentation for VNF Provider instructions on integrating
5298 vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
5301 1. Use the VNF SDK tools to design the VNF with TOSCA models to output
5302 the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
5303 validated and tested.
5305 2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
5306 is a microservice providing a translation interface from VF-C to
5307 the vendor-specific VNFM. The interface definitions of vendor-specific
5308 VNFM adaptors are supplied by the VNF Providers themselves.
5310 Creating Vendor-Specific VNFM Adaptor Microservices
5311 ------------------------------------------------------------------------------------------------
5313 VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific
5314 VNFM to ONAP, a vendor-specific VNFM adaptor is added to ONAP implementing
5315 the interface of the vendor-specific VNFM.
5317 A vendor-specific VNFM adaptor is a microservice with a unique name and
5318 an appointed port. When started up, the vendor-specific VNFM adaptor
5319 microservice is automatically registered to the Microservices Bus (MSB).
5320 The following RESTful example describes the scenario of registering a
5321 vendor-specific VNFM adaptor to MSB:
5323 .. code-block:: java
5325 POST /api/microservices/v1/services
5327 "serviceName": "catalog",
5329 "url": "/api/catalog/v1",
5334 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob