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 =========================
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 with aggreed
132 changes from ETSI SOL001 draft.
134 +---------------------+------------------------------------+-----------------+
135 | **ETSI NFV Element**| **TOSCA VNFD** | **Derived from**|
137 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]**| |
138 +=====================+====================================+=================+
139 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root|
140 +---------------------+------------------------------------+-----------------+
141 | Cpd (Connection | tosca.nodes.nfv.Cp | tosca.nodes.Root|
142 | Point) | tosca.nodes.nfv.Cp | tosca.nodes.Root|
143 +---------------------+------------------------------------+-----------------+
144 | VduCpd (internal | tosca.nodes.nfv.VduCp | tosca.nodes.\ |
145 | connection point) | | nfv.Cp |
146 +---------------------+------------------------------------+-----------------+
147 | VnfVirtualLinkDesc | tosca.nodes.nfv.VnfVirtualLink | tosca.nodes.Root|
148 | (Virtual Link) | | |
149 +---------------------+------------------------------------+-----------------+
150 | VDU Virtual Storage | tosca.nodes.nfv.VDU.VirtualStorage | tosca.nodes.Root|
151 +---------------------+------------------------------------+-----------------+
152 | VDU Virtual Compute | tosca.nodes.nfv.VDU.Compute | tosca.nodes.Root|
153 +---------------------+------------------------------------+-----------------+
154 | Software Image | | |
155 +---------------------+------------------------------------+-----------------+
156 | Deployment Flavour | | |
157 +---------------------+------------------------------------+-----------------+
158 | Scaling Aspect | | |
159 +---------------------+------------------------------------+-----------------+
160 | Element Group | | |
161 +---------------------+------------------------------------+-----------------+
162 | Instantiation | | |
164 +---------------------+------------------------------------+-----------------+
167 +--------------------------------------------------------------------+
168 | +--------------------------------------------------------------+ |
169 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
171 | | description: VNFD TOSCA file demo | |
175 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
177 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
179 | | | **node\_types: | |
180 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
181 | | derived\_from:** tosca.nodes.nfv.VNF | |
182 | | | **requirements: | |
183 | | **- **sriov\_plane: | |
184 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
185 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
186 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
187 | +--------------------------------------------------------------+ |
188 +====================================================================+
189 +--------------------------------------------------------------------+
194 1. SR-IOV Passthrought
196 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
199 +------------------------------------------------+
208 | tosca\_name: SRIOV\_Port |
212 | virtual\_network\_interface\_requirements: |
216 | support\_mandatory: false |
218 | description: sriov |
226 | description: sriov port |
228 | layer\_protocol: ipv4 |
232 | - virtual\_binding: |
234 | capability: virtual\_binding |
240 | type: tosca.relationships.nfv.VirtualBindsTo |
244 | node: tosca.nodes.Root |
246 | type: tosca.nodes.nfv.VduCpd |
248 | substitution\_mappings: |
258 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
259 +------------------------------------------------+
263 Definitions of mem\_page\_size as one property shall be added to
264 Properties and set the value to large if one VDU node supports
265 huagepages. Here is an example.
267 +----------------------------------+
276 | tosca\_name: Huge\_pages\_demo |
280 | mem\_page\_size:large |
281 +==================================+
282 +----------------------------------+
286 Likewise, we shall add definitions of numa to
287 requested\_additional\_capabilities if we wand VUD nodes to support
288 NUMA. Here is an example.
290 +-------------------------------------------------+
291 | topology\_template: |
299 | virtual\_compute: |
305 | numa\_enabled: true |
307 | virtual\_mem\_size: 2 GB |
309 | requested\_additional\_capabilities: |
313 | support\_mandatory: true |
315 | requested\_additional\_capability\_name: numa |
317 | target\_performance\_parameters: |
319 | hw:numa\_nodes: "2" |
321 | hw:numa\_cpus.0: "0,1" |
323 | hw:numa\_mem.0: "1024" |
325 | hw:numa\_cpus.1: "2,3,4,5" |
327 | hw:numa\_mem.1: "1024" |
328 +-------------------------------------------------+
332 Definitions of Hyper-Theading are necessary as one of
333 requested\_additional\_capabilities of one VUD node if that node
334 supports Hyper-Theading. Here is an example.
336 +-------------------------------------------------------------+
337 | topology\_template: |
345 | virtual\_compute: |
351 | numa\_enabled: true |
353 | virtual\_mem\_size: 2 GB |
355 | requested\_additional\_capabilities: |
357 | hyper\_threading: |
359 | support\_mandatory: true |
361 | requested\_additional\_capability\_name: hyper\_threading |
363 | target\_performance\_parameters: |
365 | hw:cpu\_sockets : "2" |
367 | hw:cpu\_threads : "2" |
369 | hw:cpu\_cores : "2" |
371 | hw:cpu\_threads\_policy: "isolate" |
372 +-------------------------------------------------------------+
376 Definitions of ovs\_dpdk are necessary as one of
377 requested\_additional\_capabilities of one VUD node if that node
378 supports dpdk. Here is an example.
380 +------------------------------------------------------+
381 | topology\_template: |
389 | virtual\_compute: |
395 | numa\_enabled: true |
397 | virtual\_mem\_size: 2 GB |
399 | requested\_additional\_capabilities: |
403 | support\_mandatory: true |
405 | requested\_additional\_capability\_name: ovs\_dpdk |
407 | target\_performance\_parameters: |
409 | sw:ovs\_dpdk: "true" |
410 +------------------------------------------------------+
412 NFV TOSCA Type Definition
413 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
415 tosca.capabilites.nfv.VirtualCompute
416 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418 This capability is used with the properties specified in ETSI SOL001 draft.
420 tosca.nodes.nfv.VDU.Compute
421 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
423 The NFV Virtualization Deployment Unit (VDU) compute node type
424 represents a VDU entity which it describes the deployment and
425 operational behavior of a VNF component (VNFC), as defined by **[ETSI
428 +-----------------------+-------------------------------+
429 | Shorthand Name | VDU.Compute |
430 +=======================+===============================+
431 | Type Qualified Name | tosca:VDU.Compute |
432 +-----------------------+-------------------------------+
433 | Type URI | tosca.nodes.nfv.VDU.Compute |
434 +-----------------------+-------------------------------+
435 | derived\_from | tosca.nodes.Compute |
436 +-----------------------+-------------------------------+
449 +------------+--------------------+------------+------------------------------+
450 | Name | Type | Constraints| Description |
451 +============+====================+============+==============================+
452 | virtual\ | tosca.\ | | Describes virtual compute |
453 | _compute | capabilities.nfv.\ | | resources capabilities. |
454 | | VirtualCompute | | |
455 +------------+--------------------+------------+------------------------------+
456 | monitoring\| tosca.\ | None | Monitoring parameter, which |
457 | _parameter | capabilities.nfv.\ | | can be tracked for a VNFC |
458 | | Metric | | based on this VDU |
460 | | | | Examples include: |
461 | | | | memory-consumption, |
462 | | | | CPU-utilisation, |
463 | | | | bandwidth-consumption, VNFC |
464 | | | | downtime, etc. |
465 +------------+--------------------+------------+------------------------------+
466 | Virtual\ | tosca.\ | | Defines ability of |
467 | _binding | capabilities.nfv.\ | | VirtualBindable |
468 | | VirtualBindable | | |
470 | | editor note: need | | |
471 | | to create a | | |
472 | | capability type | | |
473 +------------+--------------------+------------+------------------------------+
478 +-----------------------------------------------------------------------------+
479 | tosca.nodes.nfv.VDU.Compute: |
481 | derived\_from: tosca.nodes.Compute |
499 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
507 | nfvi\_constraints: |
517 | configurable\_properties: |
523 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
529 | private\_address: |
531 | status: deprecated |
535 | status: deprecated |
539 | status: deprecated |
543 | status: deprecated |
547 | virtual\_compute: |
549 | type: tosca.capabilities.nfv.VirtualCompute |
551 | virtual\_binding: |
553 | type: tosca.capabilities.nfv.VirtualBindable |
555 | #monitoring\_parameter: |
557 | # modeled as ad hoc (named) capabilities in VDU node template |
563 | # cpu\_load: tosca.capabilities.nfv.Metric |
565 | # memory\_usage: tosca.capabilities.nfv.Metric |
567 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile|
569 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__|
571 | valid\_source\_types: |
572 | [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
574 | occurrences: [0,UNBOUNDED] |
578 | occurrences: [0,0] |
582 | occurrences: [0,0] |
585 | #Editor note: FFS. How this capabilities should be used in NFV Profile |
587 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
591 | occurrences: [0,UNBOUND] |
595 | - virtual\_storage: |
597 | capability: tosca.capabilities.nfv.VirtualStorage |
599 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
601 | node: tosca.nodes.nfv.VDU.VirtualStorage |
603 | occurences: [ 0, UNBOUNDED ] |
605 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
607 | occurrences: [0,0] |
615 | type: tosca.artifacts.nfv.SwImage |
616 +-----------------------------------------------------------------------------+
621 Note: currently not supported.
623 +--------+---------+----------------+------------+------------------------+
624 | Name | Required| Type | Constraints| Description |
625 +========+=========+================+============+========================+
626 | SwImage| Yes | tosca.\ | | Describes the software |
627 | | | artifacts.nfv.\| | image which is directly|
628 | | | SwImage | | realizing this virtual |
630 +--------+---------+----------------+------------+------------------------+
637 tosca.nodes.nfv.VDU.VirtualStorage
638 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
640 The NFV VirtualStorage node type represents a virtual storage entity
641 which it describes the deployment and operational behavior of a virtual
642 storage resources, as defined by **[ETSI NFV IFA011].**
644 **[editor note]** open issue: should NFV profile use the current storage
645 model as described in YAML 1.1. Pending on Shitao proposal (see
646 NFVIFA(17)000110 discussion paper)
648 **[editor note]** new relationship type as suggested in Matt
649 presentation. Slide 8. With specific rules of “valid\_target\_type”
651 +---------------------------+--------------------------------------+
652 | **Shorthand Name** | VirtualStorage |
653 +===========================+======================================+
654 | **Type Qualified Name** | tosca: VirtualStorage |
655 +---------------------------+--------------------------------------+
656 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
657 +---------------------------+--------------------------------------+
658 | **derived\_from** | tosca.nodes.Root |
659 +---------------------------+--------------------------------------+
661 tosca.artifacts.nfv.SwImage
662 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
664 +---------------------------+------------------------------------+
665 | **Shorthand Name** | SwImage |
666 +===========================+====================================+
667 | **Type Qualified Name** | tosca:SwImage |
668 +---------------------------+------------------------------------+
669 | **Type URI** | tosca.artifacts.nfv.SwImage |
670 +---------------------------+------------------------------------+
671 | **derived\_from** | tosca.artifacts.Deployment.Image |
672 +---------------------------+------------------------------------+
677 +-----------------+---------+----------+------------+-------------------------+
678 | Name | Required| Type | Constraints| Description |
679 +=================+=========+==========+============+=========================+
680 | name | yes | string | | Name of this software |
682 +-----------------+---------+----------+------------+-------------------------+
683 | version | yes | string | | Version of this software|
685 +-----------------+---------+----------+------------+-------------------------+
686 | checksum | yes | string | | Checksum of the software|
687 | | | | | image file |
688 +-----------------+---------+----------+------------+-------------------------+
689 | container\ | yes | string | | The container format |
690 | _format | | | | describes the container |
691 | | | | | file format in which |
692 | | | | | software image is |
693 | | | | | provided. |
694 +-----------------+---------+----------+------------+-------------------------+
695 | disk\_format | yes | string | | The disk format of a |
696 | | | | | software image is the |
697 | | | | | format of the underlying|
698 | | | | | disk image |
699 +-----------------+---------+----------+------------+-------------------------+
700 | min\_disk | yes | scalar-\ | | The minimal disk size |
701 | | | unit.size| | requirement for this |
702 | | | | | software image. |
703 +-----------------+---------+----------+------------+-------------------------+
704 | min\_ram | no | scalar-\ | | The minimal RAM |
705 | | | unit.size| | requirement for this |
706 | | | | | software image. |
707 +-----------------+---------+----------+------------+-------------------------+
708 | Size | yes | scalar-\ | | The size of this |
709 | | | unit.size| | software image |
710 +-----------------+---------+----------+------------+-------------------------+
711 | sw\_image | yes | string | | A reference to the |
712 | | | | | actual software image |
713 | | | | | within VNF Package, or |
715 +-----------------+---------+----------+------------+-------------------------+
716 | operating\ | no | string | | Identifies the operating|
717 | _system | | | | system used in the |
718 | | | | | software image. |
719 +-----------------+---------+----------+------------+-------------------------+
720 | supported\ | no | list | | Identifies the |
721 | _virtualization\| | | | virtualization |
722 | _enviroment | | | | environments (e.g. |
723 | | | | | hypervisor) compatible |
724 | | | | | with this software image|
725 +-----------------+---------+----------+------------+-------------------------+
730 +-----------------------------------------------------+
731 | tosca.artifacts.nfv.SwImage: |
733 | derived\_from: tosca.artifacts.Deployment.Image |
735 | properties or metadata: |
759 | container\_format: |
773 | type: scalar-unit.size # Number |
779 | type: scalar-unit.size # Number |
785 | type: scalar-unit.size # Number |
795 | operating\_system: |
801 | supported\_virtualisation\_environments: |
810 +-----------------------------------------------------+
812 .. |image1| image:: Image1.png
815 .. |image2| image:: Image2.png
825 This section contains general Heat Orchestration Template guidelines.
830 R-95303 A VNF's Heat Orchestration Template **MUST** be defined
834 Markup Language) is a human friendly data serialization standard for all
835 programming languages. See http://www.yaml.org/.
837 Heat Orchestration Template Format
838 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
840 As stated above, Heat Orchestration templates must be defined in YAML.
844 - Tabs are not allowed, use spaces ONLY
846 - You must indent your properties and lists with 1 or more spaces
848 - All Resource IDs and resource property parameters are
849 case-sensitive. (e.g., "ThIs", is not the same as "thiS")
851 Heat Orchestration Template Structure
852 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
854 Heat Orchestration template structure follows the following format,
855 as defined by OpenStack at
856 https://docs.openstack.org/developer/heat/template_guide/hot_spec.html
858 .. code-block:: python
860 heat_template_version: <date>
863 # a description of the template
866 # a declaration of input parameter groups and order
869 # declaration of input parameters
872 # declaration of template resources
875 # declaration of output parameters
878 # declaration of conditions
880 heat_template_version
881 +++++++++++++++++++++
883 R-27078 A VNF's Heat Orchestration template **MUST** contain
884 the section "heat_template_version:".
886 The section "heat_template_version:" must be set to a date
887 that is supported by the OpenStack environment.
892 R-39402 A VNF's Heat Orchestration Template **MUST**
893 contain the section "description:".
898 A VNF Heat Orchestration template may
899 contain the section "parameter_groups:".
904 R-35414 A VNF Heat Orchestration's template **MUST**
905 contain the section "parameters:".
908 .. code-block:: python
914 type: <string | number | json | comma_delimited_list | boolean>
916 label: <human-readable name of the parameter>
918 description: <description of the parameter>
920 default: <default value for parameter>
922 hidden: <true | false>
926 <parameter constraints>
928 immutable: <true | false>
930 This section allows for
931 specifying input parameters that have to be provided when instantiating
932 the template. Each parameter is specified in a separate nested block
933 with the name of the parameters defined in the first line and additional
934 attributes (e.g., type, label) defined as nested elements.
936 R-90279 A VNF Heat Orchestration's template's parameter **MUST**
937 be used in a resource with the exception of the parameters
938 for the OS::Nova::Server resource property availability_zone.
940 R-91273 A VNF Heat Orchestration’s template’s parameter for
941 the OS::Nova::Server resource property availability_zone
942 **MAY NOT** be used in any OS::Nova::Resource.
947 The name of the parameter.
949 R-25877 A VNF's Heat Orchestration Template's parameter
950 name (i.e., <param name>) **MUST** contain only
951 alphanumeric characters and underscores ('_').
956 R-36772 A VNF’s Heat Orchestration Template’s parameter
957 **MUST** include the attribute “type:”.
959 R-11441 A VNF’s Heat Orchestration Template’s parameter
960 type **MUST** be one of the following values: "string",
961 "number", "json", "comma_delimited_list" or "boolean".
966 R-32094 A VNF's Heat Orchestration Template parameter
967 declaration **MAY** contain the attribute "label:"
972 R-44001 A VNF's Heat Orchestration Template parameter
973 declaration **MUST** contain the attribute "description".
975 Note that the parameter attribute “description:” is an
976 OpenStack optional attribute that provides a description
977 of the parameter. ONAP implementation requires this attribute.
982 R-90526 A VNF Heat Orchestration Template parameter
983 declaration **MUST** not contain the default attribute.
985 R-26124 If a VNF Heat Orchestration Template parameter
986 requires a default value, it **MUST** be enumerated in the environment file.
988 Note that the parameter attribute “default:” is an OpenStack
989 optional attribute that declares the default value of the
990 parameter. ONAP implementation prohibits the use of this attribute.
995 R-32557 A VNF's Heat Orchestration Template parameter
996 declaration MAY contain the attribute "hidden:".
998 The parameter attribute "hidden:" is an OpenStack optional
999 attribute that defines whether the parameters should be
1000 hidden when a user requests information about a stack
1001 created from the template. This attribute can be used
1002 to hide passwords specified as parameters.
1007 The parameter attribute "constraints:" is an OpenStack optional
1008 attribute that defines a list of constraints to apply to the parameter.
1010 R-88863 A VNF's Heat Orchestration Template's parameter defined as
1011 type "number" **MUST** have a parameter constraint of "range" or
1012 "allowed_values" defined.
1014 R-40518 A VNF's Heat Orchestration Template’s parameter defined as
1015 type "string" **MAY** have a parameter constraint defined.
1017 R-96227 A VNF's Heat Orchestration Template’s parameter defined as
1018 type "json" **MAY** have a parameter constraint defined.
1020 R-79817 A VNF's Heat Orchestration Template’s parameter defined as
1021 type "comma_delimited_list" **MAY** have a parameter constraint defined.
1023 R-06613 A VNF's Heat Orchestration Template’s parameter defined as
1024 type "boolean" **MAY** have a parameter constraint defined.
1026 R-00011 A VNF's Heat Orchestration Template's Nested YAML files
1027 parameter's **MUST NOT** have a parameter constraint defined.
1029 The constraints block of a parameter definition defines additional
1030 validation constraints that apply to the value of the parameter.
1031 The parameter values provided in the VNF Heat Orchestration Template
1032 are validated against the constraints at instantiation time.
1033 The stack creation fails if the parameter value doesn’t comply to
1036 The constraints are defined as a list with the following syntax
1038 .. code-block:: python
1042 <constraint type>: <constraint definition>
1044 description: <constraint description>
1048 **<constraint type>** Provides the type of constraint to apply.
1049 The list of OpenStack supported constraints can be found at
1050 https://docs.openstack.org/heat/latest/template_guide/hot_spec.html .
1052 **<constraint definition>** provides the actual constraint.
1053 The syntax and constraint is dependent of the <constraint type> used.
1055 **description** is an optional attribute that provides a description of the
1056 constraint. The text is presented to the user when the value the user
1057 defines violates the constraint. If omitted, a default validation
1058 message is presented to the user.
1060 Below is a brief overview of the "range" and "allowed values" constraints.
1061 For complete details on constraints, see
1062 https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#parameter-constraints
1066 range: The range constraint applies to parameters of type: number.
1067 It defines a lower and upper limit for the numeric value of the
1068 parameter. The syntax of the range constraint is
1070 .. code-block:: python
1072 range: { min: <lower limit>, max: <upper limit> }
1076 It is possible to define a range constraint with only a lower
1077 limit or an upper limit.
1081 allowed_values: The allowed_values constraint applies to parameters of
1082 type \"string\" or type \"number\". It specifies a set of possible
1083 values for a parameter. At deployment time, the user-provided value
1084 for the respective parameter must match one of the elements of the
1085 list. The syntax of the allowed_values constraint is
1087 .. code-block:: python
1089 allowed_values: [ <value>, <value>, ... ]
1091 Alternatively, the following YAML list notation can be used
1106 R-22589 A VNF’s Heat Orchestration Template parameter declaration
1107 **MAY** contain the attribute "immutable:".
1109 The parameter attribute \"immutable:\" is an OpenStack optional
1110 attribute that defines whether the parameter is updatable. A Heat
1111 Orchestration Template stack update fails if immutable is set to
1112 true and the parameter value is changed. This attribute
1113 \"immutable:\" defaults to false.
1118 R-23664 A VNF's Heat Orchestration template **MUST** contain
1119 the section "resources:".
1121 R-90152 A VNF's Heat Orchestration Template's "resources:"
1122 section **MUST** contain the declaration of at least one resource.
1124 R-40551 A VNF's Heat Orchestration Template's Nested YAML files
1125 **MAY** contain the section "resources:".
1127 Each resource is defined as a
1128 separate block in the resources section with the following syntax.
1130 .. code-block:: python
1136 type: <resource type>
1140 <property name>: <property value>
1144 <resource specific metadata>
1146 depends_on: <resource ID or list of ID>
1148 update_policy: <update policy>
1150 deletion_policy: <deletion policy>
1152 external_id: <external resource ID>
1154 condition: <condition name or expression or boolean>
1161 R-75141 A VNF's Heat Orchestration Template's resource name
1162 (i.e., <resource ID>) **MUST** only contain alphanumeric
1163 characters and underscores ('_').
1165 R-16447 A VNF's <resource ID> **MUST** be unique across all
1166 Heat Orchestration Templates and all HEAT Orchestration Template
1167 Nested YAML files that are used to create the VNF.
1169 Note that a VNF can be composed of one or more Heat Orchestration Templates.
1171 Note that OpenStack requires the <resource ID> to be unique to the
1172 Heat Orchestration Template and not unique across all Heat
1173 Orchestration Templates the compose the VNF.
1178 The resource attribute \"type:\" is an OpenStack required
1179 attribute that defines the resource type, such as
1180 OS::Nova::Server or OS::Neutron::Port.
1182 The resource attribute \"type:\" may specify a VNF HEAT
1183 Orchestration Template Nested YAML file.
1185 R-53952 A VNF’s Heat Orchestration Template’s Resource
1186 **MUST NOT** reference a HTTP-based resource definitions.
1188 R-71699 A VNF’s Heat Orchestration Template’s Resource
1189 **MUST NOT** reference a HTTP-based Nested YAML file.
1194 The resource attribute \"properties:\" is an OpenStack optional
1195 attribute that provides a list of resource-specific properties.
1196 The property value can be provided in place, or via a function
1197 (e.g., `Intrinsic functions <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-intrinsic-functions>`__).
1199 R-10834 If a VNF Heat Orchestration Template resource attribute
1200 "property:" uses a nested "get_param", one level of nesting is
1201 supported and the nested "get_param" **MUST** reference an index
1206 The resource attribute \"metadata:\" is an OpenStack optional attribute.
1208 R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
1209 resource **MUST** contain the attribute "metadata".
1211 Section 5.4 contains the OS::Nova::Server mandatory and optional metadata.
1217 The resource attribute \"depends_on:\" is an OpenStack optional
1219 See `OpenStack documentation <https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#hot-spec-resources-dependencies>`__
1220 for additional details.
1222 R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
1223 declare the attribute “depends_on:”.
1228 R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
1229 declare the attribute “update_policy:”.
1234 R-43740 A VNF’s Heat Orchestration Template’s Resource
1235 **MAY** declare the attribute “deletion_policy:”.
1237 If specified, the \"deletion_policy:\" attribute for resources
1238 allows values 'Delete', 'Retain', and 'Snapshot'.
1239 Starting with heat_template_version 2016-10-14, lowercase
1240 equivalents are also allowed.
1242 The default policy is to delete the physical resource when
1243 deleting a resource from the stack.
1248 R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
1249 declare the attribute “external_id:”.
1251 This attribute allows for specifying the resource_id for an
1252 existing external (to the stack) resource. External resources
1253 cannot depend on other resources, but we allow other resources to
1254 depend on external resource. This attribute is optional.
1255 Note: when this is specified, properties will not be used for
1256 building the resource and the resource is not managed by Heat.
1257 This is not possible to update that attribute. Also,
1258 resource won’t be deleted by heat when stack is deleted.
1264 The resource attribute \"condition:\" is an OpenStack optional attribute.
1266 Support for the resource condition attribute was added
1267 in the Newton release of OpenStack.
1272 R-36982 A VNF’s Heat Orchestration template **MAY**
1273 contain the “outputs:” section.
1275 This section allows for specifying output parameters
1276 available to users once the template has been instantiated. If the
1277 section is specified, it will need to adhere to specific requirements.
1278 See `ONAP Parameter Classifications Overview`_ and
1279 `ONAP Output Parameter Names`_ for additional details.
1281 Environment File Format
1282 ~~~~~~~~~~~~~~~~~~~~~~~
1284 The environment file is a yaml text file.
1285 (https://docs.openstack.org/developer/heat/template_guide/environment.html)
1287 R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
1288 environment file, even if no parameters are required to be enumerated.
1290 The use of an environment file in OpenStack is optional.
1291 In ONAP, it is mandatory.
1293 R-03324 The VNF Heat Orchestration Template **MUST** contain the
1294 "parameters" section in the
1297 R-68198 A VNF’s Heat Orchestration template’s Environment File’s
1298 “parameters:” section **MAY** enumerate parameters.
1300 ONAP implementation requires the parameters section in the
1301 environmental file to be declared. The parameters section
1302 contains a list of key/value pairs.
1304 R-59930 A VNF’s Heat Orchestration template’s Environment
1305 File’s **MAY** contain the “parameter_defaults:” section.
1307 The “parameter_defaults:” section contains default parameters
1308 that are passed to all template resources.
1310 R-46096 A VNF’s Heat Orchestration template’s Environment File’s
1311 **MAY** contain the “encrypted_parameters:” section.
1313 The “encrypted_parameters:” section contains a list of encrypted parameters.
1315 R-24893 A VNF’s Heat Orchestration template’s Environment File’s
1316 **MAY** contain the “event_sinks:” section.
1318 The “event_sinks:” section contains the list of endpoints that would
1319 receive stack events.
1321 R-42685 A VNF’s Heat Orchestration template’s Environment File’s
1322 **MAY** contain the “parameter_merge_strategies:” section.
1324 The “parameter_merge_strategies:” section provides the merge strategies
1325 for merging parameters and parameter defaults from the environment file.
1327 R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
1328 contain the “resource_registry:” section.
1330 ONAP implementation does not support the Environment File
1331 resource_registry section. The resource_registry section
1332 allows for the definition of custom resources.
1335 SDC Treatment of Environment Files
1336 ++++++++++++++++++++++++++++++++++
1338 Parameter values enumerated in the environment file are used by SDC as
1339 the default value. However, the SDC user may use the SDC GUI to
1340 overwrite the default values in the environment file.
1342 SDC generates a new environment file for distribution to MSO based on
1343 the uploaded environment file and the user provided GUI updates. The
1344 user uploaded environment file is discarded when the new file is
1347 ONAP has requirements for what parameters must be enumerated in the
1348 environment file and what parameter must not be enumerated in the
1349 environment file. See `ONAP Parameter Classifications Overview`_ and
1350 `ONAP Resource ID and Parameter Naming Convention`_ for more details.
1352 ONAP Heat Orchestration Templates: Overview
1353 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1355 ONAP supports a modular Heat Orchestration Template design pattern,
1356 referred to as *VNF Modularity.*
1358 ONAP VNF Modularity Overview
1359 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1361 R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
1362 Templates, each of which represents a subset of the overall VNF.
1364 The Heat Orchestration Templates can be thought of a components or
1365 modules of the VNF and are referred to as “\ *VNF Modules*\ ”.
1366 During orchestration, these modules are
1367 deployed incrementally to create the complete VNF.
1369 R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module
1370 Heat Orchestration Template (also referred to as a Base Module), 2.)
1371 Incremental Module Heat Orchestration Template (referred to as an Incremental
1372 Module), or 3.) a Cinder Volume Module Heat Orchestration Template
1373 (referred to as Cinder Volume Module).
1375 R-37028 The VNF **MUST** be composed of one “base” module.
1377 R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
1379 R-20974 The VNF **MUST** deploy the base module first, prior to
1380 the incremental modules.
1382 R-28980 A VNF’s incremental module **MAY** be used for initial VNF
1385 R-86926 A VNF’s incremental module **MAY** be used for scale out only.
1387 A VNF’s Incremental Module that is used for scale out is deployed
1388 sometime after initial VNF deployment to add capacity.
1390 R-91497 A VNF’s incremental module **MAY** be used for both deployment
1393 R-68122 A VNF’s incremental module **MAY** be deployed more than once,
1394 either during initial VNF deployment and/or scale out.
1396 R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
1397 **MAY** be defined in a Base Module.
1399 R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
1400 **MAY** be defined in an Incremental Module.
1402 R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
1403 **MAY** be defined in a Cinder Volume Module.
1405 ONAP also supports the concept of an optional, independently deployed Cinder
1406 volume via a separate Heat Orchestration Templates, referred to as a Cinder
1407 Volume Module. This allows the volume to persist after a Virtual Machine
1408 (VM) (i.e., OS::Nova::Server) is deleted, allowing the volume to be reused
1409 on another instance (e.g., during a failover activity).
1411 R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it
1412 exists, to be 1:1 with the VNF Base Module or Incremental Module
1414 It is strongly recommended that Cinder Volumes be created in a Cinder Volume
1417 R-38474 The VNF **MUST** have a corresponding environment file for a
1420 R-81725 The VNF **MUST** have a corresponding environment file for an
1423 R-53433 The VNF **MUST** have a corresponding environment file for a
1424 Cinder Volume Module.
1426 These concepts will be described in more detail throughout the document.
1427 This overview is provided to set the stage and help clarify the concepts
1428 that will be introduced.
1430 Nested Heat Orchestration Templates Overview
1431 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1433 ONAP supports nested Heat Orchestration Templates per OpenStack
1436 R-36582 A VNF’s Base Module **MAY** utilize nested heat.
1438 R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
1440 R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
1442 Nested templates may be suitable for larger VNFs that contain many
1443 repeated instances of the same VM type(s). A common usage pattern is to
1444 create a nested template for each VM type along with its supporting
1445 resources. The Heat Orchestration Template may then reference these
1446 nested templates either statically (by repeated definition) or
1447 dynamically (via OS::Heat::ResourceGroup).
1449 See `Nested Heat Templates`_ for additional details.
1451 ONAP Heat Orchestration Template Filenames
1452 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1454 In order to enable ONAP to understand the relationship between Heat
1455 files, the following Heat file naming convention must be utilized.
1457 In the examples below, <text> represents any alphanumeric string that
1458 must not contain any special characters and must not contain the word
1461 R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
1462 be in the lower case format ‘.yaml’ or ‘.yml’.
1464 R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
1465 **MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
1467 R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
1468 **MUST** be in the lower case format ‘.env’.
1473 R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST**
1474 include ‘base’ in the filename and **MUST** match one of the following four
1475 formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.)
1476 ‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case
1477 insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters
1478 and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’.
1480 R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File
1481 **MUST** be named identical to the VNF Heat Orchestration Template’s Base
1482 Module with ‘.y[a]ml’ replaced with ‘.env’.
1487 R-87247 A VNF Heat Orchestration Template’s Incremental Module file name
1488 **MUST** contain only alphanumeric characters and underscores ‘_’ and
1489 **MUST NOT** contain the case insensitive word ‘base’.
1491 R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment
1492 File **MUST** be named identical to the VNF Heat Orchestration Template’s
1493 Incremental Module with ‘.y[a]ml’ replaced with ‘.env’.
1495 To clearly identify the incremental module, it is recommended to use the
1496 following naming options for modules:
1498 - module_<text>.y[a]ml
1500 - <text>_module.y[a]ml
1504 - <text>_module_<text>.y[a]ml
1506 Cinder Volume Modules
1507 +++++++++++++++++++++
1509 R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be
1510 named identical to the base or incremental module it is supporting with
1513 R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment
1514 File **MUST** be named identical to the VNF Heat Orchestration Template’s
1515 Cinder Volume Module with .y[a]ml replaced with ‘.env’.
1520 R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST**
1521 contain only alphanumeric characters and underscores ‘_’ and **MUST NOT**
1522 contain the case insensitive word ‘base’.
1528 - nest_<text>.y[a]ml
1530 - <text>_nest.y[a]ml
1534 - <text>_nest_<text>.y[a]ml
1536 VNF Heat Orchestration Template's Nested YAML file does not have a
1537 corresponding environment files, per OpenStack specifications.
1539 R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties
1540 all parameter values
1541 associated with the nested heat file in the resource definition defined
1542 in the parent heat template.
1547 The output parameters are parameters defined in the output section of a
1548 Heat Orchestration Template. The ONAP output parameters are subdivided
1549 into three categories:
1551 1. ONAP Base Module Output Parameters
1553 2. ONAP Volume Module Output Parameters
1555 3. ONAP Predefined Output Parameters.
1557 ONAP Base Module Output Parameters
1558 ++++++++++++++++++++++++++++++++++++
1560 ONAP Base Module Output Parameters are declared in the 'outputs:'' section of
1561 the VNF's Heat Orchestration Template's Base Module. A Base Module Output
1562 Parameter is available as an input parameter (i.e., declared in the
1563 'parameters:'' section) to all Incremental Modules in the VNF.
1565 A Base Module Output Parameter may be used as an input parameter in any
1566 incremental module in the VNF. Note that the parameter is not
1567 available to other VNFs.
1569 R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s
1570 name and type **MUST** match the VNF’s Heat Orchestration Template’s
1571 incremental Module’s name and type unless the output parameter is of type
1572 ‘comma_delimited_list’, then the corresponding input parameter **MUST**
1573 be declared as type ‘json’.
1575 If the Output parameter has a comma_delimited_list value (e.g., a collection
1576 of UUIDs from a Resource Group), then the corresponding input parameter
1577 must be declared as type json and not a comma_delimited_list, which is
1578 actually a string value with embedded commas.
1580 R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output
1581 parameter is declared as an input parameter in an Incremental Module,
1582 the parameter attribute ‘constraints:’ **MUST NOT** be declared.
1584 Additional details on ONAP Base Module Output Parameters are provided in
1585 `ONAP Output Parameter Names`_ and ONAP VNF Modularity.
1587 ONAP Volume Module Output Parameters
1588 ++++++++++++++++++++++++++++++++++++
1590 R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
1591 Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
1592 template, while other Output Parameters **MAY** be included.
1594 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output Parameter(s)
1595 are only available for the module (base or incremental) that the volume
1596 template is associated with.
1598 R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output
1599 Parameter’s name and type **MUST** match the input parameter name and type
1600 in the corresponding Base Module or Incremental Module unless the Output
1601 Parameter is of the type ‘comma_delimited_list’, then the corresponding input
1602 parameter **MUST** be declared as type ‘json’.
1604 If the Output parameter has a comma_delimited_list value (e.g., a collection
1605 of UUIDs from a Resource Group), then the corresponding input parameter must
1606 be declared as type json and not a comma_delimited_list, which is actually a
1607 string value with embedded commas.
1609 R-20547 When an ONAP Volume Module Output Parameter is declared as an input
1610 parameter in a base or an incremental module Heat Orchestration Template,
1611 parameter constraints **MUST NOT** be declared.
1613 Additional details on ONAP Base Module Output Parameters are provided in
1614 `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
1616 ONAP Predefined Output Parameters
1617 +++++++++++++++++++++++++++++++++++
1619 ONAP will look for a small set of pre-defined Heat output parameters to
1620 capture resource attributes for inventory in ONAP. These output parameters
1621 are optional and currently only two parameters are supported. These output
1622 parameters are optional and are specified in `OAM Management IP Addresses`_.
1624 Support of heat stack update
1625 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1627 ONAP does not support the use of heat stack-update command for scaling
1630 R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
1631 utilize the OpenStack ‘heat stack-update’ command for scaling
1634 R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
1635 design to support scaling (growth/de-growth).
1637 Scope of a Heat Orchestration Template
1638 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1640 R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance
1641 specific or Cloud site specific
1643 R-56750 A VNF’s Heat Orchestration Template’s parameter values that are
1644 constant across all deployments **MUST** be declared in a Heat Orchestration
1645 Template Environment File.
1647 ONAP provides the instance specific parameter values to the Heat
1648 Orchestration Template at orchestration time.
1650 R-01896 A VNF’s Heat Orchestration Template’s parameter values that are
1651 constant across all deployments **MUST** be declared in a Heat Orchestration
1652 Template Environment File.
1657 ONAP defines two types of networks: External Networks and Internal Networks.
1662 ONAP defines an external network in relation to the VNF and not with regard
1663 to the Network Cloud site. External networks may also be referred to as
1664 “inter-VNF” networks. An external network must connect VMs in a VNF to
1665 VMs in another VNF or an external gateway or external router.
1667 An External Network may be a Neutron Network or a Contrail Network.
1669 R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat
1670 resources to create external networks.
1672 External networks must be orchestrated separately, independent of the VNF.
1673 This allows the network to be shared by multiple VNFs and managed
1674 independently of VNFs.
1676 R-00606 A VNF **MAY** be connected to zero, one or more than one external
1679 R-57424 A VNF’s port connected to an external network **MUST** connect the
1680 port to VMs in another VNF and/or an external gateway and/or external router.
1682 R-29865 A VNF’s port connected to an external network **MUST NOT** connect
1683 the port to VMs in the same VNF.
1685 R-69014 When a VNF connects to an external network, a network role, referred
1686 to as the ‘{network-role}’ **MUST** be assigned to the external network
1687 for use in the VNF’s Heat Orchestration Template.
1689 R-05201 When a VNF connects to two or more external networks, each external
1690 network **MUST** be assigned a unique ‘{network-role}’ in the context of
1691 the VNF for use in the VNF’s Heat Orchestration Template.
1693 R-83015 A VNF’s ‘{network-role}’ assigned to an external network **MUST**
1694 be different than the ‘{network-role}’ assigned to the VNF’s internal
1695 networks, if internal networks exist.
1697 ONAP enforces a naming convention for parameters associated with
1698 external networks. `ONAP Resource ID and Parameter Naming Convention`_
1699 provides additional details.
1704 ONAP defines an internal network in relation to the VNF and not with
1705 regard to the Network Cloud site. Internal networks may also be referred
1706 to as “intra-VNF” networks or “private” networks. An internal network
1707 only connects VMs in a single VNF; it must not connect to other VNFs
1708 or an external gateway or router
1710 R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
1712 R-35666 If a VNF has an internal network, the VNF Heat Orchestration
1713 Template **MUST** include the heat resources to create the internal network.
1715 R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat
1716 Orchestration Template Base Module.
1718 An Internal Network may be created using Neutron Heat Resources and/or
1719 Contrail Heat Resources.
1721 R-52425 A VNF’s port connected to an internal network **MUST** connect
1722 the port to VMs in the same VNF.
1724 R-46461 A VNF’s port connected to an internal network **MUST NOT** connect
1725 the port to VMs in another VNF and/or an external gateway and/or
1728 R-68936 When a VNF creates an internal network, a network role, referred to
1729 as the ‘{network-role}’ **MUST** be assigned to the internal network for
1730 use in the VNF’s Heat Orchestration Template.
1732 R-32025 When a VNF creates two or more internal networks, each internal
1733 network **MUST** be assigned a unique ‘{network-role}’ in the context of
1734 the VNF for use in the VNF’s Heat Orchestration Template.
1736 R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST**
1737 be different than the ‘{network-role}’ assigned to the VNF’s external
1740 R-34726 If a VNF’s port is connected to an internal network and the port
1741 is created in the same Heat Orchestration Template as the internal network,
1742 then the port resource **MUST** use a ‘get_resource’ to obtain
1745 R-22688 If a VNF’s port is connected to an internal network and the
1746 port is created in an Incremental Module and the internal network is created
1747 in the Base Module then the UUID of the internal network **MUST** be exposed
1748 as a parameter in the ‘outputs:’ section of the Base Module and the port
1749 resource **MUST** use a ‘get_param’ to obtain the network UUID.
1751 ONAP does not programmatically enforce a naming convention for
1752 parameters for internal network. However, a naming convention is
1753 provided that must be followed.
1754 `ONAP Resource ID and Parameter Naming Convention`_
1755 provides additional details.
1757 ONAP Resource ID and Parameter Naming Convention
1758 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1760 This section provides the ONAP naming requirements for
1764 2. Resource Property Parameters
1769 R-01455 When a VNF's Heat Orchestration Template creates a
1770 Virtual Machine (i.e., 'OS::Nova::Server'), each 'class' of VMs
1771 **MUST** be assigned a VNF unique '{vm-type}'; where 'class'
1772 defines VMs that **MUST** have the following identical characteristics:
1774 1.) OS::Nova::Server property flavor value
1776 2.) OS::Nova::Server property image value
1778 3.) Cinder Volume attachments
1779 - Each VM in the 'class' **MUST** have the identical Cinder Volume
1782 4.) Network attachments and IP address requirements
1783 - Each VM in the 'class' **MUST** have the the identical number
1784 of ports connecting to the identical networks and requiring the
1785 identical IP address configuration.
1787 R-82481 A VNF's Heat Orchestration Template's Resource property
1789 associated with a unique Virtual Machine type **MUST**
1790 include '{vm-type}' as part of the parameter name with two
1793 1.) The Resource OS::Nova::Server property availability_zone parameter
1794 **MUST NOT** be prefixed with a common '{vm-type} identifier,
1796 2.) The Resource OS::Nova::Server eight mandatory and optional metadata
1797 parameters (vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role,
1798 vf_module_index, environment_context, workload_context) **MUST NOT**
1799 be prefixed with a common '{vm-type}' identifier.
1802 R-66729 A VNF’s Heat Orchestration Template’s Resource that is
1803 associated with a unique Virtual Machine type **MUST** include
1804 ‘{vm-type}’ as part of the resource ID.
1806 R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
1807 only alphanumeric characters and/or underscores '_' and
1808 **MUST NOT** contain any of the following strings: '_int' or 'int\_'
1811 R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
1812 substring of {network-role}.
1814 It may cause the Pre-Amsterdam VNF Validation Program (i.e.,
1815 ICE Project) process to produce erroneous error messages.
1817 R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’
1818 in all Resource property parameter names **MUST** be the same case.
1820 R-46839 A VNF’s Heat Orchestration Template’s use of
1821 ‘{vm-type}’ in all Resource IDs **MUST** be the same case.
1823 R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in
1824 Resource property parameter names **SHOULD** match the case of
1825 ‘{vm-type}’ in Resource IDs and vice versa.
1830 The assignment of a {network-role} is discussed in `Networking`_.
1832 R-21330 A VNF’s Heat Orchestration Template’s Resource property
1833 parameter that is associated with external network **MUST**
1834 include the ‘{network-role}’’ as part of the parameter name
1836 R-11168 A VNF's Heat Orchestration Template's Resource ID that is
1837 associated with an external network **MUST** include the
1838 '{network-role}' as part of the resource ID.
1840 R-84322 A VNF's Heat Orchestration Template's Resource property
1841 parameter that is associated with an internal network
1842 **MUST** include 'int\_{network-role}' as part of the parameter
1843 name, where 'int\_' is a hard coded string.
1845 R-96983 A VNF's Heat Orchestration Template's Resource ID that is
1846 associated with an internal network **MUST** include
1847 'int\_{network-role}' as part of the Resource ID, where
1848 'int\_' is a hard coded string.
1850 R-26506 A VNF's Heat Orchestration Template's '{network-role}'
1851 **MUST** contain only alphanumeric characters and/or
1852 underscores '_' and **MUST NOT** contain any of the following
1853 strings: '_int' or 'int\_' or '\_int\_'.
1855 R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’
1856 **MUST NOT** be a substring of ‘{vm-type}’.
1858 For example, if a VNF has a ‘{vm-type}’ of ‘oam’ and a
1859 ‘{network-role}’ of ‘oam_protected’ would be a violation of the requirement.
1861 R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
1862 in all Resource property parameter names **MUST** be the same case
1864 R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
1865 in all Resource IDs **MUST** be the same case.
1867 R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case
1868 in Resource property parameter names **SHOULD** match the case
1869 of ‘{network-role}’ in Resource IDs and vice versa.
1874 Requirement R-75141 states a VNF’s Heat Orchestration Template’s
1875 resource name (i.e., <resource ID>) MUST only contain alphanumeric
1876 characters and underscores (‘_’).*
1878 Requirement R-16447 states a VNF’s <resource ID> MUST be unique
1879 across all Heat Orchestration Templates and all HEAT Orchestration
1880 Template Nested YAML files that are used to create the VNF.
1882 As stated previously, OpenStack requires the <resource ID> to be unique
1883 to the Heat Orchestration Template and not unique across all Heat
1884 Orchestration Templates the compose the VNF.
1886 Heat Orchestration Template resources are described in `resources`_
1888 R-54517 When a VNF’s Heat Orchestration Template’s resource is associated
1889 with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’.
1891 R-96482 When a VNF’s Heat Orchestration Template’s resource is associated
1892 with a single external network, the Resource ID MUST contain the text
1895 R-98138 When a VNF’s Heat Orchestration Template’s resource is associated
1896 with a single internal network, the Resource ID MUST contain the text
1897 ‘int\_{network-role}’.
1899 R-82115 When a VNF's Heat Orchestration Template's resource is associated
1900 with a single '{vm-type}' and a single external network, the Resource
1901 ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
1903 - the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
1904 be separated by an underscore '_'
1906 - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
1908 - note that an '{index}' value **MAY** separate the '{vm-type}' and the
1909 '{network-role}' and when this occurs underscores **MUST** separate the
1912 R-82551 When a VNF's Heat Orchestration Template's resource is associated
1913 with a single '{vm-type}' and a single internal network, the Resource ID
1914 **MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
1916 - the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
1917 **MUST** be separated by an underscore '_'
1919 - (e.g., '{vm-type}\_int\_{network-role}',
1920 '{vm-type}_{index}\_int\_{network-role}')
1922 - note that an '{index}' value **MAY** separate the '{vm-type}' and the
1923 'int\_{network-role}' and when this occurs underscores **MUST** separate
1926 R-67793 When a VNF’s Heat Orchestration Template’s resource is associated
1927 with more than one ‘{vm-type}’ and/or more than one internal and/or
1928 external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’
1929 and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the
1930 term ‘shared’ and/or contain text that identifies the VNF
1932 R-27970 When a VNF’s Heat Orchestration Template’s resource is associated
1933 with more than one ‘{vm-type}’ and/or more than one internal and/or
1934 external network, the Resource ID **MAY** contain the term ‘shared’
1935 and/or **MAY** contain text that identifies the VNF.
1937 R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains
1938 an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’
1939 **MUST** start at zero and increment by one.
1941 The table below provides example OpenStack Heat resource ID for
1942 resources only associated with one {vm-type} and/or one network.
1944 The Requirements column states if the Resource ID Format MUST be followed
1945 or SHOULD be followed. Resource ID formats that are marked MUST must be
1946 followed, no deviations are permitted. Resource ID formats that are marked
1947 SHOULD should be followed. However, deviations are permissible to meet
1948 the needs of the VNF’s Heat Orchestration Template.
1950 +-----------------+-------------------------+-------------+------------------+
1951 |Resource Type |Resource ID Format | Requirements| Notes |
1953 +=================+=========================+=============+==================+
1954 | OS::Cinder:: | {vm-type}\_volume\ | **SHOULD** | |
1955 | Volume | _{index} | | |
1956 +-----------------+-------------------------+-------------+------------------+
1957 | OS::Cinder:: | {vm-type}\ | **SHOULD** | |
1958 | VolumeAttachment| _volumeattachment\ | | |
1960 +-----------------+-------------------------+-------------+------------------+
1961 | OS::Heat:: | {vm-type}_RCC | **SHOULD** | |
1962 | CloudConfig | | | |
1963 +-----------------+-------------------------+-------------+------------------+
1964 | OS::Heat:: | {vm-type}_RMM | **SHOULD** | |
1965 | MultipartMime | | | |
1966 +-----------------+-------------------------+-------------+------------------+
1967 | OS::Heat:: | {vm-type}_RRG | **SHOULD** | |
1968 | ResourceGroup | | | |
1969 +-----------------+-------------------------+-------------+------------------+
1970 | | {vm-type}\_{index}\ | **MUST** for| Resource ID for |
1971 | | _subint\_{network-role}\| subinterface| the OS::Heat:: |
1972 | | _port\_{index}\ | creation | ResourceGroup |
1973 | | _subinterfaces | | that creates |
1974 | | | | subinterfaces |
1975 +-----------------+-------------------------+-------------+------------------+
1976 | OS::Heat:: | {vm-type}_RSC | **SHOULD** | |
1977 | SoftwareConfig | | | |
1978 +-----------------+-------------------------+-------------+------------------+
1979 | OS::Neutron:: | {vm-type}\ | **MUST** | Resource ID for |
1980 | Port | _{vm-type-index}\ | | port connecting |
1981 | | _{network-role}\_port\ | | to an external |
1982 | | _{port-index} | | network. The |
1983 | | | | {vm-type-index} |
1984 | | | | is the instance |
1985 | | | | of the {vm_type}.|
1986 | | | | The {port-index} |
1987 | | | | is the instance |
1988 | | | | of the “port” on |
1989 | | | | the {vm-type}. |
1990 | | | | There is no index|
1992 | | | | {network_role} |
1994 | | | | {network-role} is|
1995 | | | | unique to the |
1996 | | | | VNF, there should|
1997 | | | | only be one |
1999 +-----------------+-------------------------+-------------+------------------+
2000 | | {vm-type}\_{index}\_int\| **MUST** | Resource ID for |
2001 | | _{network-role}\_port\ | | port connecting |
2002 | | _{index} | | to an internal |
2003 | | | | network. The |
2004 | | | | {index} that |
2005 | | | | follows {vm-type}|
2006 | | | | is the instance |
2007 | | | | of the {vm_type}.|
2008 | | | | The {index} that |
2009 | | | | follows “port” is|
2010 | | | | the instance of |
2011 | | | | the “port” on the|
2012 | | | | {vm-type}. There |
2013 | | | | is no index after|
2014 | | | | {network_role} |
2016 | | | | {network-role} is|
2017 | | | | unque to the AIC |
2018 | | | | LCP; there should|
2019 | | | | only be one |
2021 +-----------------+-------------------------+-------------+------------------+
2022 | | Reserve_Port\_{vm-type}\| | Resource ID for a|
2023 | | _{network-role}\ | **MUST** | reserve port that|
2024 | | _floating_ip\_{index} | | is used for an |
2025 | | | | allowed_address |
2026 | | Reserve_Port\_{vm-type}\| | \_pair. See |
2027 | | _{network-role}\ | | Section 5.6.5.5 |
2028 | | _floating_v6_ip\ | | for additional |
2029 | | _{index} | | details. |
2031 | | | | There is no |
2032 | | | | {index} that |
2033 | | | | follows {vm-type}|
2034 +-----------------+-------------------------+-------------+------------------+
2035 | OS::Neutron:: | {vm-type}\_Sec\_Grp | **SHOULD** | Security Group |
2036 | SecurityGroup | | | applicable to one|
2037 | | | | {vm-type} and |
2038 | | | | more than one |
2039 | | | | network (internal|
2040 | | | | and/or external) |
2041 +-----------------+-------------------------+-------------+------------------+
2042 | | {network-role}\_Sec\_Grp| **SHOULD** | Security Group |
2043 | | | | applicable to |
2044 | | | | more than one |
2045 | | | | {vm-type} and one|
2046 | | | | external network |
2047 +-----------------+-------------------------+-------------+------------------+
2048 | | int\_{network-role}\ | **SHOULD** | Security Group |
2049 | | _Sec\_Grp | | applicable to |
2050 | | | | more than one |
2051 | | | | {vm-type} and one|
2052 | | | | internal network |
2053 +-----------------+-------------------------+-------------+------------------+
2054 | | {vm-type}\ | **SHOULD** | Security Group |
2055 | | _{network-role}\_Sec\ | | applicable to one|
2056 | | _Grp | | {vm-type} and one|
2057 | | | | external network |
2058 +-----------------+-------------------------+-------------+------------------+
2059 | | {vm-type}\_int\ | **SHOULD** | Security Group |
2060 | | _{network-role}\_Sec\ | | applicable to one|
2061 | | _Grp | | {vm-type} and one|
2062 | | | | internal network |
2063 +-----------------+-------------------------+-------------+------------------+
2064 | | Shared\_Sec\_Grp | **SHOULD** | Security Group |
2065 | | | | applicable to |
2066 | | | | more than one |
2067 | | | | {vm-type} and |
2068 | | | | more than one |
2069 | | | | network (internal|
2070 | | | | and/or external) |
2071 +-----------------+-------------------------+-------------+------------------+
2072 | OS::Neutron:: | int\_{network-role}\ | **MUST** | VNF Heat |
2073 | Subnet | _subnet\_{index} | | Orchestration |
2074 | | | | Templates can |
2075 | | | | only create |
2078 +-----------------+-------------------------+-------------+------------------+
2079 | OS::Neutron::Net| int\_{network-role}\ | **MUST** | VNF Heat |
2080 | | _network | | Orchestration |
2081 | | | | Templates can |
2082 | | | | only create |
2084 | | | | networks. There |
2085 | | | | is no {index} |
2087 | | | | {nework-role} |
2088 | | | |should be unique. |
2089 +-----------------+-------------------------+-------------+------------------+
2090 | OS::Nova:: | {vm-type}\_keypair\ | **SHOULD** | Key Pair |
2091 | Keypair | _{index} | | applicable to one|
2092 | | | | a{vm-type} |
2093 +-----------------+-------------------------+-------------+------------------+
2094 | | {vnf-type}_keypair | **SHOULD** | Key Pair |
2095 | | | | applicable to all|
2096 | | | | {vm-type} in the |
2098 +-----------------+-------------------------+-------------+------------------+
2099 | OS::Nova::Server| {vm-type}\_server\ | Mandatory | |
2101 +-----------------+-------------------------+-------------+------------------+
2102 | OS::Nova:: | {vm-type}_RSG | **SHOULD** | Both formats are |
2103 | ServerGroup | | | valid. |
2104 +-----------------+-------------------------+-------------+------------------+
2105 | | {vm-type}_Server_Grp | **SHOULD** | |
2106 +-----------------+-------------------------+-------------+------------------+
2107 | | {vm-type}_ServerGroup | **SHOULD** | |
2108 +-----------------+-------------------------+-------------+------------------+
2109 | OS::Swift:: | {vm-type}\_RSwiftC | **SHOULD** | |
2111 +-----------------+-------------------------+-------------+------------------+
2114 Table 2: Example OpenStack Heat Resource ID
2116 The table below provides Resource ID Formats for Contrail heat resources.
2117 - The Resource ID formats that are marked mandatory must be followed.
2118 No deviations are permitted.
2119 - The Resource ID formats that are marked optional should be followed.
2120 However, deviations in the Resource ID format that is shown is
2123 +-----------------+---------------------+-----------------+-----------------+
2124 | Resource | Resource ID | Mandatory / | Notes |
2125 | Type | Format | Optional | |
2126 +=================+=====================+=================+=================+
2127 | OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** – | The {index} |
2128 | :InstanceIp | _{network-role}\ | IPv4 address on | that follows |
2129 | | _vmi\_{index}\ | vmi external | {vm-type} is |
2130 | | _IP\_{index} | network | the instance of |
2131 | | | | the {vm_type}. |
2132 | | | | The {index} |
2133 | | | | that follows |
2134 | | | | “vmi” is the |
2135 | | | | instance of the |
2136 | | | | “vmi” on the |
2137 | | | | {vm-type}. |
2138 | | | | There is no |
2139 | | | | index after |
2140 | | | | {network_role} |
2141 | | | | since since |
2142 | | | | {network-role} |
2143 | | | | is unque. The |
2144 | | | | {index} that |
2145 | | | | follows the |
2146 | | | | “IP” is the |
2147 | | | | instance of the |
2148 | | | | “IP” on the |
2150 +-----------------+---------------------+-----------------+-----------------+
2151 | | {vm-type}\_{index}\ | **MUST** – | |
2152 | | _{network-role}\ | IPv6 address on | |
2153 | | _vmi\_{index}\_v6\ | vmi external | |
2154 | | _IP\_{index} | network | |
2155 +-----------------+---------------------+-----------------+-----------------+
2156 | | {vm-type}\_{index}\ | **MUST** – | |
2157 | | _int\ | IPv4 address on | |
2158 | | _{network-role}\ | vmi internal | |
2159 | | _vmi\_{index}\_IP\ | network | |
2161 +-----------------+---------------------+-----------------+-----------------+
2162 | | {vm-type}\_{index}\ | **MUST** – | |
2163 | | _int\ | IPv6 address on | |
2164 | | _{network-role}\ | vmi internal | |
2165 | | _vmi\_{index}\_v6\ | network | |
2166 | | _IP\_{index} | | |
2167 +-----------------+---------------------+-----------------+-----------------+
2168 | | {vm-type}\_{index}\ | **MUST** – | |
2169 | | _subint\ | IPv4 address on | |
2170 | | _{network-role}\ | sub-interface | |
2171 | | _vmi\_{index}\_IP\ | vmi external | |
2172 | | _{index} | network | |
2173 +-----------------+---------------------+-----------------+-----------------+
2174 | | {vm-type}\_{index}\ | **MUST** – | |
2175 | | _subint\ | IPv6 address on | |
2176 | | _{network-role}\ | sub-interface | |
2177 | | _vmi\_{index}\_v6\ | vmi external | |
2178 | | _IP\_{index} | network | |
2179 +-----------------+---------------------+-----------------+-----------------+
2180 | OS::ContrailV2: | {network-role}\_RIRT| **MAY** | |
2181 | :InterfaceRoute | | | |
2183 +-----------------+---------------------+-----------------+-----------------+
2184 | OS::ContrailV2: | {network-role}\_RNI | **MAY** | |
2185 | :NetworkIpam | | | |
2186 +-----------------+---------------------+-----------------+-----------------+
2187 | OS::ContrailV2: | {vm-type}\_RPT | **MAY** | |
2188 | :PortTuple | | | |
2189 +-----------------+---------------------+-----------------+-----------------+
2190 | OS::ContrailV2: | {vm-type}\_RSHC\ | **MAY** | |
2191 | :ServiceHealthC | _{LEFT/RIGHT} | | |
2193 +-----------------+---------------------+-----------------+-----------------+
2194 | OS::ContrailV2: | {vm-type}\_RST\ | **MAY** | |
2195 | :ServiceTemplat | _{index} | | |
2197 +-----------------+---------------------+-----------------+-----------------+
2198 | OS::ContrailV2: | {vm-type}\_{index}\ | **MUST** - vmi | Resource ID for |
2199 | :VirtualMachine | _{network-role}\ | attached to an | virtual machine |
2200 | Interface | _vmi\_{index} | external | interface (vmi) |
2201 | | | network | connecting to |
2202 | | | | an external |
2203 | | | | network. The |
2204 | | | | {index} that |
2206 | | | | {vm-type} is |
2207 | | | | the instance of |
2208 | | | | the {vm_type}. |
2209 | | | | The {index} |
2210 | | | | that follows |
2211 | | | | “vmi” is the |
2212 | | | | instance of the |
2213 | | | | “vmi” on the |
2214 | | | | {vm-type}. |
2215 | | | | There is no |
2216 | | | | index after |
2217 | | | | {network_role} |
2218 | | | | since since |
2219 | | | | {network-role} |
2220 | | | | is unque to the |
2221 | | | | AIC LCP; there |
2222 | | | | should only be |
2223 | | | | one instance. |
2224 +-----------------+---------------------+-----------------+-----------------+
2225 | | {vm-type}\_{index}\ | **MUST** - vmi | |
2226 | | _int\ | attached to an | |
2227 | | _{network-role}\ | internal | |
2228 | | _vmi\_{index} | network | |
2229 +-----------------+---------------------+-----------------+-----------------+
2230 | | {vm-type}\_{index}\ | **MUST** - vmi | |
2231 | | _subint\ | attached to a | |
2232 | | _{network-role}\ | sub-interface | |
2233 | | _vmi\_{index} | network | |
2234 +-----------------+---------------------+-----------------+-----------------+
2235 | OS::ContrailV2: | int\_{network-role}\| **MAY** | VNF Heat |
2236 | :VirtualNetwork | _RVN | | Orchestration |
2237 | | | | Templates can |
2238 | | | | only create |
2240 | | | | networks. There |
2241 | | | | is no {index} |
2243 | | | | {nework-role} |
2245 | | | | unique. Both |
2246 | | | | formats are |
2248 +-----------------+---------------------+-----------------+-----------------+
2249 | | int\_{network-role}\| **MAY** | |
2251 +-----------------+---------------------+-----------------+-----------------+
2253 Table 3: Example Contrail Heat resource ID
2255 There is a use case where the template filename is used as the type: as
2256 shown in the example below. There is no suggested Resource ID naming
2257 convention for this use case.
2259 Example: Template Filename used as the type:
2261 .. code-block:: python
2263 heat_template_version: 2015-04-30
2271 Resource: OS::Nova::Server - Parameters
2272 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2274 The resource OS::Nova::Server manages the running virtual machine (VM)
2275 instance within an OpenStack cloud. (See
2276 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server.)
2278 Four properties of this resource must follow the ONAP parameter naming
2279 convention. The four properties are:
2287 4. availability\_zone
2289 Requirement R-01455 defines how the ‘{vm-type]’ is defined.
2291 Requirement R-82481 defines how the ‘{vm-type} is used.’
2293 The table below provides a summary. The sections that follow provides
2294 the detailed requirements.
2296 .. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
2297 :header: Property Name,Parameter Type,Parameter Name,Parameter Value Provided to Heat
2301 image, string, {vm-type}\_image\_name, Environment File
2302 flavor, string, {vm-type}\_flavor\_name, Environment File
2303 name, string, {vm-type}\_name\_{index}, ONAP
2304 name, CDL, {vm-type}_names, ONAP
2305 availability_zone, string, availability\_zone\_{index}, ONAP
2310 R-71152 The VNF’s Heat Orchestration Template’s Resource
2311 ‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
2314 R-58670 The VNF’s Heat Orchestration Template’s Resource
2315 ‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the
2316 naming convention ‘{vm-type}_image_name’.
2318 R-91125 The VNF’s Heat Orchestration Template’s Resource
2319 ‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in
2320 the Heat Orchestration Template’s Environment File and a value **MUST** be
2323 R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’
2324 **MUST** have a unique parameter name for the ‘OS::Nova::Server’
2325 property ‘image’ even if more than one {vm-type} shares the same image.
2327 *Example Parameter Definition*
2329 .. code-block:: yaml
2332 {vm-type}_image_name:
2334 description: {vm-type} server image
2339 R-50436 The VNF’s Heat Orchestration Template’s Resource
2340 ‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
2343 R-45188 The VNF’s Heat Orchestration Template’s Resource
2344 ‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the
2345 naming convention ‘{vm-type}_flavor_name’.
2347 R-69431 The VNF’s Heat Orchestration Template’s Resource
2348 ‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the
2349 Heat Orchestration Template’s Environment File and a value **MUST** be
2352 R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST**
2353 have a unique parameter name for the ‘OS::Nova::Server’ property
2354 ‘flavor’ even if more than one {vm-type} shares the same flavor.
2356 *Example Parameter Definition*
2358 .. code-block:: yaml
2361 {vm-type}_flavor_name:
2363 description: {vm-type} flavor
2368 R-51430 The VNF’s Heat Orchestration Template’s Resource
2369 ‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as
2370 either type ‘string’ or type ‘comma_delimited_list”.
2372 R-54171 When the VNF’s Heat Orchestration Template’s Resource
2373 ‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
2374 the parameter name **MUST** follow the naming convention
2375 ‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts
2376 at zero and increments by one.
2378 R-40899 When the VNF’s Heat Orchestration Template’s Resource
2379 ‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
2380 a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource
2381 associated with the ‘{vm-type}’.
2383 R-87817 When the VNF’s Heat Orchestration Template’s Resource
2384 ‘OS::Nova::Server’ property ‘name’ parameter is defined as a
2385 ‘comma_delimited_list’, the parameter name **MUST** follow the naming
2386 convention ‘{vm-type}_names’.
2388 R-85800 When the VNF’s Heat Orchestration Template’s Resource
2389 ‘OS::Nova::Server’ property ‘name’ parameter is defined as a
2390 ‘comma_delimited_list’, a parameter **MUST** be delcared once for all
2391 ‘OS::Nova::Server’ resources associated with the ‘{vm-type}’.
2393 R-22838 The VNF’s Heat Orchestration Template’s Resource
2394 ‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated
2395 in the Heat Orchestration Template’s Environment File.
2397 If a VNF’s Heat Orchestration Template’s contains more than three
2398 OS::Nova::Server resources of a given {vm-type}, the comma_delimited_list
2399 form of the parameter name (i.e., ‘{vm-type}_names’) should be used to
2400 minimize the number of unique parameters defined in the template.
2403 *Example: Parameter Definition*
2405 .. code-block:: python
2410 type: comma_delimited_list
2411 description: VM Names for {vm-type} VMs
2413 {vm-type}_name_{index}:
2415 description: VM Name for {vm-type} VM {index}
2417 *Example: comma_delimited_list*
2419 In this example, the {vm-type} has been defined as “lb” for load balancer.
2421 .. code-block:: python
2426 type: comma_delimited_list
2427 description: VM Names for lb VMs
2431 type: OS::Nova::Server
2433 name: { get_param: [lb_names, 0] }
2437 type: OS::Nova::Server
2439 name: { get_param: [lb_names, 1] }
2442 *Example: fixed-index*
2444 In this example, the {vm-type} has been defined as “lb” for load balancer.
2446 .. code-block:: python
2452 description: VM Name for lb VM 0
2456 description: VM Name for lb VM 1
2461 type: OS::Nova::Server
2463 name: { get_param: lb_name_0 }
2467 type: OS::Nova::Server
2469 name: { get_param: lb_name_1 }
2472 Contrail Issue with Values for OS::Nova::Server Property Name
2473 _____________________________________________________________
2475 R-44271 The VNF's Heat Orchestration Template's Resource
2476 'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
2477 contain special characters since the Contrail GUI has a limitation
2478 displaying special characters.
2480 However, if special characters must be used, the only special characters
2483 --- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _
2486 Property: availability\_zone
2487 ++++++++++++++++++++++++++++
2489 R-98450 The VNF’s Heat Orchestration Template’s Resource
2490 ‘OS::Nova::Server’ property ‘availability_zone’ parameter name
2491 **MUST** follow the naming convention ‘availability\_zone\_{index}’
2492 where the ‘{index}’ **MUST** start at zero and increment by one.
2494 R-23311 The VNF’s Heat Orchestration Template’s Resource
2495 ‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST**
2496 be declared as type: ‘string’.
2498 The parameter must not be declared as type ‘comma_delimited_list’,
2499 ONAP does not support it.
2501 R-59568 The VNF’s Heat Orchestration Template’s Resource
2502 ‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT**
2503 be enumerated in the Heat Orchestration Template’s Environment File.
2505 Example Parameter Definition
2507 .. code-block:: python
2510 availability_zone_{index}:
2512 description: availability zone {index} name
2514 Requirement R-90279 states that a VNF Heat Orchestration’s template’s
2515 parameter MUST be used in a resource with the exception of the parameters
2516 for the OS::Nova::Server resource property availability_zone.
2518 R-01359 A VNF’s Heat Orchstration Template that contains an
2519 ‘OS::Nova:Server’ Resource **MAY** define a parameter for the property
2520 ‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’
2521 resources in the Heat Orchestration Template.
2526 The example below depicts part of a Heat Orchestration Template that
2527 uses the four OS::Nova::Server properties discussed in this section.
2529 In the Heat Orchestration Template below, four Virtual
2530 Machines (OS::Nova::Server) are created: two dns servers with
2531 {vm-type} set to “dns” and two oam servers with {vm-type} set to “oam”.
2532 Note that the parameter associated with the property name is a
2533 comma_delimited_list for dns and a string for oam.
2535 .. code-block:: python
2541 description: dns server image
2545 description: dns server flavor
2548 type: comma_delimited_list
2549 description: dns server names
2553 description: oam server image
2557 description: oam server flavor
2561 description: oam server name 0
2565 description: oam server name 1
2567 availability_zone_0:
2569 description: availability zone ID or Name
2571 availability_zone_1:
2573 description: availability zone ID or Name
2578 type: OS::Nova::Server
2580 name: { get_param: [ dns_names, 0 ] }
2581 image: { get_param: dns_image_name }
2582 flavor: { get_param: dns_flavor_name }
2583 availability_zone: { get_param: availability_zone_0 }
2588 type: OS::Nova::Server
2590 name: { get_param: [ dns_names, 1 ] }
2591 image: { get_param: dns_image_name }
2592 flavor: { get_param: dns_flavor_name }
2593 availability_zone: { get_param: availability_zone_1 }
2598 type: OS::Nova::Server
2600 name: { get_param: oam_name_0 }
2601 image: { get_param: oam_image_name }
2602 flavor: { get_param: oam_flavor_name }
2603 availability_zone: { get_param: availability_zone_0 }
2608 type: OS::Nova::Server
2610 name: { get_param: oam_name_1 }
2611 image: { get_param: oam_image_name }
2612 flavor: { get_param: oam_flavor_name }
2613 availability_zone: { get_param: availability_zone_1 }
2620 R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine
2621 (i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
2622 boot from a Cinder Volume.
2624 R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine
2625 (i.e., ‘OS::Nova::Server’ Resource) boots from an image, the
2626 ‘OS::Nova::Server’ resource property ‘image’ **MUST** be used.
2628 The requirements associated with
2629 the 'image' property are detailed in `Property: image`_
2631 R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine
2632 (i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the
2633 ‘OS::Nova::Server’ resource property ‘block_device_mapping’ or
2634 ‘block_device_mapping_v2’ **MUST** be used.
2636 There are currently no heat guidelines
2637 associated with these two properties:
2638 'block_device_mapping' and 'block_device_mapping_v2'.
2640 Resource: OS::Nova::Server – Metadata Parameters
2641 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2643 The OS::Nova::Server Resource property metadata is an optional
2645 The table below summarizes the mandatory and optional metadata
2648 The sections that follow provides the requirements associated with each
2651 .. csv-table:: **Table 5 OS::Nova::Server Mandatory and Optional Metadata**
2652 :header: Metadata Parameter Name, Parameter Type, Required, Parameter Value Provided to Heat
2656 vnf_id, string, **MUST**, ONAP
2657 vf_module_id, string, **MUST**, ONAP
2658 vnf_name, string, **MUST**, ONAP
2659 vf_module_name, string, **SHOULD**, ONAP
2660 vm_role, string, **MAY**, YAML or Environment File
2661 vf_module_index, string, **MAY**, ONAP
2662 workload_context, string, **SHOULD**, ONAP
2663 environment_context, string, **SHOULD**, ONAP
2668 The OS::Nova::Server Resource metadata map value parameter 'vnf_id'
2669 is an ONAP generated UUID that identifies the VNF. The value
2670 is provided by ONAP to the VNF's Heat Orchestration
2671 Template at orchestration time.
2673 R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2674 Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
2676 R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2677 Resource metadata map value parameter ‘vnf_id’ **MUST** be declared
2680 R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2681 Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have
2682 parameter contraints defined.
2684 R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2685 Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be
2686 enumerated in the Heat Orchestration Template’s environment file.
2688 R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2689 Resource metadata map value parameter ‘vnf_id’ is passed into a
2690 Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change.
2693 *Example 'vnf_id' Parameter Definition*
2695 .. code-block:: python
2701 description: Unique ID for this VNF instance
2706 The OS::Nova::Server Resource metadata map value parameter 'vf\_module\_id'
2707 is an ONAP generated UUID that identifies the VF Module (e.g., Heat
2708 Orchestration Template). The value
2709 is provided by ONAP to the VNF's Heat Orchestration
2710 Template at orchestration time.
2712 R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2713 Resource **MUST** contain the metadata map value parameter
2716 R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2717 Resource metadata map value parameter ‘vf\_module\_id’ **MUST**
2718 be declared as type: ‘string’.
2720 R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2721 Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
2722 have parameter contraints defined.
2724 R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2725 Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
2726 be enumerated in the Heat Orchestration Template’s environment file.
2728 R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2729 Resource metadata map value parameter ‘vf_module_id’ is passed
2730 into a Nested YAML file, the parameter name ‘vf\_module\_id’
2731 **MUST NOT** change.
2733 *Example 'vf\_module\_id' Parameter Definition*
2735 .. code-block:: python
2741 description: Unique ID for this VNF module instance
2747 The OS::Nova::Server Resource metadata map value parameter 'vnf_name'
2748 is the ONAP generated alphanumeric name of the deployed VNF instance.
2750 is provided by ONAP to the VNF's Heat Orchestration
2751 Template at orchestration time.
2752 The parameter must be declared as type: string
2754 R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2755 Resource **MUST** contain the metadata map value parameter
2758 R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2759 Resource metadata map value parameter ‘vnf_name’ **MUST** be
2760 declared as type: ‘string’.
2762 R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2763 Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have
2764 parameter contraints defined.
2766 R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2767 Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be
2768 enumerated in the Heat Orchestration Template’s environment file.
2770 R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2771 Resource metadata map value parameter ‘vnf_name’ is passed into a
2772 Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change.
2774 *Example 'vnf_name' Parameter Definition*
2776 .. code-block:: python
2782 description: Unique name for this VNF instance
2787 The OS::Nova::Server Resource metadata map value parameter 'vf_module_name'
2788 is the deployment name of the heat stack created (e.g., <STACK_NAME>) from the
2789 VNF's Heat Orchestration template
2790 in the command 'Heat stack-create'
2791 (e.g., 'Heat stack-create [-f <FILE>] [-e <FILE>] <STACK_NAME>').
2792 The 'vf_module_name' (e.g., <STACK_NAME> is specified as
2793 part of the orchestration process.
2795 R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2796 Resource **SHOULD** contain the metadata map value parameter
2799 R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2800 Resource metadata map value parameter ‘vf\_module\_name’ **MUST**
2801 be declared as type: ‘string’.
2803 R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2804 Resource metadata map value parameter ‘vf\_module\_name’
2805 **MUST NOT** have parameter contraints defined.
2807 R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2808 Resource metadata map value parameter ‘vf\_module\_name’
2809 **MUST NOT** be enumerated in the Heat Orchestration Template’s
2812 R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2813 Resource metadata map value parameter ‘vf\_module\_name’ is passed
2814 into a Nested YAML file, the parameter name ‘vf\_module\_name’
2815 **MUST NOT** change.
2817 *Example 'vf_module_name' Parameter Definition*
2819 .. code-block:: python
2825 description: Unique name for this VNF Module instance
2830 The OS::Nova::Server Resource metadata map value parameter 'vm-role'
2831 is a metadata tag that describes the role of the Virtual Machine.
2832 The 'vm_role' is stored in ONAP's A&AI module and is
2833 available for use by other ONAP components and/or north bound systems.
2835 R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2836 Resource **MAY** contain the metadata map value parameter ‘vm_role’.
2838 R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2839 Resource metadata map value parameter ‘vm_role’ **MUST** be
2840 declared as type: ‘string’.
2842 R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2843 Resource metadata map value parameter ‘vm_role’ **MUST NOT** have
2844 parameter contraints defined.
2846 R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2847 Resource metadata map value parameter ‘vnf_name’ **MUST** be
2850 - enumerated in the VNF’s Heat Orchestration
2851 Template’s environment file.
2853 - hard coded in the VNF’s Heat Orchestration
2854 Template’s OS::Nova::Resource metadata property.
2856 Defining the 'vm_role' as the '{vm-type}' is a recommended convention
2858 R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2859 Resource metadata map value parameter ‘vm_role’ value **MUST only**
2860 contain alphanumeric characters and underscores ‘_’.
2862 R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2863 Resource metadata map value parameter ‘vm_role’ is passed into a
2864 Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change.
2867 *Example 'vm_role' Parameter Definition*
2869 .. code-block:: python
2875 description: Unique role for this VM
2877 *Example: 'vm-role' Definition: Hard Coded in
2878 OS::Nova::Resource metadata property*
2880 .. code-block:: python
2885 type: OS::Nova::Server
2891 *Example 'vm-role' Definition: Defined in Environment file
2892 and retrieved via 'get_param'*
2894 .. code-block:: python
2899 type: OS::Nova::Server
2903 vm_role: { get_param: vm_role }
2905 Example vnf_id, vf_module_id, vnf_name, vf_module_name, vm_role
2906 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2908 The example below depicts part of a Heat Orchestration Template
2909 that uses the five of the OS::Nova::Server metadata parameter
2910 discussed in this section. The {vm-type} has been defined as lb
2913 .. code-block:: python
2918 description: VM Name for lb VM 0
2921 description: Unique name for this VNF instance
2924 description: Unique ID for this VNF instance
2927 description: Unique name for this VNF Module instance
2930 description: Unique ID for this VNF Module instance
2933 description: Unique role for this VM
2936 type: OS::Nova::Server
2938 name: { get_param: lb_name_0 }
2941 vnf_name: { get_param: vnf_name }
2942 vnf_id: { get_param: vnf_id }
2943 vf_module_name: { get_param: vf_module_name }
2944 vf_module_id: { get_param: vf_module_id }
2950 R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2951 Resource **MAY** contain the metadata map value parameter
2952 ‘vf\_module\_index’.
2954 R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2955 Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be
2956 declared as type: ‘number’.
2958 R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2959 Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
2960 have parameter contraints defined.
2962 R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server
2963 Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
2964 be enumerated in the Heat Orchestration Template’s environment file.
2966 R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2967 Resource metadata map value parameter ‘vf\_module\_index’ is passed
2968 into a Nested YAML file, the parameter name ‘vf\_module\_index’
2969 **MUST NOT** change.
2971 R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
2972 Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be
2973 used in a VNF’s Volume Template; it is not supported.
2975 The vf_module_index parameter indicates which instance of the module is being
2976 deployed into the VNF.
2977 This parameter may be used in cases where multiple instances of the same
2978 incremental module may be instantiated for scaling purposes. The index
2979 can be used in the Heat Orchestration Template for indexing into a
2980 pseudo-constant array parameter when unique values are required for each
2981 module instance, e.g., for fixed private IP addresses on VM types.
2983 The vf_module_index will start at 0 for the first instance of a module
2984 type. Subsequent instances of the same module type will receive the
2985 lowest unused index. This means that indexes will be reused if a module
2986 is deleted and re-added. As an example, if three copies of a module are
2987 deployed with vf_module_index values of 0, 1, and 2 then subsequently
2988 the second one is deleted (index 1), and then re-added, index 1 will be
2993 In this example, the {vm-type} has been defined as oam_vm to represent
2994 an OAM VM. An incremental heat module is used to deploy the OAM VM. The
2995 OAM VM attaches to an internal control network which has a
2996 {network-role} of ctrl. A maximum of four OAM VMs can be deployed. The
2997 environment file contains the four IP addresses that each successive OAM
2998 VM will be assigned. The vf_module_index is used as the index to
2999 determine the IP assignment.
3003 .. code-block:: python
3006 oam_vm_int_ctrl_ips: 10.10.10.1,10.10.10.2,10.10.10.3,10.10.10.4
3010 .. code-block:: python
3015 description: Unique index for this VNF Module instance
3018 description: VM Name for lb VM 0
3021 description: Neutron UUID for the internal control network
3022 oam_vm_int_ctrl_ips:
3023 type: comma_delimited_list
3024 description: Fixed IP assignments for oam VMs on the internal control
3028 type: OS::Nova::Server
3030 name: { get_param: oam_vm_name_0 }
3032 - port: { get_resource: oam_vm_0_int_ctrl_port_0 }
3035 vf_module_index: { get_param: vf_module_index }
3036 oam_vm_0_int_ctrl_port_0:
3037 type: OS::Neutron::Port
3039 network: { get_param: int_ctrl_net_id }
3040 fixed_ips: [ { “ip_address”: {get_param: [ oam_vm_int_ctrl_ips, { get_param, vf_module_index]}}}]
3045 R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3046 Resource **SHOULD** contain the metadata map value parameter
3049 R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3050 Resource metadata map value parameter ‘workload_context’ **MUST** be
3051 declared as type: ‘string’.
3053 R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3054 Resource metadata map value parameter ‘workload_context’ **MUST NOT**
3055 have parameter contraints defined.
3057 R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3058 Resource metadata map value parameter ‘workload_context’ **MUST NOT**
3059 be enumerated in the Heat Orchestration Template’s environment file.
3061 R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
3062 Resource metadata map value parameter ‘workload_context’ is passed
3063 into a Nested YAML file, the parameter name ‘workload_context’
3064 **MUST NOT** change.
3066 The 'workload_context' parameter value will be chosen by the Service Model
3067 Distribution context client in VID and will be supplied to the
3068 Heat Orchestration Template by ONAP at orchestration time.
3070 *Example Parameter Definition*
3072 .. code-block:: python
3077 description: Workload Context for this VNF instance
3080 *Example OS::Nova::Server with metadata*
3082 .. code-block:: python
3087 {vm-type}_server_{index}:
3088 type: OS::Nova::Server
3095 vnf_name: { get_param: vnf_name }
3096 vnf_id: { get_param: vnf_id }
3097 vf_module_name: { get_param: vf_module_name }
3098 vf_module_id: { get_param: vf_module_id }
3099 workload_context: {get_param: workload_context}
3104 R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3105 Resource **SHOULD** contain the metadata map value parameter
3106 ‘environment_context’.
3108 R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3109 Resource metadata map value parameter ‘environment_context’ **MUST**
3110 be declared as type: ‘string’.
3112 R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3113 Resource metadata map value parameter ‘environment_context’ **MUST NOT**
3114 have parameter contraints defined.
3116 R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server
3117 Resource metadata map value parameter ‘environment_context’ **MUST NOT**
3118 be enumerated in the Heat Orchestration Template’s environment file.
3120 R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
3121 Resource metadata map value parameter ‘environment_context’ is
3122 passed into a Nested YAML file, the parameter name
3123 ‘environment_context’ **MUST NOT** change.
3125 The 'environment_context' parameter value will be defined by the
3126 service designer as part of the service model during the SDC
3127 on-boarding process and will be supplied to the Heat Orchestration
3128 Template by ONAP at orchestration time.
3131 *Example Parameter Definition*
3133 .. code-block:: python
3136 environment_context:
3138 description: Environment Context for this VNF instance
3141 *Example OS::Nova::Server with metadata*
3143 .. code-block:: python
3148 {vm-type}_server_{index}:
3149 type: OS::Nova::Server
3156 vnf_name: { get_param: vnf_name }
3157 vnf_id: { get_param: vnf_id }
3158 vf_module_name: { get_param: vf_module_name }
3159 vf_module_id: { get_param: vf_module_id }
3160 workload_context: {get_param: workload_context}
3161 environment_context: {get_param: environment_context }
3164 Resource: OS::Neutron::Port - Parameters
3165 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3167 The resource OS::Neutron::Port is for managing Neutron ports (See
3168 https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
3173 Four properties of the resource OS::Neutron::Port that must follow the
3174 ONAP parameter naming convention. The four properties are:
3177 2. fixed_ips, ip_address
3178 3. fixed_ips, subnet_id or fixed_ips, subnet
3180 * Note that in many examples in this document fixed_ips, subnet_id is used.
3182 4. allowed_address_pairs, ip_address
3184 Below is a generic example. Note that for some parameters
3185 comma_delimited_list are supported in addition to String.
3187 .. code-block:: python
3194 type: OS::Neutron::Port
3196 allowed_address_pairs: [{"ip_address": String, "mac_address": String},
3197 {"ip_address": String, "mac_address": String}, ...]
3198 fixed_ips: [{"ip_address": String, "subnet_id": String, "subnet":
3199 String}, {"ip_address": String, "subnet_id": String, "subnet": String},
3203 The parameters associated with these properties may reference an
3204 external network or internal network. External networks and internal
3205 networks are defined in `Networking`_.
3207 When the OS::Neutron::Port is attaching to an external network, all
3208 property values are parameters that are retrieved via the intrinsic
3209 function 'get_param'.
3211 When the OS::Neutron::Port is attaching to an internal network, a
3212 property value maybe retrieved via the intrinsic
3213 function 'get_param', 'get_resource', or 'get_attr'.
3215 This will be described in the forth coming sections.
3220 A network (internal or external) may contain one or or more subnets.
3222 A VNF can have one or more ports connected to the same network.
3224 A port can have one or more IP addresses assigned.
3226 The IP address assignments can be IPv4 addresses and/or IPv6 addresses.
3228 The IP addresses assignments for a unique external network **MUST**
3229 be all Cloud Assigned addresses OR **MUST** be all ONAP
3230 SDN-C assigned IP addresses.
3232 If the IP addresses are Cloud Assigned, all the IPv4 Addresses **MUST**
3234 the same subnet and all the IPv6 Addresses **MUST** be from the
3237 If the IP addresses are ONAP SDN-C assigned,
3238 the IPv4 Addresses **MAY**
3240 different subnets and the IPv6 Addresses **MAY** be from different
3243 If a VNF's Port is attached to an external network the IP addresses **MAY**
3244 either be assigned by
3246 1. ONAP's SDN-Controller (SDN-C)
3247 2. Cloud Assigned by OpenStack’s DHCP Service
3249 If a VNF's Port is attached to an external network and the port's IP addresses
3250 are assigned by ONAP's SDN-Controller, the 'OS::Neutron::Port' Resource's
3252 * property 'fixed_ips' map property 'ip_address' **MUST** be used
3253 * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used
3255 If a VNF's Port is attached to an external network and the port's IP addresses
3256 are Cloud Assigned by OpenStack’s DHCP Service,
3257 the 'OS::Neutron::Port' Resource's
3259 * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
3260 * property fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
3262 If a VNF's Port is attached to an internal network and the port's IP addresses
3263 are assigned by the VNF's Heat Orchestration Template
3264 (i.e., enumerated in the Heat Orchestration Template's environment file),
3265 the 'OS::Neutron::Port' Resource's
3267 * property 'fixed_ips' map property 'ip_address' **MUST** be used
3268 * property 'fixed_ips' map property 'subnet'/'subnet_id'
3269 **MUST NOT** be used
3271 If a VNF's Port is attached to an internal network and the port's IP addresses
3272 are Cloud Assigned by OpenStack’s DHCP Service,
3273 the 'OS::Neutron::Port' Resource's
3275 * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used
3276 * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used
3278 If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
3279 'fixed_ips' map property 'ip_address' is specified, then the
3280 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT**
3283 If a VNF's Heat Orchestration Template 'OS::Neutron::Port' Resource property
3284 'fixed_ips' map property 'subnet'/'subnet_id' is specified, then the
3285 'fixed_ips' map property 'ip_address' **MUST NOT**
3288 .. csv-table:: **Table 4 OS::Nova::Server Resource Property Parameter Naming Convention**
3289 :header: Resource,Property,Parameter Type,Parameter Name,Parameter Value Provided to Heat
3293 OS::Nova::Server, image, string, {vm-type}_image_name, Environment File
3298 The Resource 'OS::Neutron::Port' property 'network' determines what network
3299 the port is attached to.
3302 R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
3303 property ‘network’ parameter **MUST** be declared as type: ‘string’.
3305 R-62983 When the VNF’s Heat Orchestration Template’s
3306 Resource ‘OS::Neutron::Port’ is attaching to an external network,
3307 the ‘network’ parameter name **MUST**
3309 - follow the naming convention ‘{network-role}_net_id’ if the Neutron
3310 network UUID value is used to reference the network
3311 - follow the naming convention ‘{network-role}_net_name’ if the OpenStack
3312 network name is used to reference the network.
3314 where ‘{network-role}’ is the network-role of the external network and
3315 a ‘get_param’ **MUST** be used as the intrinsic function.
3317 R-86182 When the VNF’s Heat Orchestration Template’s
3318 Resource ‘OS::Neutron::Port’ is attaching to an internal network,
3319 and the internal network is created in a different
3320 Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
3321 parameter name **MUST**
3323 - follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron
3324 network UUID value is used to reference the network
3325 - follow the naming convention ‘int\_{network-role}_net_name’ if the
3326 OpenStack network name in is used to reference the network.
3328 where ‘{network-role}’ is the network-role of the internal network
3329 and a ‘get_param’ **MUST** be used as the intrinsic function.
3331 In Requirement R-86182, the internal network is created in the VNF's
3332 Base Module (Heat Orchestration Template) and the parameter name is
3333 declared in the Base Module's outputs' section.
3334 The output parameter name will be declared as a parameter in the
3335 'parameters' section of the incremental module.
3337 R-93177 When the VNF’s Heat Orchestration Template’s
3338 Resource ‘OS::Neutron::Port’ is attaching to an internal
3339 network, and the internal network is created in the same Heat
3340 Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
3341 parameter name **MUST** obtain the UUID of the internal network
3342 by using the intrinsic function ‘get_resource’ or ‘get_attr’
3343 and referencing the Resource ID of the internal network.
3345 R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’
3346 property ‘network’ parameter **MUST NOT** be enumerated in the Heat
3347 Orchestration Template’s Environment File.
3349 The parameter values for external networks are provided by ONAP
3350 to the VNF's Heat Orchestration Template at orchestration time.
3352 The parameter values for internal networks created in the VNF's Base Module
3353 Heat Orchestration Template
3354 are provided to the VNF's Incremental Module Heat Orchestration Template
3355 at orchestration time.
3357 *Example Parameter Definition of External Networks*
3359 .. code-block:: python
3363 {network-role}_net_id:
3365 description: Neutron UUID for the external {network-role} network
3367 {network-role}_net_name:
3369 description: Neutron name for the external {network-role} network
3372 *Example Parameter Definition of Internal Networks in an Incremental Module*
3374 .. code-block:: python
3378 int_{network-role}_net_id:
3380 description: Neutron UUID for the internal int_{network-role} network
3382 int_{network-role}_net_name:
3384 description: Neutron name for the internal int_{network-role} network
3386 Property: fixed_ips, Map Property: ip_address
3387 +++++++++++++++++++++++++++++++++++++++++++++
3389 The resource 'OS::Neutron::Port' property 'fixed_ips'
3390 map property 'ip_address'
3391 is used to assign one IPv4 or IPv6
3394 One 'OS::Neutron::Port' resource may assign one or more
3395 IPv4 and/or IPv6 addresses.
3397 R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
3398 property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST**
3399 be declared as either type ‘string’ or type ‘comma_delimited_list’.
3401 R-40971 When the VNF’s Heat Orchestration Template’s Resource
3402 ‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 address is
3403 assigned using the property
3404 ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined
3405 as a string, the parameter name **MUST** follow the naming
3406 convention ‘{vm-type}_{network-role}\_ip\_{index}’, where
3408 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3409 - ‘{network-role}’ is the {network-role} of the external network
3410 - the value for {index} must start at zero (0) and increment by one
3412 R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
3413 property ‘fixed_ips’ map property ‘ip_address’ parameter
3414 ‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the
3415 VNF’s Heat Orchestration Template’s Environment File.
3417 ONAP's SDN-Controller assigns the IP Address and ONAP provides
3418 the value at orchestration to the Heat Orchestration Template.
3420 *Example External Network IPv4 Address string Parameter Definition*
3422 .. code-block:: python
3426 {vm-type}_{network-role}_ip_{index}:
3428 description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network
3430 R-04697 When the VNF’s Heat Orchestration Template’s
3431 Resource ‘OS::Neutron::Port’ is attaching to an external
3432 network, and an IPv4 address is assigned using the property
3433 ‘fixed_ips’ map property ‘ip_address’ and the parameter type
3434 is defined as a comma_delimited_list, the parameter name **MUST**
3435 follow the naming convention ‘{vm-type}_{network-role}_ips’,
3438 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3439 - ‘{network-role}’ is the {network-role} of the external network
3441 R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
3442 property ‘fixed_ips’ map property ‘ip_address’ parameter
3443 ‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s
3444 Heat Orchestration Template’s Environment File.
3446 ONAP's SDN-Controller assigns the IP Address and ONAP provides
3447 the value at orchestration to the Heat Orchestration Template.
3449 *Example External Network IPv4 Address comma_delimited_list
3450 Parameter Definition*
3452 .. code-block:: python
3456 {vm-type}_{network-role}_ips:
3457 type: comma_delimited_list
3458 description: Fixed IPv4 assignments for {vm-type} VMs on the {network-role} network
3460 R-71577 When the VNF’s Heat Orchestration Template’s Resource
3461 ‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address
3462 is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
3463 the parameter type is defined as a string, the parameter name **MUST** follow
3464 the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where
3466 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3467 - ‘{network-role}’ is the {network-role} of the external network
3468 - the value for {index} must start at zero (0) and increment by one
3471 R-87123 The VNF’s Heat Orchestration Template’s Resource
3472 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3473 parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’
3474 **MUST NOT** be enumerated in the VNF’s Heat Orchestration
3475 Template’s Environment File.
3477 ONAP's SDN-Controller assigns the IP Address and ONAP provides
3478 the value at orchestration to the Heat Orchestration Template.
3480 *Example External Network IPv6 Address string Parameter Definition*
3482 .. code-block:: python
3486 {vm-type}_{network-role}_v6_ip_{index}:
3488 description: Fixed IPv6 assignment for {vm-type} VM {index} on the {network-role} network
3490 R-23503 When the VNF’s Heat Orchestration Template’s Resource
3491 ‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
3492 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
3493 and the parameter type is defined as a comma_delimited_list, the parameter
3494 name **MUST** follow the naming convention
3495 ‘{vm-type}_{network-role}_v6_ips’, where
3497 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3498 - ‘{network-role}’ is the {network-role} of the external network
3500 R-93030 The VNF’s Heat Orchestration Template’s Resource
3501 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3502 parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the
3503 VNF’s Heat Orchestration Template’s Environment File.
3505 ONAP's SDN-Controller assigns the IP Address and ECOMP provides
3506 the value at orchestration to the Heat Orchestration Template.
3508 *Example External Network IPv6 Address comma_delimited_list Parameter
3511 .. code-block:: python
3515 {vm-type}_{network-role}_v6_ips:
3516 type: comma_delimited_list
3517 description: Fixed IPv6 assignments for {vm-type} VMs on the {network-role} network
3519 R-78380 When the VNF’s Heat Orchestration Template’s Resource
3520 ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address
3521 is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
3522 the parameter type is defined as a string, the parameter name **MUST** follow
3523 the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where
3525 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3526 - ‘{network-role}’ is the {network-role} of the internal network
3527 - the value for {index} must start at zero (0) and increment by one
3529 R-28795 The VNF’s Heat Orchestration Template’s Resource
3530 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3531 parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated
3532 in the VNF’s Heat Orchestration Template’s Environment File.
3534 The IP address is local to the VNF's internal network and is (re)used
3535 in every VNF spin up, thus the constant value is declared in the VNF's
3536 Heat Orchestration Template's Environment File.
3538 *Example Internal Network IPv4 Address string Parameter Definition*
3540 .. code-block:: python
3544 {vm-type}_int_{network-role}_ip_{index}:
3546 description: Fixed IPv4 assignment for {vm-type} VM {index} on the int_{network-role} network
3548 R-85235 When the VNF’s Heat Orchestration Template’s Resource
3549 ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4
3550 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
3551 and the parameter type is defined as a comma_delimited_list, the parameter
3552 name **MUST** follow the naming convention
3553 ‘{vm-type}\_int\_{network-role}_ips’, where
3555 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3556 - ‘{network-role}’ is the {network-role} of the internal network
3558 R-90206 The VNF’s Heat Orchestration Template’s Resource
3559 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3560 parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in
3561 the VNF’s Heat Orchestration Template’s Environment File.
3563 The IP address is local to the VNF's internal network and is (re)used
3564 in every VNF spin up, thus the constant value is declared in the VNF's
3565 Heat Orchestration Template's Environment File.
3567 .. code-block:: python
3571 {vm-type}_int_{network-role}_ips:
3572 type: comma_delimited_list
3573 description: Fixed IPv4 assignments for {vm-type} VMs on the int_{network-role} network
3575 R-27818 When the VNF’s Heat Orchestration Template’s Resource
3576 ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address
3577 is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
3578 the parameter type is defined as a string, the parameter name **MUST** follow
3579 the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where
3581 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3582 - ‘{network-role}’ is the {network-role} of the internal network
3583 - the value for {index} must start at zero (0) and increment by one
3585 R-97201 The VNF’s Heat Orchestration Template’s Resource
3586 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3587 parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’
3588 **MUST** be enumerated in the VNF’s Heat Orchestration
3589 Template’s Environment File.
3591 The IP address is local to the VNF's internal network and is (re)used
3592 in every VNF spin up, thus the constant value is declared in the VNF's
3593 Heat Orchestration Template's Environment File.
3595 *Example Internal Network IPv6 Address string Parameter Definition*
3597 .. code-block:: python
3601 {vm-type}_int_{network-role}_v6_ip_{index}:
3603 description: Fixed IPv6 assignment for {vm-type} VM {index} on the int_{network-role} network
3605 R-29765 When the VNF’s Heat Orchestration Template’s Resource
3606 ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6
3607 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
3608 and the parameter type is defined as a comma_delimited_list, the parameter
3609 name **MUST** follow the naming convention
3610 ‘{vm-type}\_int\_{network-role}_v6_ips’, where
3612 - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
3613 - ‘{network-role}’ is the {network-role} of the internal network
3615 *Example Internal Network IPv6 Address comma_delimited_list Parameter
3618 .. code-block:: python
3622 {vm-type}_int_{network-role}_v6_ips:
3623 type: comma_delimited_list
3624 description: Fixed IPv6 assignments for {vm-type} VMs on the int_{network-role} network
3626 R-98569 The VNF’s Heat Orchestration Template’s Resource
3627 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3628 parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in
3629 the VNF’s Heat Orchestration Template’s Environment File.
3631 The IP address is local to the VNF's internal network and is (re)used
3632 in every VNF spin up, thus the constant value is declared in the VNF's
3633 Heat Orchestration Template's Environment File.
3635 R-62590 The VNF’s Heat Orchestration Template’s Resource
3636 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3637 parameter associated with an external network, i.e.,
3639 - {vm-type}_{network-role}\_ip\_{index}
3640 - {vm-type}_{network-role}\_ip\_v6\_{index}
3641 - {vm-type}_{network-role}_ips
3642 - {vm-type}_{network-role}_v6_ips
3644 **MUST NOT** be enumerated in the Heat Orchestration Template’s
3645 Environment File. ONAP provides the IP address assignments at
3648 R-93496 The VNF’s Heat Orchestration Template’s Resource
3649 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
3650 parameter associated with an internal network, i.e.,
3652 - {vm-type}\_int\_{network-role}\_ip\_{index}
3653 - {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
3654 - {vm-type}\_int\_{network-role}_ips
3655 - {vm-type}\_int\_{network-role}_v6_ips
3657 **MUST** be enumerated in the Heat Orchestration Template’s Environment
3658 File and IP addresses **MUST** be assigned.
3663 .. csv-table:: **Table # OS::Neutron::Port Property fixed_ips map property ip_address Parameter Naming Convention**
3664 :header: Resource,Property,Map Property,Network Type,IP Address,Parameter Type,Parameter Name, Environment File
3668 OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, string, {vm-type}\_{network-role}\_ip\_{index}, NO
3669 OS::Neutron::Port, fixed_ips, ip_address, external, IPv4, comma\_delimited\_list, {vm-type}\_{network-role}\_ips, NO
3670 OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, string, {vm-type}\_{network-role}\_v6\_ip\_{index}, NO
3671 OS::Neutron::Port, fixed_ips, ip_address, external, IPv6, comma\_delimited\_list, {vm-type}\_{network-role}\_v6\_ips, NO
3672 OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, string, {vm-type}\_int\_{network-role}\_ip\_{index}, YES
3673 OS::Neutron::Port, fixed_ips, ip_address, internal, IPv4, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_ips, YES
3674 OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, string, {vm-type}\_int\_{network-role}\_v6\_ip\_{index}, YES
3675 OS::Neutron::Port, fixed_ips, ip_address, internal, IPv6, comma\_delimited\_list, {vm-type}\_int\_{network-role}\_v6\_ips, YES
3681 *Example: comma_delimited_list parameters for IPv4 and IPv6 Address
3682 Assignments to an external network*
3684 In this example, the '{network-role}' has been defined as 'oam' to represent
3685 an oam network and the '{vm-type}' has been defined as 'db' for database.
3687 .. code-block:: python
3692 description: Neutron UUID for a oam network
3694 type: comma_delimited_list
3695 description: Fixed IPv4 assignments for db VMs on the oam network
3697 type: comma_delimited_list
3698 description: Fixed IPv6 assignments for db VMs on the oam network
3701 type: OS::Neutron::Port
3703 network: { get_param: oam_net_id }
3704 fixed_ips: [ { “ip_address”: {get_param: [ db_oam_ips, 0 ]}}, {
3705 “ip_address”: {get_param: [ db_oam_v6_ips, 0 ]}}]
3707 type: OS::Neutron::Port
3709 network: { get_param: oam_net_id }
3711 - “ip_address”: {get_param: [ db_oam_ips, 1 ]}
3712 - “ip_address”: {get_param: [ db_oam_v6_ips, 1 ]}
3714 *Example: string parameters for IPv4 and IPv6 Address Assignments to an
3717 In this example, the '{network-role}' has been defined as 'oam' to
3718 represent an oam network and the '{vm-type}' has been defined as 'db' for
3721 .. code-block:: python
3726 description: Neutron UUID for an OAM network
3729 description: Fixed IPv4 assignment for db VM 0 on the OAM network
3732 description: Fixed IPv4 assignment for db VM 1 on the OAM network
3735 description: Fixed IPv6 assignment for db VM 0 on the OAM network
3738 description: Fixed IPv6 assignment for db VM 1 on the OAM network
3741 type: OS::Neutron::Port
3743 network: { get_param: oam_net_id }
3744 fixed_ips: [ { “ip_address”: {get_param: db_oam_ip_0}}, { “ip_address”: {get_param: db_oam_v6_ip_0 ]}}]
3746 type: OS::Neutron::Port
3748 network: { get_param: oam_net_id }
3750 - “ip_address”: {get_param: db_oam_ip_1}}]
3751 - “ip_address”: {get_param: db_oam_v6_ip_1}}]
3754 *Example: comma_delimited_list parameters for IPv4 and IPv6 Address
3755 Assignments to an internal network*
3757 In this example, the '{network-role}' has been defined as 'ctrl' to
3758 represent an ctrl network internal to the vnf.
3759 The '{vm-type}' has been defined as 'db' for
3762 .. code-block:: python
3767 description: Neutron UUID for the ctrl internal network
3769 type: comma_delimited_list
3770 description: Fixed IPv4 assignments for db VMs on the ctrl internal
3773 type: comma_delimited_list
3774 description: Fixed IPv6 assignments for db VMs on the ctrl internal
3777 db_0_int_ctrl_port_0:
3778 type: OS::Neutron::Port
3780 network: { get_param: int_ctrl_net_id }
3781 fixed_ips: [ { “ip_address”: {get_param: [ db_int_ctrl_ips, 0 ]}}, {
3782 “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 0 ]}}]
3783 db_1_int_ctrl_port_0:
3784 type: OS::Neutron::Port
3786 network: { get_param: int_ctrl_net_id }
3788 - “ip_address”: {get_param: [ db_int_ctrl_ips, 1 ]}
3789 - “ip_address”: {get_param: [ db_int_ctrl_v6_ips, 1 ]}
3792 *Example: string parameters for IPv4 and IPv6 Address Assignments to an
3795 In this example, the int\_{network-role} has been defined as
3796 int_ctrl to represent a control network internal to the vnf.
3797 The {vm-type} has been defined as db for database.
3799 .. code-block:: python
3804 description: Neutron UUID for an OAM internal network
3807 description: Fixed IPv4 assignment for db VM on the oam_int network
3810 description: Fixed IPv4 assignment for db VM 1 on the oam_int network
3811 db_int_ctrl_v6_ip_0:
3813 description: Fixed IPv6 assignment for db VM 0 on the oam_int network
3814 db_int_ctrl_v6_ip_1:
3816 description: Fixed IPv6 assignment for db VM 1 on the oam_int network
3818 db_0_int_ctrl_port_0:
3819 type: OS::Neutron::Port
3821 network: { get_param: int_oam_int_net_id }
3822 fixed_ips: [ { “ip_address”: {get_param: db_oam_int_ip_0}}, {
3823 “ip_address”: {get_param: db_oam_int_v6_ip_0 ]}}]
3824 db_1_int_ctrl_port_0:
3825 type: OS::Neutron::Port
3827 network: { get_param: int_oam_int_net_id }
3829 - “ip_address”: {get_param: db_oam_int_ip_1}}]
3830 - “ip_address”: {get_param: db_oam_int_v6_ip_1}}]
3833 Property: fixed\_ips, Map Property: subnet\_id
3834 ++++++++++++++++++++++++++++++++++++++++++++++
3836 The resource 'OS::Neutron::Port' property 'fixed_ips' map
3837 property 'subnet'/'subnet_id' is used when a
3838 port is requesting an IP assignment via
3839 OpenStack’s DHCP Service (i.e., Cloud Assigned).
3841 The IP address assignment will be made from the specified subnet.
3843 Specifying the subnet is not required; it is optional.
3845 If the network (external or internal) that the port is attaching
3846 to only contains one subnet, specifying the subnet is
3847 superfluous. The IP address will be assigned from the one existing
3850 If the network (external or internal) that the port is attaching
3851 to contains two or more subnets, specifying the subnet in the
3852 'fixed_ips' map property 'subnet'/'subnet_id' determines which
3853 subnet the IP address will be assigned from.
3855 If the network (external or internal) that the port is attaching
3856 to contains two or more subnets, and the subnet is not is not
3857 specified, OpenStack will randomly(?) determine which subnet
3858 the IP address will be assigned from.
3860 The property fixed_ips is used to assign IPs to a port. The Map Property
3861 subnet_id specifies the subnet the IP is assigned from.
3863 R-38236 The VNF’s Heat Orchestration Template’s resource
3864 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property
3865 ‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’.
3867 R-62802 When the VNF’s Heat Orchestration Template’s resource
3868 ‘OS::Neutron::Port’ is attaching to an external network, and an IPv4
3869 address is being Cloud Assigned by OpenStack’s DHCP Service and the
3870 external network IPv4 subnet is to be specified using the property
3871 ‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
3872 follow the naming convention ‘{network-role}_subnet_id’, where
3873 ‘{network-role}’ is the network role of the network.
3875 R-83677 The VNF’s Heat Orchestration Template’s Resource
3876 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property
3877 subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’
3878 **MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
3881 ONAP's SDN-Controller provides the network's subnet's UUID
3882 value at orchestration to the Heat Orchestration Template.
3884 *Example Parameter Definition*
3886 .. code-block:: python
3890 {network-role}_subnet_id:
3892 description: Neutron IPv4 subnet UUID for the {network-role} network
3894 R-15287 When the VNF’s Heat Orchestration Template’s resource
3895 ‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
3896 address is being Cloud Assigned by OpenStack’s DHCP Service and the
3897 external network IPv6 subnet is to be specified using the property
3898 ‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
3899 follow the naming convention ‘{network-role}_subnet_v6_id’, where
3900 ‘{network-role}’ is the network role of the network.
3902 R-80829 The VNF’s Heat Orchestration Template’s Resource
3903 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property
3904 subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’
3905 **MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
3908 ONAP's SDN-Controller provides the network's subnet's UUID
3909 value at orchestration to the Heat Orchestration Template.
3911 *Example Parameter Definition*
3913 .. code-block:: python
3917 {network-role}_v6_subnet_id:
3919 description: Neutron IPv6 subnet UUID for the {network-role} network
3922 *Example: One Cloud Assigned IPv4 Address (DHCP) assigned to a network
3923 that has two or more IPv4 subnets*
3925 In this example, the '{network-role}' has been defined as 'oam' to represent
3926 an oam network and the '{vm-type}' has been defined as 'lb' for load
3927 balancer. The Cloud Assigned IP Address uses the OpenStack DHCP service
3928 to assign IP addresses.
3930 .. code-block:: python
3935 description: Neutron UUID for the oam network
3938 description: Neutron IPv4 subnet UUID for the oam network
3941 type: OS::Neutron::Port
3943 network: { get_param: oam_net_id }
3945 - subnet_id: { get_param: oam_subnet_id }
3947 *Example: One Cloud Assigned IPv4 address and one Cloud Assigned IPv6
3948 address assigned to a network that has at least one IPv4 subnet and one
3951 In this example, the '{network-role}' has been defined as 'oam' to represent
3952 an oam network and the '{vm-type}' has been defined as 'lb' for load
3955 .. code-block:: python
3960 description: Neutron UUID for the oam network
3963 description: Neutron IPv4 subnet UUID for the oam network
3966 description: Neutron IPv6 subnet UUID for the oam network
3969 type: OS::Neutron::Port
3971 network: { get_param: oam_net_id }
3973 - subnet_id: { get_param: oam_subnet_id }
3974 - subnet_id: { get_param: oam_v6_subnet_id }
3978 - the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
3979 in an Incremental Module is attaching to an internal network
3980 that is created in the Base Module, AND
3981 - an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND
3982 - the internal network IPv4 subnet is to be specified using the
3983 property ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
3985 the parameter **MUST** follow the naming convention
3986 ‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the
3987 network role of the internal network
3989 - Note that the parameter **MUST** be defined as an ‘output’ parameter in
3992 R-69634 The VNF’s Heat Orchestration Template’s Resource
3993 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property
3994 subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’
3995 **MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
3998 The assumption is that internal networks are created in the base module.
3999 The Neutron subnet network ID will be passed as an output parameter
4000 (e.g., ECOMP Base Module Output Parameter) to the incremental modules.
4001 In the incremental modules, the output parameter name will be defined as
4004 *Example Parameter Definition*
4006 .. code-block:: python
4010 int_{network-role}_subnet_id:
4012 description: Neutron IPv4 subnet UUID for the int_{network-role} network
4016 - the VNF’s Heat Orchestration Template’s resource
4017 ‘OS::Neutron::Port’ in an Incremental Module is attaching to an
4018 internal network that is created in the Base Module, AND
4019 - an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND
4020 - the internal network IPv6 subnet is to be specified using the property
4021 ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
4023 the parameter **MUST** follow the naming convention
4024 ‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
4025 is the network role of the internal network
4027 - Note that the parameter **MUST** be defined as an ‘output’ parameter in
4030 R-22288 The VNF’s Heat Orchestration Template’s Resource
4031 ‘OS::Neutron::Port’ property ‘fixed_ips’ map property
4032 ‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’
4033 **MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
4036 *Example Parameter Definition*
4038 .. code-block:: python
4042 int_{network-role}_v6_subnet_id:
4044 description: Neutron subnet UUID for the int_{network-role} network
4047 Property: allowed\_address\_pairs, Map Property: ip\_address
4048 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4050 The property allowed\_address\_pairs in the resource OS::Neutron::Port
4051 allows the user to specify a mac\_address and/or ip\_address that will
4052 pass through a port regardless of subnet. This enables the use of
4053 protocols such as VRRP, which floats an IP address between two instances
4054 to enable fast data plane failover. The map property ip\_address
4055 specifies the IP address.
4057 The allowed\_address\_pairs is an optional property. It is not required.
4059 An ONAP Heat Orchestration Template allows the assignment of one IPv4
4060 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
4061 and {network-role}/int\_{network-role} combination.
4063 An ONAP Heat Orchestration Template allows the assignment of one IPv6
4064 address allowed\_address\_pairs and/or one IPv6 address to a {vm-type}
4065 and {network-role}/int\_{network-role} combination.
4067 Note that the management of these IP addresses (i.e. transferring
4068 ownership between active and standby VMs) is the responsibility of the
4071 Note that these parameters are **not** intended to represent Neutron
4072 “Floating IP” resources, for which OpenStack manages a pool of public IP
4073 addresses that are mapped to specific VM ports. In that case, the
4074 individual VMs are not even aware of the public IPs, and all assignment
4075 of public IPs to VMs is via OpenStack commands. ONAP does not support
4076 Neutron-style Floating IPs.
4081 R-61282 The VNF Heat Orchestration Template **MUST**
4082 adhere to the following naming convention for the property
4083 allowed\_address\_pairs and Map Property ip\_address parameter,
4084 when the parameter is referencing an “external” network:
4086 - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
4088 - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
4090 The parameter must be declared as type: string
4092 The parameter must not be enumerated in the Heat environment file.
4094 *Example Parameter Definition*
4096 .. code-block:: yaml
4100 {vm-type}_{network-role}_floating_ip:
4102 description: VIP for {vm-type} VMs on the {network-role} network
4104 {vm-type}_{network-role}_floating_v6_ip:
4106 description: VIP for {vm-type} VMs on the {network-role} network
4110 In this example, the {network-role} has been defined as oam to represent
4111 an oam network and the {vm-type} has been defined as db for database.
4113 .. code-block:: yaml
4118 description: Neutron UUID for the oam network
4121 type: comma_delimited_list
4122 description: Fixed IPs for db VMs on the oam network
4126 description: VIP IP for db VMs on the oam network
4130 type: OS::Neutron::Port
4132 network: { get_param: oam_net_id }
4133 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,0] }}]
4134 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4137 type: OS::Neutron::Port
4139 network: { get_param: oam_net_id }
4140 fixed_ips: [ { “ip_address”: {get_param: [db_oam_ips,1] }}]
4141 allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
4146 R-16805 The VNF Heat Orchestration Template **MUST** adhere to the
4147 following naming convention for the property allowed\_address\_pairs
4148 and Map Property ip\_address parameter when the parameter is
4149 referencing an “internal” network.
4151 - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
4153 - {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
4155 The parameter must be declared as type: string
4157 The parameter must be enumerated in the Heat environment file.
4159 *Example Parameter Definition*
4161 .. code-block:: yaml
4165 {vm-type}_int_{network-role}_floating_ip:
4167 description: VIP for {vm-type} VMs on the int_{network-role} network
4169 {vm-type}_int_{network-role}_floating_v6_ip:
4171 description: VIP for {vm-type} VMs on the int_{network-role} network
4173 Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
4174 ______________________________________________________________________________
4176 The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
4177 allowed address pair IPv4 address per {vm-type} and {network-role} pair.
4179 The parameter {vm-type}\_{network-role}\_floating\_v6\_ip provides only
4180 one allowed address pair IPv6 address per {vm-type} and {network-role}
4183 If there is a need for multiple allowed address pair IPs for a given
4184 {vm-type} and {network-role} combination within a VNF, then the
4185 parameter names defined for the property fixed\_ips and Map Property
4186 ip\_address should be used with the allowed\_address\_pairs property.
4187 The examples below illustrate this.
4189 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
4191 In this example, there are two administrative VM pairs. Each pair has
4192 one VIP. The {network-role} has been defined as oam to represent an oam
4193 network and the {vm-type} has been defined as admin for an
4196 Pair 1: Resources admin\_0\_port\_0 and admin\_1\_port\_0 share a unique
4197 VIP, [admin\_oam\_ips,2]
4199 Pair 2: Resources admin\_2\_port\_0 and admin\_3\_port\_0 share a unique
4200 VIP, [admin\_oam\_ips,5]
4202 .. code-block:: yaml
4207 description: Neutron UUID for the oam network
4209 type: comma_delimited_list
4210 description: Fixed IP assignments for admin VMs on the oam network
4215 type: OS::Neutron::Port
4217 network: { get_param: oam_net_id }
4218 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,0] }}]
4219 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4222 type: OS::Neutron::Port
4224 network: { get_param: oam_net_id }
4225 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,1] }}]
4226 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,2] }}]
4229 type: OS::Neutron::Port
4231 network: { get_param: oam_net_id }
4232 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,3] }}]
4233 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4236 type: OS::Neutron::Port
4238 network: { get_param: oam_net_id }
4239 fixed_ips: [ { “ip_address”: {get_param: [admin_oam_ips,4] }}]
4240 allowed_address_pairs: [{ “ip_address”: {get_param: [admin_oam_ips,5] }}]
4242 *Example: A VNF has two load balancers. The pair of load balancers share
4245 In this example, there is one load balancer pairs. The pair has two
4246 VIPs. The {network-role} has been defined as oam to represent an oam
4247 network and the {vm-type} has been defined as lb for a load balancer VM.
4249 .. code-block:: yaml
4253 type: OS::Neutron::Port
4255 network: { get_param: oam_net_id }
4256 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,0] }}]
4257 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4260 type: OS::Neutron::Port
4262 network: { get_param: oam_net_id }
4263 fixed_ips: [ { “ip_address”: {get_param: [lb_oam_ips,1] }}]
4264 allowed_address_pairs: [{ "ip_address": {get_param: [lb_oam_ips,2]}, {get_param: [lb_oam_ips,3] }}]
4266 As a general rule, provide the fixed IPs for the VMs indexed first in
4267 the CDL and then the VIPs as shown in the examples above.
4269 ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
4270 __________________________________________________________________
4272 The following items must be taken into consideration when designing Heat
4273 Orchestration Templates that expect ONAP’s SDN-C to assign
4274 allowed\_address\_pair IP addresses via automation.
4276 The VMs must be of the same {vm-type}.
4278 The VMs must be created in the same module (base or incremental).
4280 Resource Property “name”
4281 ~~~~~~~~~~~~~~~~~~~~~~~~
4283 The parameter naming convention of the property name for the resource
4284 OS::Nova::Server has been defined in
4285 `Resource: OS::Nova::Server – Metadata Parameters`_.
4287 This section provides the requirements how the property name for non
4288 OS::Nova::Server resources must be defined when the property is used.
4289 Not all resources require the property name (e.g., it is optional) and
4290 some resources do not support the property.
4292 R-85734 The VNF Heat Orchestration Template **MUST** use the
4293 intrinsic function str\_replace in conjunction with the ONAP
4294 supplied metadata parameter vnf\_name to generate a unique
4295 value, when the property name for a non OS::Nova::Server
4296 resources is defined in a Heat Orchestration Template.
4298 This prevents the enumeration of a
4299 unique value for the property name in a per instance environment file.
4303 - In most cases, only the use of the metadata value vnf\_name is
4304 required to create a unique property name
4306 - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’
4307 may also be used in the str\_replace construct to generate a unique
4308 name when the vnf\_name does not provide uniqueness
4310 *Example: Property* name *for resource* OS::Neutron::SecurityGroup
4312 .. code-block:: yaml
4316 type: OS::Neutron::SecurityGroup
4318 description: vDNS security group
4321 template: VNF_NAME_sec_grp_DNS
4323 VNF_NAME: {get_param: vnf_name}
4327 *Example: Property name for resource* OS::Cinder::Volume
4329 .. code-block:: yaml
4333 type: OS::Cinder::Volume
4335 description: Cinder Volume
4338 template: VNF_NAME_STACK_NAME_dns_volume
4340 VNF_NAME: {get_param: vnf_name}
4341 STACK_NAME: { get_param: 'OS::stack_name' }
4344 Contrail Issue with Values for the Property Name
4345 ++++++++++++++++++++++++++++++++++++++++++++++++
4347 The Contrail GUI has a limitation displaying special characters. The
4348 issue is documented in
4349 https://bugs.launchpad.net/juniperopenstack/+bug/1590710. It is
4350 recommended that special characters be avoided. However, if special
4351 characters must be used, note that for the following resources:
4365 the only special characters supported are:
4367 - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
4369 ONAP Output Parameter Names
4370 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
4372 ONAP defines three types of Output Parameters as detailed in
4373 `Output Parameters`_.
4375 ONAP Base Module Output Parameters:
4376 +++++++++++++++++++++++++++++++++++
4378 ONAP Base Module Output Parameters do not have an explicit naming
4379 convention. The parameter name must contain {vm-type} and {network-role}
4382 ONAP Volume Template Output Parameters:
4383 +++++++++++++++++++++++++++++++++++++++
4385 ONAP Base Module Output Parameters do not have an explicit naming
4386 convention. The parameter name must contain {vm-type} when appropriate.
4388 Predefined Output Parameters
4389 ++++++++++++++++++++++++++++
4391 ONAP currently defines one predefined output parameter the OAM
4392 Management IP Addresses.
4394 OAM Management IP Addresses
4395 ___________________________
4397 A VNF may have a management interface for application controllers to
4398 interact with and configure the VNF. Typically, this will be via a
4399 specific VM that performs a VNF administration function. The IP address
4400 of this interface must be captured and inventoried by ONAP. The IP
4401 address might be a VIP if the VNF contains an HA pair of management VMs,
4402 or may be a single IP address assigned to one VM.
4404 The Heat template may define either (or both) of the following Output
4405 parameters to identify the management IP address.
4407 - oam\_management\_v4\_address
4409 - oam\_management\_v6\_address
4413 - The use of this output parameters are optional.
4415 - The Management IP Address should be defined only once per VNF, so it
4416 must only appear in one Module template
4418 - If a fixed IP for the admin VM is passed as an input parameter, it
4419 may be echoed in the output parameters. In this case, a IPv4 and/or
4420 IPv6 parameter must be defined in the parameter section of the YAML
4421 Heat template. The parameter maybe named oam\_management\_v4\_address
4422 and/or oam\_management\_v6\_address or may be named differently.
4424 - If the IP for the admin VM is obtained via DHCP, it may be obtained
4425 from the resource attributes. In this case,
4426 oam\_management\_v4\_address and/or oam\_management\_v6\_address must
4427 not be defined in the parameter section of the YAML Heat template.
4429 *Example: SDN-C Assigned IP Address echoed as*
4430 oam\_management\_v4\_address
4432 .. code-block:: yaml
4437 description: Fixed IPv4 assignment for admin VM 0 on the OAM network
4441 admin_oam_net_0_port:
4442 type: OS::Neutron::Port
4446 template: VNF_NAME_admin_oam_net_0_port
4448 VNF_NAME: {get_param: vnf_name}
4449 network: { get_param: oam_net_id }
4450 fixed_ips: [{ "ip_address": { get_param: admin_oam_ip_0 }}]
4451 security_groups: [{ get_param: security_group }]
4454 type: OS::Nova::Server
4456 name: { get_param: admin_names }
4457 image: { get_param: admin_image_name }
4458 flavor: { get_param: admin_flavor_name }
4459 availability_zone: { get_param: availability_zone_0 }
4461 - port: { get_resource: admin_oam_net_0_port }
4463 vnf_id: { get_param: vnf_id }
4464 vf_module_id: { get_param: vf_module_id }
4465 vnf_name: {get_param: vnf_name }
4467 oam_management_v4_address:
4468 value: {get_param: admin_oam_ip_0 }
4470 *Example: Cloud Assigned IP Address output as*
4471 oam\_management\_v4\_address
4473 .. code-block:: yaml
4478 admin_oam_net_0_port:
4479 type: OS::Neutron::Port
4483 template: VNF_NAME_admin_oam_net_0_port
4485 VNF_NAME: {get_param: vnf_name}
4486 network: { get_param: oam_net_id }
4487 security_groups: [{ get_param: security_group }]
4490 type: OS::Nova::Server
4492 name: { get_param: admin_names }
4493 image: { get_param: admin_image_name }
4494 flavor: { get_param: admin_flavor_name }
4495 availability_zone: { get_param: availability_zone_0 }
4497 - port: { get_resource: admin_oam_net_0_port }
4499 vnf_id: { get_param: vnf_id }
4500 vf_module_id: { get_param: vf_module_id }
4501 vnf_name: {get_param: vnf_name }
4504 oam_management_v4_address:
4505 value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
4507 Contrail Resource Parameters
4508 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4510 ONAP requires the parameter names of certain Contrail Resources to
4511 follow specific naming conventions. This section provides these
4514 Contrail Network Parameters
4515 +++++++++++++++++++++++++++
4517 Contrail based resources may require references to a Contrail network
4518 using the network FQDN.
4523 When the parameter associated with the Contrail Network is referencing
4524 an “external” network, the parameter must adhere to the following naming
4525 convention in the Heat Orchestration Template
4527 - {network-role}\_net\_fqdn
4529 The parameter must be declared as type: string
4531 The parameter must not be enumerated in the Heat environment file.
4533 *Example: Parameter declaration*
4535 .. code-block:: yaml
4538 {network-role}_net_fqdn:
4540 description: Contrail FQDN for the {network-role} network
4542 *Example: Contrail Resource OS::ContrailV2::VirtualMachineInterface
4543 Reference to a Network FQDN.*
4545 In this example, the {network-role} has been defined as oam to represent
4546 an oam network and the {vm-type} has been defined as fw for firewall.
4547 The Contrail resource OS::ContrailV2::VirtualMachineInterface property
4548 virtual\_network\_refs references a contrail network FQDN.
4550 .. code-block:: yaml
4553 type: OS::ContrailV2::VirtualMachineInterface
4557 template: VM_NAME_virtual_machine_interface_1
4559 VM_NAME: { get_param: fw_name_0 }
4560 virtual_machine_interface_properties:
4561 virtual_machine_interface_properties_service_interface_type: { get_param: oam_protected_interface_type }
4562 virtual_network_refs:
4563 - get_param: oam_net_fqdn
4564 security_group_refs:
4565 - get_param: fw_sec_grp_id
4567 Interface Route Table Prefixes for Contrail InterfaceRoute Table
4568 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4570 The parameter associated with the resource
4571 OS::ContrailV2::InterfaceRouteTable property
4572 interface\_route\_table\_routes, map property
4573 interface\_route\_table\_routes\_route\_prefix is an ONAP Orchestration
4576 The parameters must be named {vm-type}\_{network-role}\_route\_prefixes
4577 in the Heat Orchestration Template.
4579 The parameter must be declared as type: json
4581 The parameter supports IP addresses in the format:
4583 1. Host IP Address (e.g., 10.10.10.10)
4585 2. CIDR Notation format (e.g., 10.0.0.0/28)
4587 The parameter must not be enumerated in the Heat environment file.
4589 *Example Parameter Definition*
4591 .. code-block:: yaml
4594 {vm-type}_{network-role}_route_prefixes:
4596 description: JSON list of Contrail Interface Route Table route prefixes
4600 .. code-block:: yaml
4605 description: Unique name for this VF instance
4606 fw_int_fw_route_prefixes:
4608 description: prefix for the ServiceInstance InterfaceRouteTable
4609 int_fw_dns_trusted_interface_type:
4611 description: service_interface_type for ServiceInstance
4614 type: OS::ContrailV2::InterfaceRouteTable
4615 depends_on: [*resource name of* *OS::ContrailV2::ServiceInstance*]
4619 template: VNF_NAME_interface_route_table
4621 VNF_NAME: { get_param: vnf_name }
4622 interface_route_table_routes:
4623 interface_route_table_routes_route: { get_param: fw_int_fw_route_prefixes }
4624 service_instance_refs:
4625 - get_resource: < *resource name of* *OS::ContrailV2::ServiceInstance* >
4626 service_instance_refs_data:
4627 - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
4629 Parameter Names in Contrail Resources
4630 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4632 Contrail Heat resource properties will use, when appropriate, the same
4633 naming convention as OpenStack Heat resources. For example, the resource
4634 OS::ContrailV2::InstanceIp has two properties that the parameter naming
4635 convention is identical to properties in OS::Neutron::Port.
4637 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4638 instance\_ip\_address*
4640 The property instance\_ip\_address uses the same parameter naming
4641 convention as the property fixed\_ips and Map Property ip\_address in
4642 OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP
4643 Address. The {network-role} has been defined as oam\_protected to
4644 represent an oam protected network and the {vm-type} has been defined as
4647 .. code-block:: yaml
4649 CMD_FW_OAM_PROTECTED_RII:
4650 type: OS::ContrailV2::InstanceIp
4652 - FW_OAM_PROTECTED_RVMI
4654 virtual_machine_interface_refs:
4655 - get_resource: FW_OAM_PROTECTED_RVMI
4656 virtual_network_refs:
4657 - get_param: oam_protected_net_fqdn
4658 instance_ip_address: { get_param: [fw_oam_protected_ips, get_param: index ] }
4660 *Example: Contrail Resource OS::ContrailV2::InstanceIp, Property
4663 The property instance\_ip\_address uses the same parameter naming
4664 convention as the property fixed\_ips and Map Property subnet\_id in
4665 OS::Neutron::Port. The resource is assigning a Cloud Assigned IP
4666 Address. The {network-role} has been defined as “oam\_protected” to
4667 represent an oam protected network and the {vm-type} has been defined as
4670 .. code-block:: yaml
4672 CMD_FW_SGI_PROTECTED_RII:
4673 type: OS::ContrailV2::InstanceIp
4675 - FW_OAM_PROTECTED_RVMI
4677 virtual_machine_interface_refs:
4678 - get_resource: FW_OAM_PROTECTED_RVMI
4679 virtual_network_refs:
4680 - get_param: oam_protected_net_fqdn
4681 subnet_uuid: { get_param: oam_protected_subnet_id }
4683 Cinder Volume Templates
4684 ^^^^^^^^^^^^^^^^^^^^^^^^
4686 ONAP supports the independent deployment of a Cinder volume via separate
4687 Heat Orchestration Templates, the Cinder Volume module. This allows the
4688 volume to persist after VNF deletion so that they can be reused on
4689 another instance (e.g., during a failover activity).
4691 A Base Module or Incremental Module may have a corresponding volume
4692 module. Use of separate volume modules is optional. A Cinder volume may
4693 be embedded within the Base Module or Incremental Module if persistence
4696 R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
4697 scope of a cinder volume module, when it exists, with the
4698 Base Module or Incremental Module
4700 A single volume module must create only the volumes
4701 required by a single Incremental module or Base module.
4703 The following rules apply to independent volume Heat templates:
4705 - Cinder volumes must be created in a separate Heat Orchestration
4706 Template from the Base Module or Incremental Module.
4708 - A single Cinder volume module must include all Cinder volumes
4709 needed by the Base/Incremental module.
4711 - R-79531 The VNF Heat Orchestration Template **MUST** define
4712 “outputs” in the volume template for each Cinder volume
4713 resource universally unique identifier (UUID) (i.e. ONAP
4714 Volume Template Output Parameters).
4716 - The VNF Incremental Module or Base Module must define input
4717 parameters that match each Volume output parameter (i.e., ONAP Volume
4718 Template Output Parameters).
4720 - ONAP will supply the volume template outputs automatically to the
4721 bases/incremental template input parameters.
4723 - Volume modules may utilize nested Heat templates.
4725 *Examples: Volume Template*
4727 A VNF has a Cinder volume module, named incremental\_volume.yaml, that
4728 creates an independent Cinder volume for a VM in the module
4729 incremental.yaml. The incremental\_volume.yaml defines a parameter in
4730 the output section, lb\_volume\_id\_0 which is the UUID of the cinder
4731 volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
4732 ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
4733 output statement and provides the value to the incremental module.
4735 Note that the example below is not a complete Heat Orchestration
4736 Template. The {vm-type} has been defined as “lb” for load balancer
4738 incremental\_volume.yaml
4740 .. code-block:: yaml
4751 type: OS::Cinder::Volume
4755 template: VNF_NAME_volume_0
4757 VNF_NAME: { get_param: vnf_name }
4758 size: {get_param: dns_volume_size_0}
4763 value: {get_resource: dns_volume_0}
4769 .. code-block:: yaml
4780 type: OS::Nova::Server
4782 name: {get_param: dns_name_0}
4787 type: OS::Cinder::VolumeAttachment
4789 instance_uuid: { get_resource: lb_0 }
4790 volume_id: { get_param: lb_volume_id_0 }
4792 ONAP Support of Environment Files
4793 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4795 The use of an environment file in OpenStack is optional. In ONAP, it is
4798 R-86285 The VNF Heat Orchestration Template **MUST** have a
4799 corresponding environment file, even if no parameters are required to be
4802 (Note that ONAP, the open source version of ONAP, does not
4803 programmatically enforce the use of an environment file.)
4805 R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
4806 environment file for a Base Module.
4808 R-35727 The VNF Heat Orchestration Template **MUST** have a
4809 corresponding environment file for an Incremental module.
4811 R-22656 The VNF Heat Orchestration Template **MUST** have a
4812 corresponding environment file for a Cinder Volume Module.
4814 A nested heat template must not have an environment file; OpenStack does
4817 The environment file must contain parameter values for the ONAP
4818 Orchestration Constants and VNF Orchestration Constants. These
4819 parameters are identical across all instances of a VNF type, and
4820 expected to change infrequently. The ONAP Orchestration Constants are
4821 associated with OS::Nova::Server image and flavor properties (See
4822 `Property: image`_ and `Property: flavor`_). Examples of VNF
4823 Orchestration Constants are the networking parameters associated
4824 with an internal network (e.g., private IP ranges) and Cinder
4827 The environment file must not contain parameter values for parameters
4828 that are instance specific (ONAP Orchestration Parameters, VNF
4829 Orchestration Parameters). These parameters are supplied to the Heat by
4830 ONAP at orchestration time.
4832 SDC Treatment of Environment Files
4833 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4835 Parameter values enumerated in the environment file are used by SDC as
4836 the default value. However, the SDC user may use the SDC GUI to
4837 overwrite the default values in the environment file.
4839 SDC generates a new environment file for distribution to MSO based on
4840 the uploaded environment file and the user provided GUI updates. The
4841 user uploaded environment file is discarded when the new file is
4842 created. Note that if the user did not change any values via GUI
4843 updates, the SDC generated environment file will contain the same values
4844 as the uploaded file.
4846 Use of Environment Files when using OpenStack “heat stack-create” CLI
4847 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4849 When ONAP is instantiating the Heat Orchestration Template, certain
4850 parameter must not be enumerated in the environment file. This document
4851 provides the details of what parameters should not be enumerated.
4853 If the Heat Orchestration Template is to be instantiated from the
4854 OpenStack Command Line Interface (CLI) using the command “heat
4855 stack-create”, all parameters must be enumerated in the environment
4858 Heat Template Constructs
4859 ^^^^^^^^^^^^^^^^^^^^^^^^^
4861 Nested Heat Templates
4862 ~~~~~~~~~~~~~~~~~~~~~
4864 ONAP supports nested Heat templates per the OpenStack specifications.
4865 Nested templates may be suitable for larger VNFs that contain many
4866 repeated instances of the same VM type(s). A common usage pattern is to
4867 create a nested template for each {vm-type} along with its supporting
4868 resources. The VNF module may then reference these component templates
4869 either statically by repeated definition or dynamically by using the
4870 resource OS::Heat::ResourceGroup.
4872 Nested Heat Template Requirements
4873 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4875 ONAP supports nested Heat Orchestration Templates. A Base Module,
4876 Incremental Module, and Cinder Volume Module may use nested heat.
4878 A Heat Orchestration Template may reference the nested heat statically
4879 by repeated definition.
4881 A Heat Orchestration Template may reference the nested heat dynamically
4882 using the resource OS::Heat::ResourceGroup.
4884 A Heat Orchestration template must have no more than three levels of
4885 nesting. ONAP supports a maximum of three levels.
4887 Nested heat templates must be referenced by file name. The use of
4888 resource\_registry in the environment file is not supported and must not
4891 R-89868 The VNF Heat Orchestration Template **MUST** have unique
4892 file names within the scope of the VNF for a nested heat yaml file.
4894 R-52530 The VNF Heat Orchestration Template **MUST NOT** use a
4895 directory hierarchy for nested templates. All templates must
4896 be in a single, flat directory (per VNF).
4898 A nested heat template may be used by any module within a given VNF.
4902 - Constrains must not be defined for any parameter enumerated in a
4903 nested heat template.
4905 - R-11041 The VNF Heat Orchestration Template **MUST** have the
4906 resource calling the nested yaml file pass in as properties
4907 all parameters defined in nested yaml file.
4909 - R-61183 The VNF Heat Orchestration Template **MUST NOT**
4910 change the parameter names, when OS::Nova::Server metadata
4911 parameters are past into a nested heat template.
4913 - With nested templates, outputs are required to expose any resource
4914 properties of the child templates to the parent template. Those would
4915 not explicitly be declared as parameters but simply referenced as
4916 get\_attribute targets against the “parent” resource.
4918 Nested Heat Template Example: Static
4919 ++++++++++++++++++++++++++++++++++++++
4923 .. code-block:: yaml
4929 dns_image_name: { get_param: dns_image_name }
4930 dns_flavor_name: { get_param: dns_flavor_name }
4931 availability_zone: { get_param: availability_zone_0 }
4932 security_group: { get_param: DNS_shared_sec_grp_id }
4933 oam_net_id: { get_param: oam_protected_net_id }
4934 dns_oam_ip: { get_param: dns_oam_ip_0 }
4935 dns_name: { get_param: dns_name_0 }
4936 vnf_name: { get_param: vnf_name }
4937 vnf_id: { get_param: vnf_id }
4938 vf_module_id: {get_param: vf_module_id}
4943 dns_image_name: { get_param: dns_image_name }
4944 dns_flavor_name: { get_param: dns_flavor_name }
4945 availability_zone: { get_param: availability_zone_1 }
4946 security_group: { get_param: DNS_shared_sec_grp_id }
4947 oam_net_id: { get_param: oam_protected_net_id }
4948 dns_oam_ip: { get_param: dns_oam_ip_1 }
4949 dns_name: { get_param: dns_name_1 }
4950 vnf_name: { get_param: vnf_name }
4951 vnf_id: { get_param: vnf_id }
4952 vf_module_id: {get_param: vf_module_id}
4956 .. code-block:: yaml
4959 type: OS::Neutron::Port
4963 template: VNF_NAME_dns_oam_port
4965 VNF_NAME: {get_param: vnf_name}
4966 network: { get_param: oam_net_id }
4967 fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
4968 security_groups: [{ get_param: security_group }]
4971 type: OS::Nova::Server
4973 name: { get_param: dns_names }
4974 image: { get_param: dns_image_name }
4975 flavor: { get_param: dns_flavor_name }
4976 availability_zone: { get_param: availability_zone }
4978 - port: { get_resource: dns_oam_0_port }
4980 vnf_id: { get_param: vnf_id }
4981 vf_module_id: { get_param: vf_module_id }
4982 vnf_name {get_param: vnf_name }
4984 Use of Heat ResourceGroup
4985 +++++++++++++++++++++++++
4987 The OS::Heat::ResourceGroup is a useful Heat element for creating
4988 multiple instances of a given resource or collection of resources.
4989 Typically, it is used with a nested Heat template, to create, for
4990 example, a set of identical OS::Nova::Server resources plus their
4991 related OS::Neutron::Port resources via a single resource in a master
4994 ResourceGroup may be used in ONAP to simplify the structure of a Heat
4995 template that creates multiple instances of the same VM type.
4997 However, there are important caveats to be aware of:
4999 ResourceGroup does not deal with structured parameters
5000 (comma-delimited-list and json) as one might typically expect. In
5001 particular, when using a list-based parameter, where each list element
5002 corresponds to one instance of the ResourceGroup, it is not possible to
5003 use the intrinsic “loop variable” %index% in the ResourceGroup
5006 For instance, the following is **not** valid Heat for ResourceGroup:
5008 .. code-block:: yaml
5010 type: OS::Heat::ResourceGroup
5012 type: my_nested_vm_template.yaml
5014 name: {get_param: [vm_name_list, %index%]}
5016 Although this appears to use the nth entry of the vm\_name\_list list
5017 for the nth element of the ResourceGroup, it will in fact result in a
5018 Heat exception. When parameters are provided as a list (one for each
5019 element of a ResourceGroup), you must pass the complete parameter to the
5020 nested template along with the current index as separate parameters.
5022 Below is an example of an **acceptable** Heat Syntax for a
5025 .. code-block:: yaml
5027 type: OS::Heat::ResourceGroup
5029 type: my_nested_vm_template.yaml
5031 names: {get_param: vm_name_list}
5034 You can then reference within the nested template as:
5036 { get\_param: [names, {get\_param: index} ] }
5038 ResourceGroup Property count
5039 ____________________________
5041 ONAP requires that the OS::Heat::ResourceGroup property count be defined
5042 (even if the value is one) and that the value must be enumerated in the
5043 environment file. This is required for ONAP to build the TOSCA model for
5046 .. code-block:: yaml
5048 type: OS::Heat::ResourceGroup
5050 count: { get_param: count }
5053 type: my_nested_vm_template.yaml
5055 names: {get_param: vm_name_list}
5058 Availability Zone and ResourceGroups
5059 ____________________________________
5061 The resource OS::Heat::ResourceGroup and the property availability\_zone
5062 has been an “issue” with a few VNFs since ONAP only supports
5063 availability\_zone as a string parameter and not a
5064 comma\_delimited\_list. This makes it difficult to use a ResourceGroup
5065 to create Virtual Machines in more than one availability zone.
5067 There are numerous solutions to this issue. Below are two suggested
5070 **Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
5071 resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
5072 availability\_zones by using the intrinsic function list\_join.
5074 .. code-block:: yaml
5077 type: OS::Heat::ResourceGroup
5079 count: { get_param: node_count }
5085 avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
5089 .. code-block:: yaml
5092 avaialability_zones:
5093 type: comma_delimited_list
5098 type: OS::Nova::Server
5100 name: { get_param: [ dns_names, get_param: index ] }
5101 image: { get_param: dns_image_name }
5102 flavor: { get_param: dns_flavor_name }
5103 availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
5106 **Option 2:** Create a resource group per availability zone. A separate
5107 OS::Heat::ResourceGroup is created for each availability zone.
5112 Heat templates *should not* reference any HTTP-based resource
5113 definitions, any HTTP-based nested configurations, or any HTTP-based
5116 - During orchestration, ONAP *should not* retrieve any such resources
5117 from external/untrusted/unknown sources.
5119 - VNF images should not contain such references in user-data or other
5120 configuration/operational scripts that are specified via Heat or
5121 encoded into the VNF image itself.
5123 *Note:* HTTP-based references are acceptable if the HTTP-based reference
5124 is accessing information with the VM private/internal network.
5126 Heat Files Support (get\_file)
5127 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5129 Heat Templates may contain the inclusion of text files into Heat
5130 templates via the Heat get\_file directive. This may be used, for
5131 example, to define a common “user-data” script, or to inject files into
5132 a VM on startup via the “personality” property.
5134 Support for Heat Files is subject to the following limitations:
5136 R-76718 The VNF Heat Orchestration Template **MUST** reference
5137 the get\_files targets in Heat templates by file name, and the
5138 corresponding files should be delivered to ONAP along with the
5141 R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
5143 R-62177 The VNF Heat Orchestration Template **MUST** have unique
5144 file names for the included files within the scope of the VNF.
5146 R-87848 The VNF Heat Orchestration Template **MUST** have all
5147 included files in a single, flat directory per VNF. ONAP does
5148 not support a directory hierarchy.
5150 - Included files may be used by all Modules within a given VNF.
5152 - get\_file directives may be used in both non-nested and nested
5158 When Nova Servers are created via Heat templates, they may be passed a
5159 “keypair” which provides an ssh key to the ‘root’ login on the newly
5160 created VM. This is often done so that an initial root key/password does
5161 not need to be hard-coded into the image.
5163 Key pairs are unusual in OpenStack, because they are the one resource
5164 that is owned by an OpenStack User as opposed to being owned by an
5165 OpenStack Tenant. As a result, they are usable only by the User that
5166 created the keypair. This causes a problem when a Heat template attempts
5167 to reference a keypair by name, because it assumes that the keypair was
5168 previously created by a specific ONAP user ID.
5170 When a keypair is assigned to a server, the SSH public-key is
5171 provisioned on the VMs at instantiation time. They keypair itself is not
5172 referenced further by the VM (i.e. if the keypair is updated with a new
5173 public key, it would only apply to subsequent VMs created with that
5176 Due to this behavior, the recommended usage of keypairs is in a more
5177 generic manner which does not require the pre-requisite creation of a
5178 keypair. The Heat should be structured in such a way as to:
5180 - Pass a public key as a parameter value instead of a keypair name
5182 - Create a new keypair within The VNF Heat Orchestration Template (in the base
5183 module) for use within that VNF
5185 By following this approach, the end result is the same as pre-creating
5186 the keypair using the public key – i.e., that public key will be
5187 provisioned in the new VM. However, this recommended approach also makes
5188 sure that a known public key is supplied (instead of having OpenStack
5189 generate a public/private pair to be saved and tracked outside of ONAP).
5190 It also removes any access/ownership issues over the created keypair.
5192 The public keys may be enumerated as a VNF Orchestration Constant in the
5193 environment file (since it is public, it is not a secret key), or passed
5194 at run-time as instance-specific parameters. ONAP will never
5195 automatically assign a public/private key pair.
5197 *Example (create keypair with an existing ssh public-key for {vm-type}
5198 of lb (for load balancer)):*
5200 .. code-block:: yaml
5210 type: OS::Nova::Keypair
5214 template: VNF_NAME_key_pair
5216 VNF_NAME: { get_param: vnf_name }
5217 public_key: {get_param: lb_ssh_public_key}
5218 save_private_key: false
5223 OpenStack allows a tenant to create Security groups and define rules
5224 within the security groups.
5226 Security groups, with their rules, may either be created in the Heat
5227 Orchestration Template or they can be pre-created in OpenStack and
5228 referenced within the Heat template via parameter(s). There can be a
5229 different approach for security groups assigned to ports on internal
5230 (intra-VNF) networks or external networks (inter-VNF). Furthermore,
5231 there can be a common security group across all VMs for a specific
5232 network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
5235 Anti-Affinity and Affinity Rules
5236 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5238 Anti-affinity or affinity rules are supported using normal OpenStack
5239 OS::Nova::ServerGroup resources. Separate ServerGroups are typically
5240 created for each VM type to prevent them from residing on the same host,
5241 but they can be applied to multiple VM types to extend the
5242 affinity/anti-affinity across related VM types as well.
5246 In this example, the {network-role} has been defined as oam to represent
5247 an oam network and the {vm-type} have been defined as lb for load
5248 balancer and db for database.
5250 .. code-block:: yaml
5254 type: OS::Nova::ServerGroup
5259 $vnf_name: {get_param: vnf_name}
5260 template: $vnf_name-server_group1
5265 type: OS::Nova::ServerGroup
5270 $vnf_name: {get_param: vnf_name}
5271 template: $vnf_name-server_group2
5276 type: OS::Nova::Server
5280 group: {get_resource: db_server_group}
5283 type: OS::Nova::Server
5287 group: {get_resource: db_server_group}
5290 type: OS::Nova::Server
5294 group: {get_resource: lb_server_group}
5296 Resource Data Synchronization
5297 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5299 For cases where synchronization is required in the orchestration of Heat
5300 resources, two approaches are recommended:
5302 - Standard Heat depends\_on property for resources
5304 - Assures that one resource completes before the dependent resource
5307 - Definition of completeness to OpenStack may not be sufficient
5308 (e.g., a VM is considered complete by OpenStack when it is ready
5309 to be booted, not when the application is up and running).
5311 - Use of Heat Notifications
5313 - Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
5316 - Pre-requisite resources issue *wc\_notify* commands in user\_data.
5318 - Dependent resource define depends\_on in the
5319 OS::Heat::WaitCondition resource.
5321 *Example: “depends\_on” case*
5323 In this example, the {network-role} has been defined as oam to represent
5324 an oam network and the {vm-type} has been defined as oam to represent an
5327 .. code-block:: yaml
5331 type: OS::Nova::Server
5333 name: {get_param: [oam_ names, 0]}
5334 image: {get_param: oam_image_name}
5335 flavor: {get_param: oam_flavor_name}
5336 availability_zone: {get_param: availability_zone_0}
5338 - port: {get_resource: oam01_port_0}
5339 - port: {get_resource: oam01_port_1}
5341 scheduler_hints: {group: {get_resource: oam_servergroup}}
5342 user_data_format: RAW
5345 type: OS::Neutron::Port
5347 network: {get_resource: oam_net_name}
5348 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
5349 security_groups: [{get_resource: oam_security_group}]
5352 type: OS::Neutron::Port
5354 network: {get_param: oam_net_name}
5355 fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
5356 security_groups: [{get_resource: oam_security_group}]
5358 oam_01_vol_attachment:
5359 type: OS::Cinder::VolumeAttachment
5360 depends_on: oam_server_01
5362 volume_id: {get_param: oam_vol_1}
5363 mountpoint: /dev/vdb
5364 instance_uuid: {get_resource: oam_server_01}
5369 VNF/VM parameters may include availability zone IDs for VNFs that
5370 require high availability.
5372 The Heat must comply with the following requirements to specific
5373 availability zone IDs:
5375 - The Heat template should spread Nova and Cinder resources across the
5376 availability zones as desired
5378 Post Orchestration & VNF Configuration
5379 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5381 Heat templates should contain a minimum amount of post-orchestration
5382 configuration data. For instance, *do not* embed complex user-data
5383 scripts in the template with large numbers of configuration parameters
5384 to the Heat template.
5386 - VNFs may provide configuration APIs for use after VNF creation. Such
5387 APIs will be invoked via application and/or SDN controllers.
5389 *Note:* It is important to follow this convention to the extent possible
5390 even in the short-term as of the long-term direction.
5392 VNFM Driver Development Steps
5393 -----------------------------------------------------------
5395 Refer to the ONAP documentation for VNF Provider instructions on integrating
5396 vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
5399 1. Use the VNF SDK tools to design the VNF with TOSCA models to output
5400 the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
5401 validated and tested.
5403 2. The VNF Provider supplies a vendor-specific VNFM driver in ONAP, which
5404 is a microservice providing a translation interface from VF-C to
5405 the vendor-specific VNFM. The interface definitions of vendor-specific
5406 VNFM adaptors are supplied by the VNF Providers themselves.
5408 Creating Vendor-Specific VNFM Adaptor Microservices
5409 ------------------------------------------------------------------------------------------------
5411 VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific
5412 VNFM to ONAP, a vendor-specific VNFM adaptor is added to ONAP implementing
5413 the interface of the vendor-specific VNFM.
5415 A vendor-specific VNFM adaptor is a microservice with a unique name and
5416 an appointed port. When started up, the vendor-specific VNFM adaptor
5417 microservice is automatically registered to the Microservices Bus (MSB).
5418 The following RESTful example describes the scenario of registering a
5419 vendor-specific VNFM adaptor to MSB:
5421 .. code-block:: java
5423 POST /api/microservices/v1/services
5425 "serviceName": "catalog",
5427 "url": "/api/catalog/v1",
5432 "ip": "10.74.56.36",
Code Review / vnfrqts / requirements.git / blob