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 HPA 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
1623 This section contains general Heat Orchestration Template guidelines.
1628 R-95303 The VNF Heat Orchestration Template **MUST** be defined using valid YAML.
1631 Markup Language) is a human friendly data serialization standard for all
1632 programming languages. See http://www.yaml.org/.
1634 Heat Orchestration Template Format
1635 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1637 As stated above, Heat Orchestration templates must be defined in YAML.
1641 - Tabs are not allowed, use spaces ONLY
1643 - You must indent your properties and lists with 1 or more spaces
1645 - All Resource IDs and resource property parameters are case-sensitive. (e.g., "ThIs", is not the same as "thiS")
1647 Heat Orchestration Template Structure
1648 +++++++++++++++++++++++++++++++++++++
1650 Heat Orchestration template structure follows the following format, as defined by OpenStack at https://docs.openstack.org/developer/heat/template_guide/hot_spec.html
1652 .. code-block:: python
1654 heat_template_version: <date>
1657 # a description of the template
1660 # a declaration of input parameter groups and order
1663 # declaration of input parameters
1666 # declaration of template resources
1669 # declaration of output parameters
1672 # declaration of conditions
1674 The VNF Heat Orchestration template must contain the following sections:
1676 - "heat_template_version:".
1681 A VNF Heat Orchestration template may contain the section "parameter_groups:."
1683 A VNF Heat Orchestration template may contain the section "outputs:."
1685 heat_template_version
1686 _____________________
1688 R-27078 The VNF Heat Orchestration template **MUST** contain the section "heat_template_version:".
1690 The section "heat_template_version:" must be set to a date that is supported by the OpenStack environment.
1695 R-39402 The VNF Heat Orchestration Template **MUST** contain the section "description:".
1700 A VNF Heat Orchestration template may contain the section "parameter_groups:".
1705 R-35414 The VNF Heat Orchestration template **MUST** contain the section "parameters:".
1707 This section allows for
1708 specifying input parameters that have to be provided when instantiating
1709 the template. Each parameter is specified in a separate nested block
1710 with the name of the parameters defined in the first line and additional
1711 attributes (e.g., type, label) defined as nested elements.
1713 R-90279 The VNF Heat Orchestration Template must use all declared parameters in a resource with the exception of the parameters for the OS::Nova::Server resource property availability_zone.
1715 .. code-block:: python
1721 type: <string | number | json | comma_delimited_list | boolean>
1723 label: <human-readable name of the parameter>
1725 description: <description of the parameter>
1727 default: <default value for parameter>
1729 hidden: <true | false>
1733 <parameter constraints>
1735 immutable: <true | false>
1741 The name of the parameter.
1743 R-25877 The VNF Heat Orchestration Template parameter name **MUST** contain only alphanumeric characters and underscores ('_').
1748 The parameter attribute "type:" is an OpenStack mandatory and can have a value of "string", "number", "json", "comma_delimited_list" or boolean.
1753 The parameter attribute "label:" is an OpenStack optional attribute that provides a human readable name for the parameter.
1755 A VNF Heat Orchestration Template parameter declaration may contain the attribute "label".
1760 The parameter attribute "description:" is an OpenStack optional attribute that provides a description of the parameter.
1762 R-44001 The VNF Heat Orchestration Template parameter declaration **MUST** contain the "description" attribute.
1767 The parameter attribute "default:" is an OpenStack optional attribute that defines the default value for the parameter.
1769 R-90526 The VNF Heat Orchestration Template parameter declaration **MUST NOT** contain the default attribute.
1771 R-26124 If The VNF Heat Orchestration Template parameter has a default value, it **MUST** be enumerated in the environment file.
1776 The parameter attribute "hidden:" is an OpenStack optional attribute that defines whether the parameters should be hidden when a user requests information about a stack created from the template. This attribute can be used to hide passwords specified as parameters.
1781 The parameter attribute "constraints:" is an OpenStack optional attribute that defines a list of constraints to apply to the parameter.
1783 The constraints block of a parameter definition defines additional validation constraints that apply to the value of the parameter. The parameter values provided in the VNF Heat Orchestration Template are validated against the constraints at instantiation time. The stack creation fails if the parameter value doesn’t comply to the constraints.
1785 The constraints are defined as a list with the following syntax
1787 .. code-block:: python
1791 <constraint type>: <constraint definition>
1793 description: <constraint description>
1797 *<constraint type>* Provides the type of constraint to apply. The list of OpenStack supported constraints can be found at https://docs.openstack.org/heat/latest/template_guide/hot_spec.html .
1799 *<constraint definition>* provides the actual constraint. The syntax and constraint is dependent of the <constraint type> used.
1801 *description* is an optional attribute that provides a description of the constraint. The text is presented to the user when the value the user defines violates the constraint. If omitted, a default validation message is presented to the user.
1803 R-88863 If a parameter type is declared as a "number", The VNF Heat Orchestration Template **MUST** declare a parameter constraint of "range" or "allowed_values" for that parameter.
1805 When a VNF Heat Orchestration Template parameter type is declared as a type other than \"number\", a parameter constraint may be defined. However, some VNF Heat Orchestration Template parameters must never have constraints defined. See Section 5 for the use cases where these exceptions exist.
1807 R-00011 The VNF Heat Orchestration Template **MUST NOT** have a constraints defined for parameters defined in VNF Heat Orchestration Template Nested YAML.
1811 range: The range constraint applies to parameters of type: number. It defines a lower and upper limit for the numeric value of the parameter. The syntax of the range constraint is
1813 .. code-block:: python
1815 range: { min: <lower limit>, max: <upper limit> }
1819 It is possible to define a range constraint with only a lower limit or an upper limit.
1823 allowed_values: The allowed_values constraint applies to parameters of type \"string\" or type \"number\". It specifies a set of possible values for a parameter. At deployment time, the user-provided value for the respective parameter must match one of the elements of the list. The syntax of the allowed_values constraint is
1825 .. code-block:: python
1827 allowed_values: [ <value>, <value>, ... ]
1829 Alternatively, the following YAML list notation can be used
1844 The parameter attribute \"immutable:\" is an OpenStack optional attribute that defines whether the parameter is updatable. A Heat Orchestration Template stack update fails if immutable is set to true and the parameter value is changed. This attribute \"immutable:\" defaults to false.
1849 R-23664 The VNF Heat Orchestration template **MUST** contain the section "resources:".
1851 R-90152 The VNF Heat Orchestration Template section "resources:" **MUST** contain the declaration of at least one resource.
1853 A VNF Heat Orchestration Template Nested YAML file may \(or may not\) contain the section "\resources:\".
1855 Each resource is defined as a
1856 separate block in the resources section with the following syntax.
1858 .. code-block:: python
1864 type: <resource type>
1868 <property name>: <property value>
1872 <resource specific metadata>
1874 depends_on: <resource ID or list of ID>
1876 update_policy: <update policy>
1878 deletion_policy: <deletion policy>
1880 external_id: <external resource ID>
1882 condition: <condition name or expression or boolean>
1889 R-16447 The VNF Heat Orchestration Template <resource ID>s **MUST** be unique across all VNF Heat Orchestration Templates and all VNF HEAT Orchestration Template Nested YAML files that are used to create the VNF.
1891 Note that a VNF can be composed of one or more Heat Orchestration Templates. For additional details, see Section 3.1.
1893 Note that OpenStack requires the <resource ID> to be unique to the Heat Orchestration Template and not unique across all Heat Orchestration Templates the compose the VNF.
1895 R-75141 The VNF Heat Orchestration Template <resource ID>s **MUST** contain only alphanumeric characters and underscores ('_').
1897 The detailed naming convention for the <resource ID> is provided in Section 5.3.
1902 The resource attribute \"type:\" is an OpenStack required attribute that defines the resource type, such as OS::Nova::Server or OS::Neutron::Port. Note that the type may specify a VNF HEAT Orchestration Template Nested YAML file.
1908 The resource attribute \"properties:\" is an OpenStack optional attribute that provides a list of resource-specific properties. The property value can be provided in place, or via a function (e.g., `Intrinsic functions <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-intrinsic-functions>`__).
1910 R-10834 If the VNF Heat Orchestration Template resource attribute "property:" uses a nested "get_param", one level is nesting is supported and the nested "get_param" **MUST** reference an index
1912 The naming convention for specific resource property parameters is provided in Section 5.
1917 The resource attribute \"metadata:\" is an OpenStack optional attribute.
1919 R-97199 The VNF Heat Orchestration Template OS::Nova::Server resource **MUST** contain the attribute metadata.
1921 Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
1927 The resource attribute \"depends_on:\" is an OpenStack optional attribute. See `Section <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-resources-dependencies>`__ 9.7 for additional details. A resource in a VNF HEAT Orchestration Template may contain the attribute \"depends_on:\".
1932 The resource attribute \"update_policy:\" is an OpenStack optional attribute. A resource in a VNF HEAT Orchestration Template may contain the attribute \"update_policy:\".
1937 The resource attribute \"deletion_policy:\" is an OpenStack optional attribute. A resource in a VNF HEAT Orchestration Template may contain the attribute \"deletion_policy:\".
1939 If specified, the \"deletion_policy:\" attribute for resources allows values 'Delete', 'Retain', and 'Snapshot'. Starting with heat_template_version 2016-10-14, lowercase equivalents are also allowed.
1941 The default policy is to delete the physical resource when deleting a resource from the stack.
1946 The resource attribute \"external_id:\" is an OpenStack optional attribute. A resource in a VNF HEAT Orchestration Template may contain the attribute \"external_id:\".
1948 This attribute allows for specifying the resource_id for an existing external (to the stack) resource. External resources cannot depend on other resources, but we allow other resources to depend on external resource. This attribute is optional. Note: when this is specified, properties will not be used for building the resource and the resource is not managed by Heat. This is not possible to update that attribute. Also, resource won’t be deleted by heat when stack is deleted.
1954 The resource attribute \"condition:\" is an OpenStack optional attribute.
1959 A VNF Heat Orchestration template may contain the section \"outputs:\".
1961 This section allows for specifying output parameters
1962 available to users once the template has been instantiated. If the
1963 section is specified, it will need to adhere to specific requirements.
1964 See `ONAP Parameter Classifications Overview`_ and
1965 `ONAP Output Parameter Names`_ for additional details.
1967 Environment File Format
1968 ^^^^^^^^^^^^^^^^^^^^^^^^
1970 The environment file is a yaml text file.
1971 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1973 The environment file can contain the following sections:
1975 - parameters: A list of key/value pairs.
1977 - resource\_registry: Definition of custom resources.
1979 - parameter\_defaults: Default parameters passed to all template
1982 - encrypted\_parameters: List of encrypted parameters.
1984 - event\_sinks: List of endpoints that would receive stack events.
1986 - parameter\_merge\_strategies: Merge strategies for merging parameters
1987 and parameter defaults from the environment file.
1989 R-03324 The VNF Heat Orchestration Template **MUST** contain the "parameters" section in the
1992 Environment files for ONAP may contain the following sections:
1994 - resource\_registry:
1996 - parameter\_defaults:
1998 - encrypted\_parameters:
2002 - parameter\_merge\_strategies:
2004 The use of an environment file in OpenStack is optional. In ONAP, it is
2005 mandatory. A Heat Orchestration Template uploaded to ONAP must have a
2006 corresponding environment file, even if no parameters are enumerated in
2007 the mandatory parameter section.
2009 (Note that ONAP, the open source version of ONAP, does not
2010 programmatically enforce the use of an environment file.)
2012 SDC Treatment of Environment Files
2013 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2015 Parameter values enumerated in the environment file are used by SDC as
2016 the default value. However, the SDC user may use the SDC GUI to
2017 overwrite the default values in the environment file.
2019 SDC generates a new environment file for distribution to MSO based on
2020 the uploaded environment file and the user provided GUI updates. The
2021 user uploaded environment file is discarded when the new file is
2024 ONAP has requirements for what parameters must be enumerated in the
2025 environment file and what parameter must not be enumerated in the
2026 environment file. See `ONAP Parameter Classifications Overview`_ and
2027 `ONAP Resource ID and Parameter Naming Convention`_ for more details.
2029 Nested Heat Orchestration Templates Overview
2030 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2032 ONAP supports nested Heat Orchestration Templates per OpenStack
2035 A Base Module may utilize nested templates.
2037 An Incremental Module may utilize nested templates.
2039 A Cinder Volume Module may utilize nested templates.
2041 A nested template must not define parameter constraints in the parameter
2044 Nested templates may be suitable for larger VNFs that contain many
2045 repeated instances of the same VM type(s). A common usage pattern is to
2046 create a nested template for each VM type along with its supporting
2047 resources. The Heat Orchestration Template may then reference these
2048 nested templates either statically (by repeated definition) or
2049 dynamically (via OS::Heat::ResourceGroup).
2051 See `Nested Heat Templates`_ for additional details.
2053 ONAP Heat Orchestration Template Filenames
2054 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2056 In order to enable ONAP to understand the relationship between Heat
2057 files, the following Heat file naming convention must be utilized.
2059 In the examples below, <text> represents any alphanumeric string that
2060 must not contain any special characters and must not contain the word
2066 R-19473 The VNF Heat Orchestration Template **MUST** include “base” in the filename for the
2069 R-81339 The VNF Heat Orchestration Template **MUST** match one of the following options for
2070 the base module file name:
2072 - base\_<text>.y[a]ml
2074 - <text>\_base.y[a]ml
2078 - <text>\_base\_<text>.y[a]ml
2080 R-91342 The VNF Heat Orchestration Template **MUST** name the base module’s corresponding
2081 environment file to be identical to the base module with “.y[a]ml”
2082 replaced with “.env”.
2085 ~~~~~~~~~~~~~~~~~~~~~
2087 There is no explicit naming convention for the incremental modules.
2088 As noted above, <text> represents any alphanumeric string.
2090 R-87247 The VNF Heat Orchestration Template **MUST NOT** use any special characters or the
2091 word “base” in the name of the incremental module.
2095 R-94509 The VNF Heat Orchestration Template **MUST** name the incremental module’s
2096 corresponding environment file to be identical to the incremental
2097 module with “.y[a]ml” replaced with “.env”.
2099 To clearly identify the incremental module, it is recommended to use the
2100 following naming options for modules:
2102 - module\_<text>.y[a]ml
2104 - <text>\_module.y[a]ml
2108 Cinder Volume Modules
2109 ~~~~~~~~~~~~~~~~~~~~~~~
2111 R-82732 The VNF Heat Orchestration Template **MUST** name the Cinder volume module file name
2112 to be the same as the corresponding module it is supporting (base
2113 module or incremental module) with “\_volume” appended.
2115 - <base module name>\_volume.y[a]ml
2117 - <incremental module name>\_volume.y[a]ml
2119 R-31141 The VNF Heat Orchestration Template **MUST** name the volume module’s corresponding
2120 environment file to be identical to the volume module with “.y[a]ml”
2121 replaced with “.env”.
2126 There is no explicit naming convention for nested Heat files with the
2127 following exceptions; the name should contain “nest”.
2129 R-76057 The VNF Heat Orchestration Template **MUST NOT** use special characters
2130 or the word “base” in the file name for the nested template.
2132 As noted above, <text> represents any alphanumeric string.
2136 Nested Heat files do not have corresponding environment files, per
2137 OpenStack specifications.
2139 R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties all parameter values
2140 associated with the nested heat file in the resource definition defined
2141 in the parent heat template.
2143 ONAP Parameter Classifications Overview
2144 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2146 In order for ONAP to support workflow automation, Heat Orchestration
2147 Template resource property parameters must adhere to specific naming
2148 conventions and requirements.
2150 Broadly, ONAP categorizes parameters into four categories:
2152 1. ONAP metadata parameters
2154 2. Instance specific parameters
2156 3. Constant parameters
2158 4. Output parameters.
2160 ONAP Metadata Parameters
2161 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2163 There are both mandatory and optional ONAP metadata parameters
2164 associated with the resource OS::Nova::Server.
2166 - ONAP metadata parameters must not have parameter constraints defined.
2168 - Both mandatory and optional (if specified) ONAP metadata parameter
2169 names must follow the ONAP metadata parameter naming convention.
2171 `Resource: OS::Nova::Server – Metadata Parameters`_ provides more details on
2172 the metadata parameters.
2174 Instance specific parameters
2175 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2177 The instance specific parameters are VNF instance specific. The value of
2178 the parameter will be different for every instance of a VNF (e.g., IP
2179 address). The instance specific parameters are subdivided into two
2180 categories: **ONAP Orchestration Parameters** and **VNF Orchestration
2183 ONAP Orchestration Parameters
2184 +++++++++++++++++++++++++++++++
2186 ONAP Orchestration Parameters are per instance parameters where the
2187 value is assigned via ONAP automation. (Note that in some cases,
2188 automation is currently not available and the value is loaded into ONAP
2189 prior to instantiation.)
2191 - ONAP orchestration parameters must not be enumerated in the
2194 - When the ONAP orchestration parameter type is set to number, the
2195 parameter must have constraints for range and/or allowed\_values.
2197 - Parameter constraints for ONAP orchestration parameters are optional
2198 for all parameter types other than number. If constraints are
2199 specified, they must adhere to the OpenStack specifications.
2201 - The ONAP orchestration parameter names must follow the ONAP
2202 orchestration parameter naming convention.
2203 `ONAP Resource ID and Parameter Naming Convention`_
2204 provides additional details.
2206 VNF Orchestration Parameters
2207 +++++++++++++++++++++++++++++
2209 VNF Orchestration Parameters are per instance parameters where the
2210 values are assigned manually. They are not supported by ONAP automation.
2211 The per instance values are loaded into ONAP prior to VNF instantiation.
2213 - VNF orchestration parameters must not be enumerated in the
2216 - When the VNF orchestration parameter type is set to number, the
2217 parameter must have constraints for range or allowed\_values.
2219 - Parameter constraints for VNF orchestration parameters are optional
2220 for all parameter types other than number. If constraints are
2221 specified, they must adhere to the OpenStack specifications.
2223 - The VNF orchestration parameter names should follow the VNF
2224 orchestration parameter naming convention.
2225 `ONAP Resource ID and Parameter Naming Convention`_
2226 provides additional details.
2229 ~~~~~~~~~~~~~~~~~~~~~
2231 The constant parameters are parameters that remain constant across many
2232 VNF instances (e.g., image, flavor). The constant parameters are
2233 subdivided into two categories: **ONAP Constant Parameters** and
2234 **VNF Constant Parameters.**
2236 ONAP Constant Parameters
2237 ++++++++++++++++++++++++++
2239 - ONAP Constant Parameters must be enumerated in the environment file.
2240 These parameter values are not assigned by ONAP.
2242 - When the ONAP Constant Parameter type is set to number, the parameter
2243 must have constraints for range and/or allowed\_values.
2245 - Parameter constraints for ONAP constant parameters are optional for
2246 all parameter types other than number. If constraints are specified,
2247 they must adhere to the OpenStack specifications.
2249 - The ONAP Constant Parameter names must follow the ONAP orchestration
2250 parameter naming convention.
2251 `ONAP Resource ID and Parameter Naming Convention`_
2252 provides additional details.
2254 VNF Constant Parameters
2255 ++++++++++++++++++++++++
2257 - VNF Constant Parameters must be enumerated in the environment file.
2258 These parameter values are not assigned by ONAP.
2260 - When the VNF Constant Parameters type is set to number, the parameter
2261 must have constraints for range and/or allowed\_values.
2263 - Parameter constraints for ONAP constant parameters are optional for
2264 all parameter types other than number. If constraints are specified,
2265 they must adhere to the OpenStack specifications.
2267 - The VNF Constant Parameters names should follow the ONAP
2268 orchestration parameter naming convention.
2269 `ONAP Resource ID and Parameter Naming Convention`_
2270 provides additional details.
2275 The output parameters are parameters defined in the output section of a
2276 Heat Orchestration Template. The ONAP output parameters are subdivided
2277 into three categories:
2279 1. ONAP Base Module Output Parameters
2281 2. ONAP Volume Module Output Parameters
2283 3. ONAP Predefined Output Parameters.
2285 ONAP Base Module Output Parameters
2286 ++++++++++++++++++++++++++++++++++++
2288 ONAP Base Module Output Parameters are declared in the outputs: section
2289 of the base module Heat Orchestration Template. A Base Module Output
2290 Parameter is available as an input parameter (i.e., declared in the
2291 “parameters:” section) to all incremental modules in the VNF.
2293 - A Base Module Output Parameter may be used as an input parameter in
2294 an incremental module.
2296 - The Output parameter name and type must match the input parameter
2297 name and type unless the Output parameter is of the type
2298 comma\_delimited\_list.
2300 - If the Output parameter has a comma\_delimited\_list value (e.g.,
2301 a collection of UUIDs from a Resource Group), then the
2302 corresponding input parameter must be declared as type json and
2303 not a comma\_delimited\_list, which is actually a string value
2304 with embedded commas.
2306 - When a Base Module Output Parameter is declared as an input parameter
2307 in an incremental module Heat Orchestration Template, parameter
2308 constraints must not be declared.
2310 Additional details on ONAP Base Module Output Parameters are provided in
2311 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
2313 ONAP Volume Module Output Parameters
2314 ++++++++++++++++++++++++++++++++++++++
2316 The volume template output parameters are only available for the module
2317 (base or add on) that the volume is associated with.
2319 - ONAP Volume Module Output Parameters are declared in the “outputs:”
2320 section of the Cinder volume module Heat Orchestration Template
2322 - An ONAP Volume Module Output Parameter is available as an input
2323 parameter (i.e., declared in the parameters: section) only for the
2324 module (base or incremental) that the Cinder volume module is
2327 - R-07443 The VNF Heat Orchestration Template **MUST** match the Output parameter name and type with
2328 the input parameter name and type unless the Output parameter is of the
2329 type comma\_delimited\_list.
2331 - If the Output parameter has a comma\_delimited\_list value (e.g., a
2332 collection of UUIDs from a Resource Group), then the corresponding
2333 input parameter must be declared as type json and not a
2334 comma\_delimited\_list, which is actually a string value with
2337 - When an ONAP Volume Module Output Parameter is declared as an input
2338 parameter in a base module or incremental module, parameter
2339 constraints must not be declared.
2341 Additional details on ONAP Base Module Output Parameters are provided in
2342 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
2344 ONAP Predefined Output Parameters
2345 +++++++++++++++++++++++++++++++++++
2347 ONAP will look for a small set of pre-defined Heat output parameters to
2348 capture resource attributes for inventory in ONAP. These output
2349 parameters are optional and are specified in `OAM Management IP Addresses`_.
2351 Support of heat stack update
2352 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2354 VNF Heat Orchestration Templates must not be designed to utilize the
2355 OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
2356 does not support the use of heat stack-update command for scaling.
2358 It is important to note that ONAP only supports heat stack-update for
2364 ONAP defines two types of networks: External Networks and Internal
2367 ONAP defines an external network in relation to the VNF and not with
2368 regard to the Network Cloud site. External networks may also be referred
2369 to as “inter-VNF” networks. An external network connects VMs in a VNF to
2371 - VMs in another VNF or
2373 - an external gateway or router
2375 ONAP defines an internal network in relation to the VNF and not with
2376 regard to the Network Cloud site. Internal networks may also be referred
2377 to as “intra-VNF” networks or “private” networks. An internal network
2378 only connects VMs in a single VNF. It must not connect to other VNFs or
2379 an external gateway or router.
2384 VNF Heat Orchestration Templates must not include any resources for
2385 external networks connected to the VNF. External networks must be
2386 orchestrated separately, as independent, stand-alone VNF Heat
2387 Orchestration Templates, so they can be shared by multiple VNFs and
2388 managed independently.
2390 When the external network is created, it must be assigned a unique
2391 {network-role}. The {network-role} should describe the network (e.g.,
2392 oam). The {network-role} while unique to the LCP, can repeat across
2395 An External Network may be a Neutron Network or a Contrail Network
2397 R-23983 The VNF **MUST** pass the external networks into The VNF Heat Orchestration Template
2398 Orchestration Templates as parameters.
2400 - Neutron Network-id (UUID)
2402 - Neutron Network subnet ID (UUID)
2404 - Contrail Network Fully Qualified Domain Name (FQDN)
2406 ONAP enforces a naming convention for parameters associated with
2407 external networks. `ONAP Resource ID and Parameter Naming Convention`_
2408 provides additional details.
2410 Parameter values associated with an external network will be generated
2411 and/or assigned by ONAP at orchestration time. Parameter values
2412 associated with an external network must not be enumerated in the
2413 environment file. `ONAP Resource ID and Parameter Naming Convention`_
2414 provides additional details.
2416 VNFs may use **Cloud assigned IP addresses** or
2417 **ONAP SDN-C assigned IP addresses**
2418 when attaching VMs to an external network
2420 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2422 - An ONAP SDN-C assigned IP address is assigned by the ONAP SDN-C
2425 - Note that Neutron Floating IPs must not be used. ONAP does not
2426 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2428 - ONAP supports the property allowed\_address\_pairs in the resource
2429 OS::Neutron:Port and the property
2430 virtual\_machine\_interface\_allowed\_address\_pairs in
2431 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2432 of a virtual IP (VIP) address to a set of VMs.
2434 R-63345 The VNF Heat Orchestration Template **MUST** pass the appropriate external
2435 network IDs into nested VM templates when nested Heat is used.
2440 R-35666 The VNF Heat Orchestration Template **MUST** include the resource(s) to
2441 create the internal network. The internal network must be either a
2442 Neutron Network or a Contrail Network.
2444 R-86972 The VNF Heat Orchestration Template **MUST** create internal networks in the Base
2445 Module, in the modular approach, with their resource IDs exposed as outputs
2446 (i.e., ONAP Base Module Output Parameters) for use by all incremental
2447 modules. If the Network resource ID is required in the base template,
2448 then a get\_resource must be used.
2450 R-68936 The VNF Heat Orchestration Template **SHOULD** assign a unique
2451 {network-role} in the context of the VNF, when the internal network is
2452 created. `ONAP Resource ID and Parameter Naming Convention`_ provides
2455 VNFs may use **Cloud assigned IP addresses** or
2456 **predetermined static IPs** when attaching VMs to an internal network.
2458 - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
2460 - A predetermined static IP address is enumerated in the Heat
2461 environment file. Since an internal network is local to the VNF, IP
2462 addresses can be re-used at every VNF instance.
2464 - Note that Neutron Floating IPs must not be used. ONAP does not
2465 support Neutron Floating IPs (e.g., OS::Neutron::FloatingIP)
2467 - ONAP supports the property allowed\_address\_pairs in the resource
2468 OS::Neutron:Port and the property
2469 virtual\_machine\_interface\_allowed\_address\_pairs in
2470 OS::ContrailV2::VirtualMachineInterfaces. This allows the assignment
2471 of a virtual IP (VIP) address to a set of VMs.
2473 ONAP does not programmatically enforce a naming convention for
2474 parameters for internal network. However, a naming convention is
2475 provided that must be followed.
2476 `ONAP Resource ID and Parameter Naming Convention`_
2477 provides additional details.
2479 ONAP Resource ID and Parameter Naming Convention
2480 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2482 This section provides the ONAP naming requirements for
2486 2. Resource Property Parameters
2491 R-01455 The VNF Heat Orchestration Template **MUST** assign a VNF unique
2492 {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
2493 instantiated in the VNF. While the {vm-type} must be unique to the VNF,
2494 it does not have to be globally unique across all VNFs that ONAP
2497 R-82481 The VNF Heat Orchestration Template **MUST** include {vm-type} as part of the parameter name
2498 for any parameter that is associated with a unique Virtual Machine type.
2500 R-66729 The VNF Heat Orchestration Template **MUST** include {vm-type} as part of the resource ID
2501 for any resource ID that is associated with a unique Virtual Machine type in
2504 Note that {vm-type} must not be a substring of {network-role}. A
2505 substring of a string is another string that occurs "in". For example,
2506 "oam" is a substring of "oam\_protected". It will cause the
2507 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2508 produce erroneous error messages.
2510 The {vm-type} should not contain the string “\_int” or “int\_” or
2511 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2512 ICE Project) process to produce erroneous error messages.
2514 R-32394 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
2515 parameter names in the VNF.
2517 R-46839 The VNF Heat Orchestration Template **MUST** use the same case for {vm-type} for all
2518 Resource IDs in the VNF.
2520 It is recommended that the {vm-type} case in the parameter names matches
2521 the {vm-type} case in the Resource IDs.
2523 There are two exceptions to the above rules:
2525 1. R-05008 The VNF Heat Orchestration Template **MUST NOT** be prefixed with a common
2526 {vm-type} identifier for the six ONAP Metadata parameters.
2527 They are *vnf\_name*, *vnf\_id*, *vf\_module\_id*, *vf\_module\_name,
2528 vm\_role*. The ONAP Metadata parameters are described in
2529 `Resource: OS::Nova::Server – Metadata Parameters`_.
2531 2. R-15422 The VNF Heat Orchestration Template **MUST NOT** be prefixed with a common {vm-type}
2532 identifier the parameter referring to the OS::Nova::Server property
2533 availability\_zone . availability\_zone is described in `Property: availability_zone`_.
2538 The assignment of a {network-role} is discussed in `Networking`_.
2540 R-21330 The VNF Heat Orchestration Template **MUST** include the {network-role} as part of the
2541 parameter name for any parameter that is associated with an external network.
2543 R-11168 The VNF Heat Orchestration Template **MUST** include the {network-role} as part of the
2544 resource ID for any resource ID that is associated with an external network
2547 R-84322 The VNF Heat Orchestration Template **MUST** include int\_{network-role} as part of the
2548 parameter name for any parameter that is associated with an internal network.
2550 R-96983 The VNF Heat Orchestration Template **MUST** include int\_{network-role} as part of the
2551 resource ID for any resource ID that is associated with an internal network.
2553 Note that {network-role} must not be a substring of {vm-type}. A
2554 substring of a string is another string that occurs "in". For example,
2555 "oam" is a substring of "oam\_protected". It will cause the
2556 Pre-Amsterdam VNF Validation Program (i.e., ICE Project) process to
2557 produce erroneous error messages.
2559 The {network-role} should not contain the string “\_int” or “int\_” or
2560 “\_int\_”. It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
2561 ICE Project) process to produce erroneous error messages.
2563 R-58424 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
2564 all parameter names in the VNF.
2566 R-21511 The VNF Heat Orchestration Template **MUST** use the same case for {network-role} for
2567 all Resource IDs in the VNF.
2569 It is recommended that the {network-role} case in the parameter names
2570 matches the {network-role} case in the Resource IDs.
2575 Heat Orchestration Template resources are described in `resources`_
2577 R-59629 The VNF Heat Orchestration Template **MUST** have unique resource IDs within the
2578 resources section of a Heat Orchestration Template. This is an
2579 OpenStack Requirement.
2581 R-43319 The VNF Heat Orchestration Template **MUST** have unique resource IDs
2582 across all modules that compose the VNF,
2583 when a VNF is composed of more than one Heat Orchestration Template
2586 R-54517 The VNF Heat Orchestration Template **MUST** include {vm-type} in the resource ID
2587 when a resource is associated with a single {vm-type}.
2589 R-96482 The VNF Heat Orchestration Template **MUST** include {network-role} in the resource ID
2590 when a resource is associated with a single external network.
2592 R-98138 The VNF Heat Orchestration Template **MUST** include int\_{network-role} in the resource ID
2593 when a resource is associated with a single internal network.
2595 R-82115 The VNF Heat Orchestration Template **MUST** include both the {vm-type} and
2596 {network-role} in the resource ID,
2597 when a resource is associated with a single {vm-type} and a single
2600 - The {vm-type} must appear before the {network-role} and must be
2601 separated by an underscore (i.e., {vm-type}\_{network-role}).
2603 - Note that an {index} value may separate the {vm-type} and the
2604 {network-role}. An underscore will separate the three values (i.e.,
2605 {vm-type}\_{index}\_{network-role}).
2607 R-82551 The VNF Heat Orchestration Template **MUST** include both the {vm-type} and
2608 int\_{network-role} in the resource ID,
2609 when a resource is associated with a single {vm-type} and a single
2612 - The {vm-type} must appear before the int\_{network-role} and must be
2613 separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
2615 - Note that an {index} value may separate the {vm-type} and the
2616 int\_{network-role}. An underscore will separate the three values
2617 (i.e., {vm-type}\_{index}\_int\_{network-role}).
2619 When a resource is associated with more than one {vm-type} and/or more
2620 than one network, the resource ID
2622 - must not contain the {vm-type} and/or
2623 {network-role}/int\_{network-role}
2625 - should contain the term “shared” and/or contain text that identifies
2628 R-69287 The VNF Heat Orchestration Template **MUST** use only alphanumeric characters and “\_”
2629 underscores in the resource ID. Special characters must not be used.
2631 All {index} values must be zero based. That is, the {index} must start
2632 at zero and increment by one.
2634 The table below provides example OpenStack Heat resource ID for
2635 resources only associated with one {vm-type} and/or one network.
2637 +-----------------------------+--------------------------------------+
2638 | Resource Type | Resource ID Format |
2639 +=============================+======================================+
2640 | OS::Cinder::Volume | {vm\_type}\_volume\_{index} |
2641 +-----------------------------+--------------------------------------+
2642 | OS::Cinder::VolumeAttachment| {vm\_type}\_volumeattachment\_{index}|
2643 +-----------------------------+--------------------------------------+
2644 | OS::Heat::CloudConfig | {vm\_type}\_RCC |
2645 +-----------------------------+--------------------------------------+
2646 | OS::Heat::MultipartMime | {vm\_type}\_RMM |
2647 +-----------------------------+--------------------------------------+
2648 | OS::Heat::ResourceGroup | {vm\_type}\_RRG |
2649 +-----------------------------+--------------------------------------+
2650 | OS::Heat::SoftwareConfig | {vm\_type}\_RSC |
2651 +-----------------------------+--------------------------------------+
2652 | OS::Neutron::Port | {vm\_type}\_{index}\ |
2653 | | _{network\_role}\_{index}\_port |
2654 +-----------------------------+--------------------------------------+
2655 | | {vm\_type}\_{index}\ |
2656 | | _int\_{network\_role}\_{index}\_port |
2657 +-----------------------------+--------------------------------------+
2658 | OS::Neutron::SecurityGroup | {vm\_type}\_RSG |
2659 +-----------------------------+--------------------------------------+
2660 | OS::Neutron::Subnet | {network\_role}\_subnet\_{index} |
2661 +-----------------------------+--------------------------------------+
2662 | OS::Nova::Server | {vm\_type}\_{index} |
2663 +-----------------------------+--------------------------------------+
2664 | OS::Nova::ServerGroup | {vm\_type}\_RSG |
2665 +-----------------------------+--------------------------------------+
2666 | OS::Swift::Container | {vm\_type}\_RSwiftC |
2667 +-----------------------------+--------------------------------------+
2669 Table 1: Example OpenStack Heat Resource ID
2671 The table below provides example Contrail Heat resource ID for resources
2672 only associated with one {vm-type} and/or one network.
2674 +-------------------------------------------+---------------------------------+
2675 | Resource Type | Resource ID Format |
2676 +===========================================+=================================+
2677 | OS::ContrailV2::InstanceIp | {vm\_type}\_{index}\ |
2678 | | _{network\_role}\_RII |
2679 +-------------------------------------------+---------------------------------+
2680 | OS::ContrailV2::InterfaceRouteTable | {network\_role}\_RIRT |
2681 +-------------------------------------------+---------------------------------+
2682 | OS::ContrailV2::NetworkIpam | {network\_role}\_RNI |
2683 +-------------------------------------------+---------------------------------+
2684 | OS::ContrailV2::PortTuple | {vm\_type}\_RPT |
2685 +-------------------------------------------+---------------------------------+
2686 | OS::ContrailV2::ServiceHealthCheck | {vm\_type}\_RSHC\_{LEFT\|RIGHT} |
2687 +-------------------------------------------+---------------------------------+
2688 | OS::ContrailV2::ServiceTemplate | {vm\_type}\_RST\_{index} |
2689 +-------------------------------------------+---------------------------------+
2690 | OS::ContrailV2::VirtualMachineInterface | int\_{network\_role}\_RVMI |
2691 +-------------------------------------------+---------------------------------+
2692 | OS::ContrailV2::VirtualNetwork | int\_{network\_role}\_RVN |
2693 +-------------------------------------------+---------------------------------+
2695 Table 2: Example Contrail Heat resource ID
2697 Resource: OS::Nova::Server - Parameters
2698 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2700 The resource OS::Nova::Server manages the running virtual machine (VM)
2701 instance within an OpenStack cloud. (See
2702 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2704 Four properties of this resource must follow the ONAP parameter naming
2705 convention. The four properties are:
2713 4. availability\_zone
2715 The table below provides a summary. The sections that follow provides
2718 Note that the {vm\_type} must be identical across all four property
2719 parameters for a given OS::Nova::Server resource.
2721 +----------------------------------------------------------------------------+
2722 | Resource OS::Nova::Server |
2723 +--------------+----------------+----------+----------------+----------------+
2724 | Property Name| ONAP Parameter | Parameter| Parameter Value| ONAP Parameter |
2725 | | Name | Type | Generation | Classification |
2726 +==============+================+==========+================+================+
2727 | image | {vm-type}\ | string | Environment | ONAP |
2728 | | _image\_name | string | File | Constant |
2729 +--------------+----------------+----------+----------------+----------------+
2730 | flavor | {vm-type}\ | string | Environment | ONAP |
2731 | | _flavor\_name | | File | Constant |
2732 +--------------+----------------+----------+----------------+----------------+
2733 | name | {vm-type}\ | string | ONAP | ONAP |
2734 | | _name\_{index} | | | Orchestration |
2735 +--------------+----------------+----------+----------------+----------------+
2736 | | {vm-type}\ | CDL | ONAP | ONAP |
2737 | | _names | | | Orchestration |
2738 +--------------+----------------+----------+----------------+----------------+
2739 | availability\| availability\ | string | ONAP | ONAP |
2740 | _zone | _zone\_{index} | | | Orchestration |
2741 +--------------+----------------+----------+----------------+----------------+
2743 Table 3 Resource Property Parameter Names
2748 The parameter associated with the property image is an ONAP Constant
2751 The parameters must be named {vm-type}\_image\_name in the Heat
2752 Orchestration Template.
2754 R-71152 The VNF Heat Orchestration Template **MUST** declare as type: string the parameter
2757 R-91125 The VNF Heat Orchestration Template **MUST** enumerate the parameter for property
2758 image in the Heat Orchestration Template environment file.
2760 R-57282 The VNF Heat Orchestration Template **MUST** have a separate parameter for image for
2761 Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares
2762 the same image. This provides maximum clarity and flexibility.
2764 *Example Parameter Definition*
2766 .. code-block:: yaml
2769 {vm-type}_image_name:
2771 description: {vm-type} server image
2776 The parameter associated with the property flavor is an ONAP Constant
2779 The parameters must be named {vm-type}\_flavor\_name in the Heat
2780 Orchestration Template.
2782 R-50436 The VNF Heat Orchestration Template **MUST** declare the parameter property for
2783 flavor as type: string.
2785 R-69431 The VNF Heat Orchestration Template **MUST** enumerate the parameter for property
2786 flavor in the Heat Orchestration Template environment file.
2788 R-40499 The VNF Heat Orchestration Template **MUST** have a separate parameter for flavor for each
2789 VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same
2790 flavor. This provides maximum clarity and flexibility.
2792 *Example Parameter Definition*
2794 .. code-block:: yaml
2797 {vm-type}_flavor_name:
2799 description: {vm-type} flavor
2804 The parameter associated with the property name is an ONAP Orchestration
2807 The parameter value is provided to the Heat template by ONAP.
2809 R-22838 The VNF Heat Orchestration Template **MUST NOT** enumerate the parameter for property name
2810 in the environment file.
2812 R-51430 The VNF Heat Orchestration Template **MUST** declare the parameter for property name as
2813 type: string or type: comma\_delimited\_list
2815 If the parameter is declared as type:string, the parameter must be named
2816 {vm-type}\_name\_{index}, where {index} is a numeric value that starts
2817 at zero and increments by one.
2819 If the parameter is declared as type:comma\_delimited\_list, the
2820 parameter must be named as {vm-type}\_names
2822 Each element in the VM Name list should be assigned to successive
2823 instances of that VM type.
2825 If a VNF contains more than three instances of a given {vm-type}, the
2826 comma\_delimited\_list form of the parameter name (i.e.,
2827 {vm-type}\_names) should be used to minimize the number of unique
2828 parameters defined in the Heat.
2830 *Example: Parameter Definition*
2832 .. code-block:: yaml
2836 type: comma_delimited_list
2837 description: VM Names for {vm-type} VMs
2838 {vm-type}_name_{index}:
2840 description: VM Name for {vm-type} VM {index}
2842 *Example: comma\_delimited\_list*
2844 In this example, the {vm-type} has been defined as “lb” for load
2847 .. code-block:: yaml
2851 type: comma_delimited_list
2852 description: VM Names for lb VMs
2856 type: OS::Nova::Server
2858 name: { get_param: [lb_names, 0] }
2862 type: OS::Nova::Server
2864 name: { get_param: [lb_names, 1] }
2867 *Example: fixed-index*
2869 In this example, the {vm-type} has been defined as “lb” for load
2872 .. code-block:: yaml
2877 description: VM Name for lb VM 0
2881 description: VM Name for lb VM 1
2885 type: OS::Nova::Server
2887 name: { get_param: lb_name_0 }
2891 type: OS::Nova::Server
2893 name: { get_param: lb_name_1 }
2896 Contrail Issue with Values for OS::Nova::Server Property Name
2897 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2899 The Contrail GUI has a limitation displaying special characters. The
2900 issue is documented in
2901 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
2902 recommended that special characters be avoided. However, if special
2903 characters must be used, the only special characters supported are:
2905 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
2907 Property: availability\_zone
2908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2910 The parameter associated with the property availability\_zone is an ONAP
2911 Orchestration parameter.
2913 The parameter value is provided to the Heat template by ONAP. The
2914 parameter must not be enumerated in the environment file.
2916 R-98450 The VNF Heat Orchestration Template **MUST** name the parameter availability\_zone\_{index}
2917 in the Heat Orchestration Template.
2919 R-13561 The VNF Heat Orchestration Template **MUST** start the {index} at zero.
2921 R-60204 The VNF Heat Orchestration Template **MUST** increment the {index} by one.
2923 R-36887 The VNF Heat Orchestration Template **MUST NOT** include the {vm-type} in the parameter name.
2925 The parameter must be declared as type: string
2927 The parameter must not be declared as type: comma\_delimited\_list
2932 The example below depicts part of a Heat Orchestration Template that
2933 uses the four OS::Nova::Server properties discussed in this section.
2935 In the Heat Orchestration Template below, four Virtual Machines
2936 (OS::Nova::Server) are created: two dns servers with {vm-type} set to
2937 “dns” and two oam servers with {vm-type} set to “oam”. Note that the
2938 parameter associated with the property name is a comma\_delimited\_list
2939 for dns and a string for oam.
2941 .. code-block:: yaml
2946 description: dns server image
2949 description: dns server flavor
2951 type: comma_delimited_list
2952 description: dns server names
2955 description: oam server image
2958 description: oam server flavor
2961 description: oam server name 0
2964 description: oam server name 1
2965 availability_zone_0:
2967 description: availability zone ID or Name
2968 availability_zone_1:
2970 description: availability zone ID or Name
2974 type: OS::Nova::Server
2976 name: { get_param: [ dns_names, 0 ] }
2977 image: { get_param: dns_image_name }
2978 flavor: { get_param: dns_flavor_name }
2979 availability_zone: { get_param: availability_zone_0 }
2983 type: OS::Nova::Server
2985 name: { get_param: [ dns_names, 1 ] }
2986 image: { get_param: dns_image_name }
2987 flavor: { get_param: dns_flavor_name }
2988 availability_zone: { get_param: availability_zone_1 }
2992 type: OS::Nova::Server
2994 name: { get_param: oam_name_0 }
2995 image: { get_param: oam_image_name }
2996 flavor: { get_param: oam_flavor_name }
2997 availability_zone: { get_param: availability_zone_0 }
3001 type: OS::Nova::Server
3003 name: { get_param: oam_name_1 }
3004 image: { get_param: oam_image_name }
3005 flavor: { get_param: oam_flavor_name }
3006 availability_zone: { get_param: availability_zone_1 }
3009 Resource: OS::Nova::Server – Metadata Parameters
3010 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3012 The resource OS::Nova::Server has an OpenStack optional property
3013 metadata. The metadata property is mandatory for ONAP Heat Orchestration
3014 Templates; it must be included.
3016 R-17020 The VNF Heat Orchestration Template **MUST** include the following three mandatory
3017 metadata parameters for an OS::Nova::Server resource:
3025 ONAP allows the following three optional metadata parameters for an
3026 OS::Nova::Server resource. They may be included
3032 Note that the metadata parameters do not and must not contain {vm-type}
3035 When Metadata parameters are past into a nested heat template, the
3036 parameter names must not change.
3038 The table below provides a summary. The sections that follow provides
3041 +-------------------+----------+-------------------+----------------+
3042 | Metadata Parameter| Parameter| Mandatory/Optional| Parameter Value|
3043 | Name | Type | | Generation |
3044 +===================+==========+===================+================+
3045 | vnf\_id | string | Mandatory | ONAP |
3046 +-------------------+----------+-------------------+----------------+
3047 | vf\_module\_id | string | Mandatory | ONAP |
3048 +-------------------+----------+-------------------+----------------+
3049 | vnf\_name | string | Mandatory | ONAP |
3050 +-------------------+----------+-------------------+----------------+
3051 | vf\_module\_name | string | Optional | ONAP |
3052 +-------------------+----------+-------------------+----------------+
3053 | vm\_role | string | Optional | YAML or |
3054 | | | | Environment |
3056 +-------------------+----------+-------------------+----------------+
3058 Table 4: ONAP Metadata
3063 The vnf\_id parameter is mandatory; it must be included in the Heat
3064 Orchestration Template.
3066 The vnf\_id parameter value will be supplied by ONAP. ONAP generates the
3067 UUID that is the vnf\_id and supplies it to the Heat Orchestration
3068 Template at orchestration time.
3070 The parameter must be declared as type: string
3072 R-55218 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
3073 for the OS::Nova::Server metadata parameter vnf\_id.
3075 R-20856 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
3076 metadata parameter vnf\_id in environment file.
3078 *Example Parameter Definition*
3080 .. code-block:: yaml
3085 description: Unique ID for this VNF instance
3090 The vf\_module\_id parameter is mandatory; it must be included in the
3091 Heat Orchestration Template.
3093 The vf\_module\_id parameter value will be supplied by ONAP. ONAP
3094 generates the UUID that is the vf\_module\_id and supplies it to the
3095 Heat Orchestration Template at orchestration time.
3097 The parameter must be declared as type: string
3099 R-98374 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints
3100 defined for the OS::Nova::Server metadata parameter vf\_module\_id.
3102 R-72871 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
3103 metadata parameter vf\_module\_id in environment file.
3105 *Example Parameter Definition*
3107 .. code-block:: yaml
3112 description: Unique ID for this VNF module instance
3117 The vnf\_name parameter is mandatory; it must be included in the Heat
3118 Orchestration Template.
3120 The vnf\_name parameter value will be generated and/or assigned by ONAP
3121 and supplied to the Heat Orchestration Template by ONAP at orchestration
3124 The parameter must be declared as type: string
3126 R-44318 The VNF Heat Orchestration Template **MUST NOT** have parameter constraints defined
3127 for the OS::Nova::Server metadata parameter vnf\_name.
3129 R-36542 The VNF Heat Orchestration Template **MUST NOT** enumerate the OS::Nova::Server
3130 metadata parameter vnf\_name in the environment file.
3132 *Example Parameter Definition*
3134 .. code-block:: yaml
3139 description: Unique name for this VNF instance
3144 The vf\_module\_name parameter is optional; it may be included in the
3145 Heat Orchestration Template.
3147 The vf\_module\_name parameter is the name of the name of the Heat stack
3148 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g., Heat
3149 stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The <STACK\_NAME>
3150 needs to be specified as part of the orchestration process.
3152 The parameter must be declared as type: string
3154 Parameter constraints must not be defined.
3156 The parameter must not be enumerated in the Heat environment file.
3158 *Example Parameter Definition*
3160 .. code-block:: yaml
3165 description: Unique name for this VNF Module instance
3170 The vm\_role parameter is optional; it may be included in the Heat
3171 Orchestration Template.
3173 Any roles tagged to the VMs via metadata will be stored in ONAP’s A&AI
3174 system and available for use by other ONAP components and/or north bound
3177 The vm\_role values must be either
3179 - hard-coded into the Heat Orchestration Template or
3181 - enumerated in the environment file.
3183 Defining the vm\_role as the {vm-type} is a recommended convention
3185 The parameter must be declared as type: string
3187 Parameter constraints must not be defined.
3189 *Example Parameter Definition*
3191 .. code-block:: yaml
3196 description: Unique role for this VM
3198 *Example Resource Definition: Hard Coded*
3200 In this example, the {vm-role} is hard coded in the Heat Orchestration
3203 .. code-block:: yaml
3207 type: OS::Nova::Server
3213 *Example Resource Definition: get\_param*
3215 In this example, the {vm-role} is enumerated in the environment file.
3217 .. code-block:: yaml
3221 type: OS::Nova::Server
3225 vm_role: { get_param: vm_role }
3230 The example below depicts part of a Heat Orchestration Template that
3231 uses the five of the OS::Nova::Server metadata parameter discussed in
3232 this section. The {vm-type} has been defined as lb for load balancer.
3234 .. code-block:: yaml
3239 description: VM Name for lb VM 0
3242 description: Unique name for this VNF instance
3245 description: Unique ID for this VNF instance
3248 description: Unique name for this VNF Module instance
3251 description: Unique ID for this VNF Module instance
3254 description: Unique role for this VM
3259 type: OS::Nova::Server
3261 name: { get_param: lb_name_0 }
3264 vnf_name: { get_param: vnf_name }
3265 vnf_id: { get_param: vnf_id }
3266 vf_module_name: { get_param: vf_module_name }
3267 vf_module_id: { get_param: vf_module_id }
3270 Resource: OS::Neutron::Port - Parameters
3271 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3273 The resource OS::Neutron::Port is for managing Neutron ports (See
3274 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3279 Four properties of the resource OS::Neutron::Port that must follow the
3280 ONAP parameter naming convention. The four properties are:
3284 2. fixed\_ips, ip\_address
3286 3. fixed\_ips, subnet\_id
3288 4. allowed\_address\_pairs, ip\_address
3290 The parameters associated with these properties may reference an
3291 external network or internal network. External networks and internal
3292 networks are defined in `Networking`_.
3297 When the parameter references an external network
3299 - R-72050 The VNF Heat Orchestration Template **MUST** contain {network-role} in the parameter name
3301 - the parameter must not be enumerated in the Heat environment file
3303 - the parameter is classified as an ONAP Orchestration Parameter
3305 +----------------------+---------------------------+--------------------------+
3306 | Property Name | ONAP Parameter Name | Parameter Type |
3307 +======================+===========================+==========================+
3308 | network | {network-role}\_net\_id | string |
3309 | +---------------------------+--------------------------+
3310 | | {network-role}\_net\_name | string |
3311 +----------------------+---------------------------+--------------------------+
3312 | fixed\_ips, | {vm-type}\_{network-role}\| string |
3313 | ip\_address | _ip\_{index} | |
3314 | +---------------------------+--------------------------+
3315 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3317 | +---------------------------+--------------------------+
3318 | | {vm-type}\_{network-role}\| string |
3319 | | _v6\_ip\_{index} | |
3320 | +---------------------------+--------------------------+
3321 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3323 +----------------------+---------------------------+--------------------------+
3324 | fixed\_ips, subnet | {network-role}\ | string |
3326 | +---------------------------+--------------------------+
3327 | | {network-role}\ | string |
3328 | | _v6\_subnet\_id | |
3329 +----------------------+---------------------------+--------------------------+
3330 | allowed\_address | {vm-type}\_{network-role}\| string |
3331 | \_pairs, ip\_address | _floating\_ip | |
3332 | +---------------------------+--------------------------+
3333 | | {vm-type}\_{network-role}\| string |
3334 | | _floating\_v6\_ip | |
3335 | +---------------------------+--------------------------+
3336 | | {vm-type}\_{network-role}\| string |
3337 | | _ip\_{index} | |
3338 | +---------------------------+--------------------------+
3339 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3341 | +---------------------------+--------------------------+
3342 | | {vm-type}\_{network-role}\| string |
3343 | | _v6\_ip\_{index} | |
3344 | +---------------------------+--------------------------+
3345 | | {vm-type}\_{network-role}\| comma\_delimited\_list |
3347 +----------------------+---------------------------+--------------------------+
3349 Table 5: OS::Neutron::Port Resource Property Parameters (External
3355 When the parameter references an internal network
3357 - R-57576 The VNF Heat Orchestration Template **MUST** contain int\_{network-role}
3358 in the parameter name.
3360 - the parameter may be enumerated in the environment file.
3362 +-------------------------+--------------------------------+-----------------+
3363 | Property | Parameter Name for | Parameter Type |
3364 | | Internal Networks | |
3365 +=========================+================================+=================+
3366 | network | int\_{network-role}\ | string |
3368 | +--------------------------------+-----------------+
3369 | | int\_{network-role}\ | string |
3371 +-------------------------+--------------------------------+-----------------+
3372 | fixed\_ips, ip\_address | {vm-type}\_int\_{network-role}\| string |
3373 | | _ip\_{index} | |
3374 | +--------------------------------+-----------------+
3375 | | {vm-type}\_int\_{network-role}\| comma\ |
3376 | | _ips | _delimited\_list|
3377 | +--------------------------------+-----------------+
3378 | | {vm-type}\_int\_{network-role}\| string |
3379 | | _v6\_ip\_{index} | |
3380 | +--------------------------------+-----------------+
3381 | | {vm-type}\_int\_{network-role}\| comma\ |
3382 | | _v6\_ips | _delimited\_list|
3383 +-------------------------+--------------------------------+-----------------+
3384 | fixed\_ips, subnet | int\_{network-role}\ | string |
3386 | +--------------------------------+-----------------+
3387 | | int\_{network-role}\ | string |
3388 | | _v6\_subnet\_id | |
3389 +-------------------------+--------------------------------+-----------------+
3390 | allowed\_address\_pairs,| {vm-type}\_int\_{network-role}\| string |
3391 | ip\_address | _floating\_ip | |
3392 | +--------------------------------+-----------------+
3393 | | {vm-type}\_int\_{network-role}\| string |
3394 | | _floating\_v6\_ip | |
3395 | +--------------------------------+-----------------+
3396 | | {vm-type}\_int\_{network-role}\| string |
3397 | | _ip\_{index} | |
3398 | +--------------------------------+-----------------+
3399 | | {vm-type}\_int\_{network-role}\| comma\ |
3400 | | _ips | _delimited\_list|
3401 | +--------------------------------+-----------------+
3402 | | {vm-type}\_int\_{network-role}\| string |
3403 | | _v6\_ip\_{index} | |
3404 | +--------------------------------+-----------------+
3405 | | {vm-type}\_int\_{network-role}\| comma\ |
3406 | | _v6\_ips | _delimited\_list|
3407 +-------------------------+--------------------------------+-----------------+
3409 Table 6: Port Resource Property Parameters (Internal Networks)
3414 The property networks in the resource OS::Neutron::Port must be
3415 referenced by Neutron Network ID, a UUID value, or by the network name
3416 defined in OpenStack.
3421 R-93272 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
3422 convention in the Heat Orchestration Template, when the parameter
3423 associated with the property network is referencing an “external” network:
3425 - {network-role}\_net\_id for the Neutron network ID
3427 - {network-role}\_net\_name for the network name in OpenStack
3429 The parameter must be declared as type: string
3431 The parameter must not be enumerated in the Heat environment file.
3433 *Example Parameter Definition*
3435 .. code-block:: yaml
3438 {network-role}_net_id:
3440 description: Neutron UUID for the {network-role} network
3441 {network-role}_net_name:
3443 description: Neutron name for the {network-role} network
3445 *Example: One Cloud Assigned IP Address (DHCP) assigned to a network
3446 that has only one subnet*
3448 In this example, the {network-role} has been defined as oam to represent
3449 an oam network and the {vm-type} has been defined as lb for load
3450 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3451 to assign IP addresses.
3453 .. code-block:: yaml
3458 description: Neutron UUID for the oam network
3462 type: OS::Neutron::Port
3463 network: { get_param: oam_net_id }
3468 R-65373 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
3469 convention, when the parameter associated with the property network is
3470 referencing an “internal” network:
3472 - int\_{network-role}\_net\_id for the Neutron network ID
3474 - int\_{network-role}\_net\_name for the network name in OpenStack
3476 The parameter must be declared as type: string
3478 The assumption is that internal networks are created in the base module.
3479 The Neutron Network ID will be passed as an output parameter (e.g., ONAP
3480 Base Module Output Parameter) to the incremental modules. In the
3481 incremental modules, it will be defined as input parameter.
3483 *Example Parameter Definition*
3485 .. code-block:: yaml
3488 int_{network-role}_net_id:
3490 description: Neutron UUID for the {network-role} network
3491 int_{network-role}_net_name:
3493 description: Neutron name for the {network-role} network
3495 Property: fixed\_ips, Map Property: subnet\_id
3496 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3498 The property fixed\_ips is used to assign IPs to a port. The Map
3499 Property subnet\_id specifies the subnet the IP is assigned from.
3501 The property fixed\_ips and Map Property subnet\_id must be used if a
3502 Cloud (i.e., DHCP) IP address assignment is being requested and the
3503 Cloud IP address assignment is targeted at a specific subnet when two or
3506 The property fixed\_ips and Map Property subnet\_id should not be used
3507 if all IP assignments are fixed, or if the Cloud IP address assignment
3508 does not target a specific subnet or there is only one subnet.
3510 Note that DHCP assignment of IP addresses is also referred to as cloud
3511 assigned IP addresses.
3513 Subnet of an External Networks
3514 +++++++++++++++++++++++++++++++
3516 R-47716 The VNF Heat Orchestration Template **MUST** adhere to the following parameter naming
3517 convention for the property fixed\_ips and Map Property subnet\_id
3518 parameter, when the parameter is referencing a subnet of an
3521 - {network-role}\_subnet\_id if the subnet is an IPv4 subnet
3523 - {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3525 The parameter must be declared as type: string
3527 The parameter must not be enumerated in the Heat environment file.
3529 *Example Parameter Definition*
3531 .. code-block:: yaml
3534 {network-role}_subnet_id:
3536 description: Neutron subnet UUID for the {network-role} network
3538 {network-role}_v6_subnet_id:
3540 description: Neutron subnet UUID for the {network-role} network
3542 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3543 that has two or more subnets subnet:*
3545 In this example, the {network-role} has been defined as oam to represent
3546 an oam network and the {vm-type} has been defined as lb for load
3547 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3548 to assign IP addresses.
3550 .. code-block:: yaml
3555 description: Neutron UUID for the oam network
3559 description: Neutron subnet UUID for the oam network
3563 type: OS::Neutron::Port
3564 network: { get_param: oam_net_id }
3566 - subnet_id: { get_param: oam_subnet_id }
3568 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3569 address assigned to a network that has at least one IPv4 subnet and one
3572 In this example, the {network-role} has been defined as oam to represent
3573 an oam network and the {vm-type} has been defined as lb for load
3576 .. code-block:: yaml
3581 description: Neutron UUID for the oam network
3585 description: Neutron subnet UUID for the oam network
3589 description: Neutron subnet UUID for the oam network
3593 type: OS::Neutron::Port
3595 network: { get_param: oam_net_id }
3597 - subnet_id: { get_param: oam_subnet_id }
3598 - subnet_id: { get_param: oam_v6_subnet_id }
3603 R-20106 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention for
3604 the property fixed\_ips and Map Property subnet\_id parameter,
3605 when the parameter is referencing the subnet of an “internal” network:
3607 - int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
3609 - int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
3611 The parameter must be declared as type: string
3613 The assumption is that internal networks are created in the base module.
3614 The Neutron subnet network ID will be passed as an output parameter
3615 (e.g., ONAP Base Module Output Parameter) to the incremental modules. In
3616 the incremental modules, it will be defined as input parameter.
3618 *Example Parameter Definition*
3620 .. code-block:: yaml
3623 int_{network-role}_subnet_id:
3625 description: Neutron subnet UUID for the {network-role} network
3627 int_{network-role}_v6_subnet_id:
3629 description: Neutron subnet UUID for the {network-role} network
3631 Property: fixed\_ips, Map Property: ip\_address
3632 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3634 The property fixed\_ips is used to assign IPs to a port. The Map
3635 Property ip\_address specifies the IP address to be assigned to the
3638 The property fixed\_ips and Map Property ip\_address must be used when
3639 statically assigning one or more IP addresses to a port. This is also
3640 referred to as ONAP SDN-C IP address assignment. ONAP’s SDN-C provides
3641 the IP address assignment.
3643 An IP address is assigned to a port on a VM (referenced by {vm-type})
3644 that is connected to an external network (referenced by {network-role})
3645 or internal network (referenced by int\_{network-role}).
3647 R-41177 The VNF Heat Orchestration Template **MUST** include {vm-type} and {network-role}
3648 in the parameter name, when a SDN-C IP assignment is made to a
3649 port connected to an external network.
3651 When a SDN-C IP assignment is made to a port connected to an internal
3652 network, the parameter name must contain {vm-type} and
3653 int\_{network-role}.
3655 IP Address Assignments on External Networks
3656 ++++++++++++++++++++++++++++++++++++++++++++
3658 When the property fixed\_ips and Map Property ip\_address is used to
3659 assign IP addresses to an external network, the parameter name is
3660 dependent on the parameter type (comma\_delimited\_list or string) and
3661 IP address type (IPv4 or IPv6).
3663 R-84898 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention,
3664 when the parameter for property fixed\_ips and Map Property ip\_address
3665 is declared type: comma\_delimited\_list:
3667 - {vm-type}\_{network-role}\_ips for IPv4 address
3669 - {vm-type}\_{network-role}\_v6\_ips for IPv6 address
3671 Each element in the IP list should be assigned to successive instances
3672 of {vm-type} on {network-role}.
3674 The parameter must not be enumerated in the Heat environment file.
3676 *Example Parameter Definition*
3678 .. code-block:: yaml
3682 {vm-type}_{network-role}_ips:
3683 type: comma_delimited_list
3684 description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
3686 {vm-type}_{network-role}_v6_ips:
3687 type: comma_delimited_list
3688 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3690 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3691 Assignments to an external network*
3693 In this example, the {network-role} has been defined as oam to represent
3694 an oam network and the {vm-type} has been defined as db for database.
3696 .. code-block:: yaml
3701 description: Neutron UUID for a oam network
3704 type: comma_delimited_list
3705 description: Fixed IPv4 assignments for db VMs on the oam network
3708 type: comma_delimited_list
3709 description: Fixed IPv6 assignments for db VMs on the oam network
3713 type: OS::Neutron::Port
3714 network: { get_param: oam_net_id }
3715 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {“ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3718 type: OS::Neutron::Port
3720 network: { get_param: oam_net_id }
3722 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3723 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3725 R-34960 The VNF Heat Orchestration Template **MUST** adhere to the following
3727 when the parameter for property fixed\_ips and Map Property ip\_address
3728 is declared type: string:
3730 - {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
3732 - {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3734 The value for {index} must start at zero (0) and increment by one.
3736 The parameter must not be enumerated in the Heat environment file.
3738 *Example Parameter Definition*
3740 .. code-block:: yaml
3743 {vm-type}_{network-role}_ip_{index}:
3745 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3747 {vm-type}_{network-role}_v6_ip_{index}:
3749 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3751 *Example: string parameters for IPv4 and IPv6 Address Assignments
3752 to an external network*
3754 In this example, the {network-role} has been defined as “oam” to
3755 represent an oam network and the {vm-type} has been defined as “db” for
3758 .. code-block:: yaml
3763 description: Neutron UUID for an OAM network
3767 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3771 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3775 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3779 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3783 type: OS::Neutron::Port
3785 network: { get_param: oam_net_id }
3786 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, {“ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3789 type: OS::Neutron::Port
3791 network: { get_param: oam_net_id }
3793 - “ip_address”: {get_param: db_oam_ip_1}}]
3794 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3796 IP Address Assignment on Internal Networks
3797 ++++++++++++++++++++++++++++++++++++++++++++
3799 When the property fixed\_ips and Map Property ip\_address is used to
3800 assign IP addresses to an internal network, the parameter name is
3801 dependent on the parameter type (comma\_delimited\_list or string) and
3802 IP address type (IPv4 or IPv6).
3804 R-62584 The VNF Heat Orchestration Template **MUST** adhere to
3805 the following naming convention,
3806 when the parameter for property fixed\_ips and Map Property ip\_address
3807 is declared type: comma\_delimited\_list:
3809 - {vm-type}\_int\_{network-role}\_ips for IPv4 address
3811 - {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
3813 Each element in the IP list should be assigned to successive instances
3814 of {vm-type} on {network-role}.
3816 The parameter must be enumerated in the Heat environment file. Since an
3817 internal network is local to the VNF, IP addresses can be re-used at
3820 *Example Parameter Definition*
3822 .. code-block:: yaml
3826 {vm-type}_int_{network-role}_ips:
3827 type: comma_delimited_list
3828 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3830 {vm-type}_int_{network-role}_v6_ips:
3831 type: comma_delimited_list
3832 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3834 *Example: comma\_delimited\_list parameters for IPv4 and IPv6 Address
3835 Assignments to an internal network*
3837 In this example, the {network-role} has been defined as oam\_int to
3838 represent an oam network internal to the vnf. The role oam\_int was
3839 picked to differentiate from an external oam network with a
3840 {network-role} of oam. The {vm-type} has been defined as db for
3843 .. code-block:: yaml
3848 description: Neutron UUID for the oam internal network
3851 type: comma_delimited_list
3852 description: Fixed IPv4 assignments for db VMs on the oam internal network
3854 db_int_oam_int_v6_ips:
3855 type: comma_delimited_list
3856 description: Fixed IPv6 assignments for db VMs on the oam internal network
3860 type: OS::Neutron::Port
3862 network: { get_param: int_oam_int_net_id }
3863 fixed_ips: [ { “ip_address”: {get_param: [ db_int_oam_int_ips, 0]}}, { “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 0 ]}}]
3866 type: OS::Neutron::Port
3868 network: { get_param: int_oam_int_net_id }
3870 - “ip_address”: {get_param: [ db_int_oam_int_ips, 1 ]}
3871 - “ip_address”: {get_param: [ db_int_oam_int_v6_ips, 1 ]}
3873 R-29256 The VNF Heat Orchestration Template **MUST** must adhere to the following
3875 when the parameter for property fixed\_ips and Map Property ip\_address
3876 is declared type: string:
3878 - {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
3880 - {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
3882 The value for {index} must start at zero (0) and increment by one.
3884 The parameter must be enumerated in the Heat environment file. Since an
3885 internal network is local to the VNF, IP addresses can be re-used at
3888 *Example Parameter Definition*
3890 .. code-block:: yaml
3894 {vm-type}_int_{network-role}_ip_{index}:
3896 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3898 {vm-type}_int_{network-role}_v6_ip_{index}:
3900 description: Fixed IPv6 assignment for {vm-type} VM {index} on the{network-role} network
3902 *Example: string parameters for IPv4 and IPv6 Address Assignments
3903 to an internal network*
3905 In this example, the {network-role} has been defined as oam\_int to
3906 represent an oam network internal to the vnf. The role oam\_int was
3907 picked to differentiate from an external oam network with a
3908 {network-role} of oam. The {vm-type} has been defined as db for
3911 .. code-block:: yaml
3916 description: Neutron UUID for an OAM internal network
3920 description: Fixed IPv4 assignment for db VM on the oam_int network
3924 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3928 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3932 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3936 type: OS::Neutron::Port
3938 network: { get_param: int_oam_int_net_id }
3939 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {“ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3942 type: OS::Neutron::Port
3944 network: { get_param: int_oam_int_net_id }
3946 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3947 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3949 Property: allowed\_address\_pairs, Map Property: ip\_address
3950 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3952 The property allowed\_address\_pairs in the resource OS::Neutron::Port
3953 allows the user to specify a mac\_address and/or ip\_address that will
3954 pass through a port regardless of subnet. This enables the use of
3955 protocols such as VRRP, which floats an IP address between two instances
3956 to enable fast data plane failover. The map property ip\_address
3957 specifies the IP address.
3959 The allowed\_address\_pairs is an optional property. It is not required.
3961 An ONAP Heat Orchestration Template allows the assignment of one IPv4
3962 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3963 and {network-role}/int\_{network-role} combination.
3965 An ONAP Heat Orchestration Template allows the assignment of one IPv6
3966 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
3967 and {network-role}/int\_{network-role} combination.
3969 Note that the management of these IP addresses (i.e. transferring
3970 ownership between active and standby VMs) is the responsibility of the
3973 Note that these parameters are **not** intended to represent Neutron
3974 “Floating IP” resources, for which OpenStack manages a pool of public IP
3975 addresses that are mapped to specific VM ports. In that case, the
3976 individual VMs are not even aware of the public IPs, and all assignment
3977 of public IPs to VMs is via OpenStack commands. ONAP does not support
3978 Neutron-style Floating IPs.
3983 R-61282 The VNF Heat Orchestration Template **MUST**
3984 adhere to the following naming convention for the property
3985 allowed\_address\_pairs and Map Property ip\_address parameter,
3986 when the parameter is referencing an “external” network:
3988 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
3990 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
3992 The parameter must be declared as type: string
3994 The parameter must not be enumerated in the Heat environment file.
3996 *Example Parameter Definition*
3998 .. code-block:: yaml
4002 {vm-type}_{network-role}_floating_ip:
4004 description: VIP for {vm-type} VMs on the {network-role} network
4006 {vm-type}_{network-role}_floating_v6_ip:
4008 description: VIP for {vm-type} VMs on the {network-role} network
4012 In this example, the {network-role} has been defined as oam to represent
4013 an oam network and the {vm-type} has been defined as db for database.
4015 .. code-block:: yaml
4020 description: Neutron UUID for the oam network
4023 type: comma_delimited_list
4024 description: Fixed IPs for db VMs on the oam network
4028 description: VIP IP for db VMs on the oam network
4032 type: OS::Neutron::Port
4034 network: { get_param: oam_net_id }
4035 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
4036 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4039 type: OS::Neutron::Port
4041 network: { get_param: oam_net_id }
4042 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
4043 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4048 R-16805 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention
4049 for the property allowed\_address\_pairs and Map Property ip\_address
4050 parameter when the parameter is referencing an “internal” network.
4052 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
4054 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
4056 The parameter must be declared as type: string
4058 The parameter must be enumerated in the Heat environment file.
4060 *Example Parameter Definition*
4062 .. code-block:: yaml
4066 {vm-type}_int_{network-role}_floating_ip:
4068 description: VIP for {vm-type} VMs on the int_{network-role} network
4070 {vm-type}_int_{network-role}_floating_v6_ip:
4072 description: VIP for {vm-type} VMs on the int_{network-role} network
4074 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
4075 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4077 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
4078 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
4080 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
4081 one allowed address pair IPv6 address per {vm-type} and {network-role}
4084 If there is a need for multiple allowed address pair IPs for a given
4085 {vm-type} and {network-role} combination within a VNF, then the
4086 parameter names defined for the property fixed\_ips and Map Property
4087 ip\_address should be used with the allowed\_address\_pairs property.
4088 The examples below illustrate this.
4090 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
4092 In this example, there are two administrative VM pairs. Each pair has
4093 one VIP. The {network-role} has been defined as oam to represent an oam
4094 network and the {vm-type} has been defined as admin for an
4097 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
4098 VIP, [admin\_oam\_ips,2]
4100 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
4101 VIP, [admin\_oam\_ips,5]
4103 .. code-block:: yaml
4108 description: Neutron UUID for the oam network
4110 type: comma_delimited_list
4111 description: Fixed IP assignments for admin VMs on the oam network
4116 type: OS::Neutron::Port
4118 network: { get_param: oam_net_id }
4119 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
4120 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4123 type: OS::Neutron::Port
4125 network: { get_param: oam_net_id }
4126 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
4127 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4130 type: OS::Neutron::Port
4132 network: { get_param: oam_net_id }
4133 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
4134 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4137 type: OS::Neutron::Port
4139 network: { get_param: oam_net_id }
4140 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
4141 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4143 *Example: A VNF has two load balancers. The pair of load balancers share
4146 In this example, there is one load balancer pairs. The pair has two
4147 VIPs. The {network-role} has been defined as oam to represent an oam
4148 network and the {vm-type} has been defined as lb for a load balancer VM.
4150 .. code-block:: yaml
4154 type: OS::Neutron::Port
4156 network: { get_param: oam_net_id }
4157 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
4158 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4161 type: OS::Neutron::Port
4163 network: { get_param: oam_net_id }
4164 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
4165 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4167 As a general rule, provide the fixed IPs for the VMs indexed first in
4168 the CDL and then the VIPs as shown in the examples above.
4170 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
4171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4173 The following items must be taken into consideration when designing Heat
4174 Orchestration Templates that expect ONAP’s SDN-C to assign
4175 allowed\_address\_pair IP addresses via automation.
4177 The VMs must be of the same {vm-type}.
4179 The VMs must be created in the same module (base or incremental).
4181 Resource Property “name”
4182 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4184 The parameter naming convention of the property name for the resource
4185 OS::Nova::Server has been defined in
4186 `Resource: OS::Nova::Server – Metadata Parameters`_.
4188 This section provides the requirements how the property name for non
4189 OS::Nova::Server resources must be defined when the property is used.
4190 Not all resources require the property name (e.g., it is optional) and
4191 some resources do not support the property.
4193 R-85734 The VNF Heat Orchestration Template **MUST** use the intrinsic function str\_replace
4194 in conjunction with the ONAP supplied metadata parameter
4195 vnf\_name to generate a unique value,
4196 when the property name for a non OS::Nova::Server resources is defined
4197 in a Heat Orchestration Template.
4199 This prevents the enumeration of a
4200 unique value for the property name in a per instance environment file.
4204 - In most cases, only the use of the metadata value vnf\_name is
4205 required to create a unique property name
4207 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4208 may also be used in the str\_replace construct to generate a unique
4209 name when the vnf\_name does not provide uniqueness
4211 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4213 .. code-block:: yaml
4217 type: OS::Neutron::SecurityGroup
4219 description: vDNS security group
4222 template: VNF_NAME_sec_grp_DNS
4224 VNF_NAME: {get_param: vnf_name}
4228 *Example: Property name for resource* OS::Cinder::Volume
4230 .. code-block:: yaml
4234 type: OS::Cinder::Volume
4236 description: Cinder Volume
4239 template: VNF_NAME_STACK_NAME_dns_volume
4241 VNF_NAME: {get_param: vnf_name}
4242 STACK_NAME: { get_param: 'OS::stack_name' }
4245 Contrail Issue with Values for the Property Name
4246 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4248 The Contrail GUI has a limitation displaying special characters. The
4249 issue is documented in
4250 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4251 recommended that special characters be avoided. However, if special
4252 characters must be used, note that for the following resources:
4266 the only special characters supported are:
4268 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4270 ONAP Output Parameter Names
4271 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4273 ONAP defines three types of Output Parameters as detailed in
4274 `Output Parameters`_.
4276 ONAP Base Module Output Parameters:
4277 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4279 ONAP Base Module Output Parameters do not have an explicit naming
4280 convention. The parameter name must contain {vm-type} and {network-role}
4283 ONAP Volume Template Output Parameters:
4284 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4286 ONAP Base Module Output Parameters do not have an explicit naming
4287 convention. The parameter name must contain {vm-type} when appropriate.
4289 Predefined Output Parameters
4290 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4292 ONAP currently defines one predefined output parameter the OAM
4293 Management IP Addresses.
4295 OAM Management IP Addresses
4296 +++++++++++++++++++++++++++++
4298 A VNF may have a management interface for application controllers to
4299 interact with and configure the VNF. Typically, this will be via a
4300 specific VM that performs a VNF administration function. The IP address
4301 of this interface must be captured and inventoried by ONAP. The IP
4302 address might be a VIP if the VNF contains an HA pair of management VMs,
4303 or may be a single IP address assigned to one VM.
4305 The Heat template may define either (or both) of the following Output
4306 parameters to identify the management IP address.
4308 - oam\_management\_v4\_address
4310 - oam\_management\_v6\_address
4314 - The use of this output parameters are optional.
4316 - The Management IP Address should be defined only once per VNF, so it
4317 must only appear in one Module template
4319 - If a fixed IP for the admin VM is passed as an input parameter, it
4320 may be echoed in the output parameters. In this case, a IPv4 and/or
4321 IPv6 parameter must be defined in the parameter section of the YAML
4322 Heat template. The parameter maybe named oam\_management\_v4\_address
4323 and/or oam\_management\_v6\_address or may be named differently.
4325 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4326 from the resource attributes. In this case,
4327 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4328 not be defined in the parameter section of the YAML Heat template.
4330 *Example: SDN-C Assigned IP Address echoed as*
4331 oam\_management\_v4\_address
4333 .. code-block:: yaml
4338 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4342 admin_oam_net_0_port:
4343 type: OS::Neutron::Port
4347 template: VNF_NAME_admin_oam_net_0_port
4349 VNF_NAME: {get_param: vnf_name}
4350 network: { get_param: oam_net_id }
4351 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4352 security_groups: [{ get_param: security_group }]
4355 type: OS::Nova::Server
4357 name: { get_param: admin_names }
4358 image: { get_param: admin_image_name }
4359 flavor: { get_param: admin_flavor_name }
4360 availability_zone: { get_param: availability_zone_0 }
4362 - port: { get_resource: admin_oam_net_0_port }
4364 vnf_id: { get_param: vnf_id }
4365 vf_module_id: { get_param: vf_module_id }
4366 vnf_name: {get_param: vnf_name }
4368 oam_management_v4_address:
4369 value: {get_param: admin_oam_ip_0 }
4371 *Example: Cloud Assigned IP Address output as*
4372 oam\_management\_v4\_address
4374 .. code-block:: yaml
4379 admin_oam_net_0_port:
4380 type: OS::Neutron::Port
4384 template: VNF_NAME_admin_oam_net_0_port
4386 VNF_NAME: {get_param: vnf_name}
4387 network: { get_param: oam_net_id }
4388 security_groups: [{ get_param: security_group }]
4391 type: OS::Nova::Server
4393 name: { get_param: admin_names }
4394 image: { get_param: admin_image_name }
4395 flavor: { get_param: admin_flavor_name }
4396 availability_zone: { get_param: availability_zone_0 }
4398 - port: { get_resource: admin_oam_net_0_port }
4400 vnf_id: { get_param: vnf_id }
4401 vf_module_id: { get_param: vf_module_id }
4402 vnf_name: {get_param: vnf_name }
4405 oam_management_v4_address:
4406 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4408 Contrail Resource Parameters
4409 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4411 ONAP requires the parameter names of certain Contrail Resources to
4412 follow specific naming conventions. This section provides these
4415 Contrail Network Parameters
4416 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4418 Contrail based resources may require references to a Contrail network
4419 using the network FQDN.
4424 When the parameter associated with the Contrail Network is referencing
4425 an “external” network, the parameter must adhere to the following naming
4426 convention in the Heat Orchestration Template
4428 - {network-role}\_net\_fqdn
4430 The parameter must be declared as type: string
4432 The parameter must not be enumerated in the Heat environment file.
4434 *Example: Parameter declaration*
4436 .. code-block:: yaml
4439 {network-role}_net_fqdn:
4441 description: Contrail FQDN for the {network-role} network
4443 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4444 Reference to a Network FQDN.*
4446 In this example, the {network-role} has been defined as oam to represent
4447 an oam network and the {vm-type} has been defined as fw for firewall.
4448 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4449 virtual\_network\_refs references a contrail network FQDN.
4451 .. code-block:: yaml
4454 type: OS::ContrailV2::VirtualMachineInterface
4458 template: VM_NAME_virtual_machine_interface_1
4460 VM_NAME: { get_param: fw_name_0 }
4461 virtual_machine_interface_properties:
4462 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4463 virtual_network_refs:
4464 - get_param: oam_net_fqdn
4465 security_group_refs:
4466 - get_param: fw_sec_grp_id
4468 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4469 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4471 The parameter associated with the resource
4472 OS::ContrailV2::InterfaceRouteTable property
4473 interface\_route\_table\_routes, map property
4474 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4477 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4478 in the Heat Orchestration Template.
4480 The parameter must be declared as type: json
4482 The parameter supports IP addresses in the format:
4484 1. Host IP Address (e.g., 10.10.10.10)
4486 2. CIDR Notation format (e.g., 10.0.0.0/28)
4488 The parameter must not be enumerated in the Heat environment file.
4490 *Example Parameter Definition*
4492 .. code-block:: yaml
4495 {vm-type}_{network-role}_route_prefixes:
4497 description: JSON list of Contrail Interface Route Table route prefixes
4501 .. code-block:: yaml
4506 description: Unique name for this VF instance
4507 fw_int_fw_route_prefixes:
4509 description: prefix for the ServiceInstance InterfaceRouteTable
4510 int_fw_dns_trusted_interface_type:
4512 description: service_interface_type for ServiceInstance
4515 type: OS::ContrailV2::InterfaceRouteTable
4516 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4520 template: VNF_NAME_interface_route_table
4522 VNF_NAME: { get_param: vnf_name }
4523 interface_route_table_routes:
4524 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4525 service_instance_refs:
4526 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4527 service_instance_refs_data:
4528 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4530 Parameter Names in Contrail Resources
4531 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4533 Contrail Heat resource properties will use, when appropriate, the same
4534 naming convention as OpenStack Heat resources. For example, the resource
4535 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4536 convention is identical to properties in OS::Neutron::Port.
4538 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4539 instance\_ip\_address*
4541 The property instance\_ip\_address uses the same parameter naming
4542 convention as the property fixed\_ips and Map Property ip\_address in
4543 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4544 Address. The {network-role} has been defined as oam\_protected to
4545 represent an oam protected network and the {vm-type} has been defined as
4548 .. code-block:: yaml
4550 CMD_FW_OAM_PROTECTED_RII:
4551 type: OS::ContrailV2::InstanceIp
4553 - FW_OAM_PROTECTED_RVMI
4555 virtual_machine_interface_refs:
4556 - get_resource: FW_OAM_PROTECTED_RVMI
4557 virtual_network_refs:
4558 - get_param: oam_protected_net_fqdn
4559 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4561 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4564 The property instance\_ip\_address uses the same parameter naming
4565 convention as the property fixed\_ips and Map Property subnet\_id in
4566 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4567 Address. The {network-role} has been defined as “oam\_protected” to
4568 represent an oam protected network and the {vm-type} has been defined as
4571 .. code-block:: yaml
4573 CMD_FW_SGI_PROTECTED_RII:
4574 type: OS::ContrailV2::InstanceIp
4576 - FW_OAM_PROTECTED_RVMI
4578 virtual_machine_interface_refs:
4579 - get_resource: FW_OAM_PROTECTED_RVMI
4580 virtual_network_refs:
4581 - get_param: oam_protected_net_fqdn
4582 subnet_uuid: { get_param: oam_protected_subnet_id }
4584 Cinder Volume Templates
4585 ^^^^^^^^^^^^^^^^^^^^^^^^
4587 ONAP supports the independent deployment of a Cinder volume via separate
4588 Heat Orchestration Templates, the Cinder Volume module. This allows the
4589 volume to persist after VNF deletion so that they can be reused on
4590 another instance (e.g., during a failover activity).
4592 A Base Module or Incremental Module may have a corresponding volume
4593 module. Use of separate volume modules is optional. A Cinder volume may
4594 be embedded within the Base Module or Incremental Module if persistence
4597 R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 scope of a cinder volume module,
4598 when it exists, with the Base Module or Incremental Module
4600 A single volume module must create only the volumes
4601 required by a single Incremental module or Base module.
4603 The following rules apply to independent volume Heat templates:
4605 - Cinder volumes must be created in a separate Heat Orchestration
4606 Template from the Base Module or Incremental Module.
4608 - A single Cinder volume module must include all Cinder volumes
4609 needed by the Base/Incremental module.
4611 - R-79531 The VNF Heat Orchestration Template **MUST** define “outputs” in the volume
4612 template for each Cinder volume resource universally unique
4613 identifier (UUID) (i.e. ONAP Volume Template Output Parameters).
4615 - The VNF Incremental Module or Base Module must define input
4616 parameters that match each Volume output parameter (i.e., ONAP Volume
4617 Template Output Parameters).
4619 - ONAP will supply the volume template outputs automatically to the
4620 bases/incremental template input parameters.
4622 - Volume modules may utilize nested Heat templates.
4624 *Examples: Volume Template*
4626 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4627 creates an independent Cinder volume for a VM in the module
4628 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4629 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4630 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4631 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4632 output statement and provides the value to the incremental module.
4634 Note that the example below is not a complete Heat Orchestration
4635 Template. The {vm-type} has been defined as “lb” for load balancer
4637 incremental\_volume.yaml
4639 .. code-block:: yaml
4650 type: OS::Cinder::Volume
4654 template: VNF_NAME_volume_0
4656 VNF_NAME: { get_param: vnf_name }
4657 size: {get_param: dns_volume_size_0}
4662 value: {get_resource: dns_volume_0}
4668 .. code-block:: yaml
4679 type: OS::Nova::Server
4681 name: {get_param: dns_name_0}
4686 type: OS::Cinder::VolumeAttachment
4688 instance_uuid: { get_resource: lb_0 }
4689 volume_id: { get_param: lb_volume_id_0 }
4691 ONAP Support of Environment Files
4692 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4694 The use of an environment file in OpenStack is optional. In ONAP, it is
4697 R-86285 The VNF Heat Orchestration Template **MUST** have a
4698 corresponding environment file, even if no parameters are required to be
4701 (Note that ONAP, the open source version of ONAP, does not
4702 programmatically enforce the use of an environment file.)
4704 R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
4705 environment file for a Base Module.
4707 R-35727 The VNF Heat Orchestration Template **MUST** have a
4708 corresponding environment file for an Incremental module.
4710 R-22656 The VNF Heat Orchestration Template **MUST** have a corresponding environment file
4711 for a Cinder Volume Module.
4713 A nested heat template must not have an environment file; OpenStack does
4716 The environment file must contain parameter values for the ONAP
4717 Orchestration Constants and VNF Orchestration Constants. These
4718 parameters are identical across all instances of a VNF type, and
4719 expected to change infrequently. The ONAP Orchestration Constants are
4720 associated with OS::Nova::Server image and flavor properties (See
4721 `Property: image`_ and `Property: flavor`_). Examples of VNF
4722 Orchestration Constants are the networking parameters associated
4723 with an internal network (e.g., private IP ranges) and Cinder
4726 The environment file must not contain parameter values for parameters
4727 that are instance specific (ONAP Orchestration Parameters, VNF
4728 Orchestration Parameters). These parameters are supplied to the Heat by
4729 ONAP at orchestration time.
4731 SDC Treatment of Environment Files
4732 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4734 Parameter values enumerated in the environment file are used by SDC as
4735 the default value. However, the SDC user may use the SDC GUI to
4736 overwrite the default values in the environment file.
4738 SDC generates a new environment file for distribution to MSO based on
4739 the uploaded environment file and the user provided GUI updates. The
4740 user uploaded environment file is discarded when the new file is
4741 created. Note that if the user did not change any values via GUI
4742 updates, the SDC generated environment file will contain the same values
4743 as the uploaded file.
4745 Use of Environment Files when using OpenStack “heat stack-create” CLI
4746 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4748 When ONAP is instantiating the Heat Orchestration Template, certain
4749 parameter must not be enumerated in the environment file. This document
4750 provides the details of what parameters should not be enumerated.
4752 If the Heat Orchestration Template is to be instantiated from the
4753 OpenStack Command Line Interface (CLI) using the command “heat
4754 stack-create”, all parameters must be enumerated in the environment
4757 Heat Template Constructs
4758 ^^^^^^^^^^^^^^^^^^^^^^^^^
4760 Nested Heat Templates
4761 ~~~~~~~~~~~~~~~~~~~~~~~
4763 ONAP supports nested Heat templates per the OpenStack specifications.
4764 Nested templates may be suitable for larger VNFs that contain many
4765 repeated instances of the same VM type(s). A common usage pattern is to
4766 create a nested template for each {vm-type} along with its supporting
4767 resources. The VNF module may then reference these component templates
4768 either statically by repeated definition or dynamically by using the
4769 resource OS::Heat::ResourceGroup.
4771 Nested Heat Template Requirements
4772 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4774 ONAP supports nested Heat Orchestration Templates. A Base Module,
4775 Incremental Module, and Cinder Volume Module may use nested heat.
4777 A Heat Orchestration Template may reference the nested heat statically
4778 by repeated definition.
4780 A Heat Orchestration Template may reference the nested heat dynamically
4781 using the resource OS::Heat::ResourceGroup.
4783 A Heat Orchestration template must have no more than three levels of
4784 nesting. ONAP supports a maximum of three levels.
4786 Nested heat templates must be referenced by file name. The use of
4787 resource\_registry in the environment file is not supported and must not
4790 R-89868 The VNF Heat Orchestration Template **MUST** have unique file names within the scope
4791 of the VNF for a nested heat yaml file.
4793 R-52530 The VNF Heat Orchestration Template **MUST NOT** use a directory hierarchy for
4794 nested templates. All templates must be in a single, flat directory
4797 A nested heat template may be used by any module within a given VNF.
4801 - Constrains must not be defined for any parameter enumerated in a
4802 nested heat template.
4804 - R-11041 The VNF Heat Orchestration Template **MUST** have the resource calling the
4805 nested yaml file pass in as properties all parameters defined
4806 in nested yaml file.
4808 - R-61183 The VNF Heat Orchestration Template **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat
4811 - With nested templates, outputs are required to expose any resource
4812 properties of the child templates to the parent template. Those would
4813 not explicitly be declared as parameters but simply referenced as
4814 get\_attribute targets against the “parent” resource.
4816 Nested Heat Template Example: Static
4817 ++++++++++++++++++++++++++++++++++++++
4821 .. code-block:: yaml
4827 dns_image_name: { get_param: dns_image_name }
4828 dns_flavor_name: { get_param: dns_flavor_name }
4829 availability_zone: { get_param: availability_zone_0 }
4830 security_group: { get_param: DNS_shared_sec_grp_id }
4831 oam_net_id: { get_param: oam_protected_net_id }
4832 dns_oam_ip: { get_param: dns_oam_ip_0 }
4833 dns_name: { get_param: dns_name_0 }
4834 vnf_name: { get_param: vnf_name }
4835 vnf_id: { get_param: vnf_id }
4836 vf_module_id: {get_param: vf_module_id}
4841 dns_image_name: { get_param: dns_image_name }
4842 dns_flavor_name: { get_param: dns_flavor_name }
4843 availability_zone: { get_param: availability_zone_1 }
4844 security_group: { get_param: DNS_shared_sec_grp_id }
4845 oam_net_id: { get_param: oam_protected_net_id }
4846 dns_oam_ip: { get_param: dns_oam_ip_1 }
4847 dns_name: { get_param: dns_name_1 }
4848 vnf_name: { get_param: vnf_name }
4849 vnf_id: { get_param: vnf_id }
4850 vf_module_id: {get_param: vf_module_id}
4854 .. code-block:: yaml
4857 type: OS::Neutron::Port
4861 template: VNF_NAME_dns_oam_port
4863 VNF_NAME: {get_param: vnf_name}
4864 network: { get_param: oam_net_id }
4865 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4866 security_groups: [{ get_param: security_group }]
4869 type: OS::Nova::Server
4871 name: { get_param: dns_names }
4872 image: { get_param: dns_image_name }
4873 flavor: { get_param: dns_flavor_name }
4874 availability_zone: { get_param: availability_zone }
4876 - port: { get_resource: dns_oam_0_port }
4878 vnf_id: { get_param: vnf_id }
4879 vf_module_id: { get_param: vf_module_id }
4880 vnf_name {get_param: vnf_name }
4882 Use of Heat ResourceGroup
4883 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4885 The OS::Heat::ResourceGroup is a useful Heat element for creating
4886 multiple instances of a given resource or collection of resources.
4887 Typically, it is used with a nested Heat template, to create, for
4888 example, a set of identical OS::Nova::Server resources plus their
4889 related OS::Neutron::Port resources via a single resource in a master
4892 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4893 template that creates multiple instances of the same VM type.
4895 However, there are important caveats to be aware of:
4897 ResourceGroup does not deal with structured parameters
4898 (comma-delimited-list and json) as one might typically expect. In
4899 particular, when using a list-based parameter, where each list element
4900 corresponds to one instance of the ResourceGroup, it is not possible to
4901 use the intrinsic “loop variable” %index% in the ResourceGroup
4904 For instance, the following is **not** valid Heat for ResourceGroup:
4906 .. code-block:: yaml
4908 type: OS::Heat::ResourceGroup
4910 type: my_nested_vm_template.yaml
4912 name: {get_param: [vm_name_list, %index%]}
4914 Although this appears to use the nth entry of the vm\_name\_list list
4915 for the nth element of the ResourceGroup, it will in fact result in a
4916 Heat exception. When parameters are provided as a list (one for each
4917 element of a ResourceGroup), you must pass the complete parameter to the
4918 nested template along with the current index as separate parameters.
4920 Below is an example of an **acceptable** Heat Syntax for a
4923 .. code-block:: yaml
4925 type: OS::Heat::ResourceGroup
4927 type: my_nested_vm_template.yaml
4929 names: {get_param: vm_name_list}
4932 You can then reference within the nested template as:
4934 { get\_param: [names, {get\_param: index} ] }
4936 ResourceGroup Property count
4937 +++++++++++++++++++++++++++++
4939 ONAP requires that the OS::Heat::ResourceGroup property count be defined
4940 (even if the value is one) and that the value must be enumerated in the
4941 environment file. This is required for ONAP to build the TOSCA model for
4944 .. code-block:: yaml
4946 type: OS::Heat::ResourceGroup
4948 count: { get_param: count }
4951 type: my_nested_vm_template.yaml
4953 names: {get_param: vm_name_list}
4956 Availability Zone and ResourceGroups
4957 +++++++++++++++++++++++++++++++++++++
4959 The resource OS::Heat::ResourceGroup and the property availability\_zone
4960 has been an “issue” with a few VNFs since ONAP only supports
4961 availability\_zone as a string parameter and not a
4962 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
4963 to create Virtual Machines in more than one availability zone.
4965 There are numerous solutions to this issue. Below are two suggested
4968 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
4969 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
4970 availability\_zones by using the intrinsic function list\_join.
4972 .. code-block:: yaml
4975 type: OS::Heat::ResourceGroup
4977 count: { get_param: node_count }
4983 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
4987 .. code-block:: yaml
4990 avaialability_zones:
4991 type: comma_delimited_list
4996 type: OS::Nova::Server
4998 name: { get_param: [ dns_names, get_param: index ] }
4999 image: { get_param: dns_image_name }
5000 flavor: { get_param: dns_flavor_name }
5001 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
5004 **Option 2:** Create a resource group per availability zone. A separate
5005 OS::Heat::ResourceGroup is created for each availability zone.
5008 ^^^^^^^^^^^^^^^^^^^^
5010 Heat templates *should not* reference any HTTP-based resource
5011 definitions, any HTTP-based nested configurations, or any HTTP-based
5014 - During orchestration, ONAP *should not* retrieve any such resources
5015 from external/untrusted/unknown sources.
5017 - VNF images should not contain such references in user-data or other
5018 configuration/operational scripts that are specified via Heat or
5019 encoded into the VNF image itself.
5021 *Note:* HTTP-based references are acceptable if the HTTP-based reference
5022 is accessing information with the VM private/internal network.
5024 Heat Files Support (get\_file)
5025 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5027 Heat Templates may contain the inclusion of text files into Heat
5028 templates via the Heat get\_file directive. This may be used, for
5029 example, to define a common “user-data” script, or to inject files into
5030 a VM on startup via the “personality” property.
5032 Support for Heat Files is subject to the following limitations:
5034 R-76718 The VNF Heat Orchestration Template **MUST** reference the get\_files targets in
5035 Heat templates by file name, and the corresponding files should be
5036 delivered to ONAP along with the Heat templates.
5038 R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
5040 R-62177 The VNF Heat Orchestration Template **MUST** have unique file names for the included
5041 files within the scope of the VNF.
5043 R-87848 The VNF Heat Orchestration Template **MUST** have all included files in a single, flat
5044 directory per VNF. ONAP does not support a directory hierarchy.
5046 - Included files may be used by all Modules within a given VNF.
5048 - get\_file directives may be used in both non-nested and nested
5054 When Nova Servers are created via Heat templates, they may be passed a
5055 “keypair” which provides an ssh key to the ‘root’ login on the newly
5056 created VM. This is often done so that an initial root key/password does
5057 not need to be hard-coded into the image.
5059 Key pairs are unusual in OpenStack, because they are the one resource
5060 that is owned by an OpenStack User as opposed to being owned by an
5061 OpenStack Tenant. As a result, they are usable only by the User that
5062 created the keypair. This causes a problem when a Heat template attempts
5063 to reference a keypair by name, because it assumes that the keypair was
5064 previously created by a specific ONAP user ID.
5066 When a keypair is assigned to a server, the SSH public-key is
5067 provisioned on the VMs at instantiation time. They keypair itself is not
5068 referenced further by the VM (i.e. if the keypair is updated with a new
5069 public key, it would only apply to subsequent VMs created with that
5072 Due to this behavior, the recommended usage of keypairs is in a more
5073 generic manner which does not require the pre-requisite creation of a
5074 keypair. The Heat should be structured in such a way as to:
5076 - Pass a public key as a parameter value instead of a keypair name
5078 - Create a new keypair within The VNF Heat Orchestration Template (in the base
5079 module) for use within that VNF
5081 By following this approach, the end result is the same as pre-creating
5082 the keypair using the public key – i.e., that public key will be
5083 provisioned in the new VM. However, this recommended approach also makes
5084 sure that a known public key is supplied (instead of having OpenStack
5085 generate a public/private pair to be saved and tracked outside of ONAP).
5086 It also removes any access/ownership issues over the created keypair.
5088 The public keys may be enumerated as a VNF Orchestration Constant in the
5089 environment file (since it is public, it is not a secret key), or passed
5090 at run-time as instance-specific parameters. ONAP will never
5091 automatically assign a public/private key pair.
5093 *Example (create keypair with an existing ssh public-key for {vm-type}
5094 of lb (for load balancer)):*
5096 .. code-block:: yaml
5106 type: OS::Nova::Keypair
5110 template: VNF_NAME_key_pair
5112 VNF_NAME: { get_param: vnf_name }
5113 public_key: {get_param: lb_ssh_public_key}
5114 save_private_key: false
5119 OpenStack allows a tenant to create Security groups and define rules
5120 within the security groups.
5122 Security groups, with their rules, may either be created in the Heat
5123 Orchestration Template or they can be pre-created in OpenStack and
5124 referenced within the Heat template via parameter(s). There can be a
5125 different approach for security groups assigned to ports on internal
5126 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
5127 there can be a common security group across all VMs for a specific
5128 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
5131 Anti-Affinity and Affinity Rules
5132 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5134 Anti-affinity or affinity rules are supported using normal OpenStack
5135 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
5136 created for each VM type to prevent them from residing on the same host,
5137 but they can be applied to multiple VM types to extend the
5138 affinity/anti-affinity across related VM types as well.
5142 In this example, the {network-role} has been defined as oam to represent
5143 an oam network and the {vm-type} have been defined as lb for load
5144 balancer and db for database.
5146 .. code-block:: yaml
5150 type: OS::Nova::ServerGroup
5155 $vnf_name: {get_param: vnf_name}
5156 template: $vnf_name-server_group1
5161 type: OS::Nova::ServerGroup
5166 $vnf_name: {get_param: vnf_name}
5167 template: $vnf_name-server_group2
5172 type: OS::Nova::Server
5176 group: {get_resource: db_server_group}
5179 type: OS::Nova::Server
5183 group: {get_resource: db_server_group}
5186 type: OS::Nova::Server
5190 group: {get_resource: lb_server_group}
5192 Resource Data Synchronization
5193 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5195 For cases where synchronization is required in the orchestration of Heat
5196 resources, two approaches are recommended:
5198 - Standard Heat depends\_on property for resources
5200 - Assures that one resource completes before the dependent resource
5203 - Definition of completeness to OpenStack may not be sufficient
5204 (e.g., a VM is considered complete by OpenStack when it is ready
5205 to be booted, not when the application is up and running).
5207 - Use of Heat Notifications
5209 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5212 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5214 - Dependent resource define depends\_on in the
5215 OS::Heat::WaitCondition resource.
5217 *Example: “depends\_on” case*
5219 In this example, the {network-role} has been defined as oam to represent
5220 an oam network and the {vm-type} has been defined as oam to represent an
5223 .. code-block:: yaml
5227 type: OS::Nova::Server
5229 name: {get_param: [oam_ names, 0]}
5230 image: {get_param: oam_image_name}
5231 flavor: {get_param: oam_flavor_name}
5232 availability_zone: {get_param: availability_zone_0}
5234 - port: {get_resource: oam01_port_0}
5235 - port: {get_resource: oam01_port_1}
5237 scheduler_hints: {group: {get_resource: oam_servergroup}}
5238 user_data_format: RAW
5241 type: OS::Neutron::Port
5243 network: {get_resource: oam_net_name}
5244 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5245 security_groups: [{get_resource: oam_security_group}]
5248 type: OS::Neutron::Port
5250 network: {get_param: oam_net_name}
5251 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5252 security_groups: [{get_resource: oam_security_group}]
5254 oam_01_vol_attachment:
5255 type: OS::Cinder::VolumeAttachment
5256 depends_on: oam_server_01
5258 volume_id: {get_param: oam_vol_1}
5259 mountpoint: /dev/vdb
5260 instance_uuid: {get_resource: oam_server_01}
5263 ^^^^^^^^^^^^^^^^^^^^
5265 VNF/VM parameters may include availability zone IDs for VNFs that
5266 require high availability.
5268 The Heat must comply with the following requirements to specific
5269 availability zone IDs:
5271 - The Heat template should spread Nova and Cinder resources across the
5272 availability zones as desired
5274 Post Orchestration & VNF Configuration
5275 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5277 Heat templates should contain a minimum amount of post-orchestration
5278 configuration data. For instance, *do not* embed complex user-data
5279 scripts in the template with large numbers of configuration parameters
5280 to the Heat template.
5282 - VNFs may provide configuration APIs for use after VNF creation. Such
5283 APIs will be invoked via application and/or SDN controllers.
5285 *Note:* It is important to follow this convention to the extent possible
5286 even in the short-term as of the long-term direction.
5288 VNFM Driver Development Steps
5289 -----------------------------------------------------------
5291 Refer to the ONAP documentation for VNF Provider instructions on integrating
5292 vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
5295 1. Use the VNF SDK tools to design the VNF with TOSCA models to output
5296 the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
5297 validated and tested.
5299 2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
5300 is a microservice providing a translation interface from VF-C to
5301 the vendor-specific VNFM. The interface definitions of vendor-specific
5302 VNFM adaptors are supplied by the VNF Providers themselves.
5304 Creating Vendor-Specific VNFM Adaptor Microservices
5305 ------------------------------------------------------------------------------------------------
5307 VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific
5308 VNFM to ONAP, a vendor-specific VNFM adaptor is added to ONAP implementing
5309 the interface of the vendor-specific VNFM.
5311 A vendor-specific VNFM adaptor is a microservice with a unique name and
5312 an appointed port. When started up, the vendor-specific VNFM adaptor
5313 microservice is automatically registered to the Microservices Bus (MSB).
5314 The following RESTful example describes the scenario of registering a
5315 vendor-specific VNFM adaptor to MSB:
5317 .. code-block:: java
5319 POST /api/microservices/v1/services
5321 "serviceName": "catalog",
5323 "url": "/api/catalog/v1",
5328 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob