resource OS::Heat::ResourceGroup.
Nested Heat Template Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-ONAP supports nested Heat Orchestration Templates. A Base Module,
-Incremental Module, and Cinder Volume Module may use nested heat.
+ONAP supports nested Heat Orchestration Templates.
+As stated in Requirements :need:`R-36582`, :need:`R-56721`, and
+:need:`R-30395`, a Base Module, Incremental Module, and Cinder Volume
+Module may use nested heat.
.. req::
:id: R-00228
:id: R-01101
:target: VNF
:keyword: MAY
+ :updated: casablanca
A VNF's Heat Orchestration Template **MAY**
reference the nested heat dynamically using the resource
- 'OS::Heat::ResourceGroup'.
+ ``OS::Heat::ResourceGroup``.
.. req::
:id: R-60011
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
A VNF's Heat Orchestration Template **MUST** have no more than
two levels of nesting.
-As stated in :need:`R-67231` a VNF's Heat Orchestration template's
-Environment File's **MUST NOT** contain the "resource_registry:" section.
+.. req::
+ :id: R-70112
+ :target: VNF
+ :keyword: MUST
+ :validation_mode: static
+ :introduced: casablanca
+
+ A VNF's Heat Orchestration Template **MUST** reference a Nested YAML
+ file by name. The use of ``resource_registry`` in the VNF's Heat
+ Orchestration Templates Environment File **MUST NOT** be used.
Two levels of nesting is defined as follows: A base module, incremental
module, or cinder volume module references a nested heat file either
-statically or by using the resource 'OS::Heat::ResourceGroup'.
-This file is the first level of nesting.
-If first level file then references a nested file, that file is
-the second level of nesting.
-
+statically or by using the resource ``OS::Heat::ResourceGroup``.
+The referenced YAML heat file is the first level of nested heat.
+If first level nested YAML file references a nested heat file, that file is
+the second level of nested heat.
-.. req::
- :id: R-89868
- :target: VNF
- :keyword: MUST
-
- The VNF Heat Orchestration Template **MUST** have unique
- file names within the scope of the VNF for a nested heat yaml file.
+As stated in requirement :need:`R-99646`, a VNF's YAML files
+(i.e, Heat Orchestration Template files and Nested files) **MUST**
+have a unique name in the scope of the VNF.
.. req::
:id: R-52530
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
A VNF's Heat Orchestration Template's Nested YAML file
**MUST** be in the same directory hierarchy as the VNF's Heat
a VNF's Heat Orchestration Templates (when the VNF is composed of two
or more Heat Orchestration Templates).
+Note that as stated in requirement :need:`R-00011`, a VNF's Heat Orchestration
+Template's Nested YAML file's parameter's **MUST NOT** have a parameter
+constraint defined.
+
.. req::
:id: R-11041
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
All parameters defined in a VNFs Nested YAML file
**MUST** be passed in as properties of the resource calling
Note that:
-- As stated in requirement :need:`R-00011`, a VNF's Heat Orchestration
- Template's Nested YAML file's parameter's **MUST NOT** have
- a parameter constraint defined.
-
-- As stated in Requirement :need:`R-44491`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vnf\_id' is passed into a Nested YAML
- file, the parameter name 'vnf\_id' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-86237`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vf\_module\_id' is passed into a Nested YAML
- file, the parameter name 'vf\_module\_id' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-16576`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vnf\_name' is passed into a Nested YAML
- file, the parameter name 'vnf\_name' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-49177`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vf\_module\_name' is passed into a Nested YAML
- file, the parameter name 'vf\_module\_name' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-70757`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vm\_role' is passed into a Nested YAML
- file, the parameter name 'vm\_role' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-22441`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'vf\_module\_index' is passed into a Nested YAML
- file, the parameter name 'vf\_module\_index' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-75202`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'workload\_context' is passed into a Nested YAML
- file, the parameter name 'workload\_context' **MUST NOT** change.
-
-- As stated in Requirement :need:`R-62954`, if a VNF's Heat Orchestration
- Template's OS::Nova::Server Resource metadata map value parameter
- 'environment\_context' is passed into a Nested YAML
- file, the parameter name 'environment\_context' **MUST NOT** change.
-
-- With nested templates, outputs are required to expose any resource
- properties of the child templates to the parent template. Those would
- not explicitly be declared as parameters but simply referenced as
- get\_attribute targets against the "parent" resource.
-
-- A parameter declared in the outputs: section of a nested template can
- be accessed from the parent template as an attribute (i.e., via
- get\_attr) of the "pseudo resource" whose type is in the nested
- template. In the case of a OS::Heat::ResourceGroup, an output will be
- an attribute of the OS::Heat::ResourceGroup itself, and will be an
- array from the perspective of the parent template.
+As stated in Requirement :need:`R-44491`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vnf_id`` is passed into a Nested YAML file, the parameter name
+``vnf_id`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-86237`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_id`` is passed into a Nested YAML file, the parameter name
+``vf_module_id`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-16576`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vnf_name`` is passed into a Nested YAML file, the parameter name
+``vnf_name`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-49177`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_name`` is passed into a Nested YAML file, the parameter name
+``vf_module_name`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-70757`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vm_role`` is passed into a Nested YAML file, the parameter name
+``vm_role`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-22441`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``vf_module_index`` is passed into a Nested YAML file, the parameter
+name ``vf_module_index`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-75202`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``workload_context`` is passed into a Nested YAML file, the parameter
+name ``workload_context`` **MUST NOT** change.
+
+As stated in Requirement :need:`R-62954`, if a VNF's Heat Orchestration
+Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter
+``environment_context`` is passed into a Nested YAML file, the parameter
+name ``environment_context`` **MUST NOT** change.
+
+With nested templates, outputs are required to expose any resource
+properties of the child templates to the parent template. Those would
+not explicitly be declared as parameters but simply referenced as
+``get_attribute`` targets against the "parent" resource.
+
+A parameter declared in the outputs: section of a nested template can
+be accessed from the parent template as an attribute (i.e., via
+``get_attr``) of the "pseudo resource" whose type is in the nested
+template. In the case of a ``OS::Heat::ResourceGroup``, an output will be
+an attribute of the ``OS::Heat::ResourceGroup`` itself, and will be an
+array from the perspective of the parent template.
.. req::
:id: R-17528
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
A VNF's Heat Orchestration Template's first level Nested YAML file
**MUST NOT** contain more than one ``OS::Nova::Server`` resource.
.. code-block:: yaml
- Resources:
- dns_server_0:
- type: nested.yaml
- properties:
- dns_image_name: { get_param: dns_image_name }
- dns_flavor_name: { get_param: dns_flavor_name }
- availability_zone: { get_param: availability_zone_0 }
- security_group: { get_param: DNS_shared_sec_grp_id }
- oam_net_id: { get_param: oam_protected_net_id }
- dns_oam_ip: { get_param: dns_oam_ip_0 }
- dns_name: { get_param: dns_name_0 }
- vnf_name: { get_param: vnf_name }
- vnf_id: { get_param: vnf_id }
- vf_module_id: {get_param: vf_module_id}
-
- dns_server_1:
- type: nested.yaml
- properties:
- dns_image_name: { get_param: dns_image_name }
- dns_flavor_name: { get_param: dns_flavor_name }
- availability_zone: { get_param: availability_zone_1 }
- security_group: { get_param: DNS_shared_sec_grp_id }
- oam_net_id: { get_param: oam_protected_net_id }
- dns_oam_ip: { get_param: dns_oam_ip_1 }
- dns_name: { get_param: dns_name_1 }
- vnf_name: { get_param: vnf_name }
- vnf_id: { get_param: vnf_id }
- vf_module_id: {get_param: vf_module_id}
+ resources:
+ dns_server_0:
+ type: nested.yaml
+ properties:
+ dns_image_name: { get_param: dns_image_name }
+ dns_flavor_name: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_0 }
+ security_group: { get_param: DNS_shared_sec_grp_id }
+ oam_net_id: { get_param: oam_protected_net_id }
+ dns_oam_ip: { get_param: dns_oam_ip_0 }
+ dns_name: { get_param: dns_name_0 }
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: {get_param: vf_module_id}
+
+ dns_server_1:
+ type: nested.yaml
+ properties:
+ dns_image_name: { get_param: dns_image_name }
+ dns_flavor_name: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone_1 }
+ security_group: { get_param: DNS_shared_sec_grp_id }
+ oam_net_id: { get_param: oam_protected_net_id }
+ dns_oam_ip: { get_param: dns_oam_ip_1 }
+ dns_name: { get_param: dns_name_1 }
+ vnf_name: { get_param: vnf_name }
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: {get_param: vf_module_id}
nested.yaml
.. code-block:: yaml
- dns_oam_0_port:
- type: OS::Neutron::Port
- properties:
- name:
- str_replace:
- template: VNF_NAME_dns_oam_port
- params:
- VNF_NAME: {get_param: vnf_name}
- network: { get_param: oam_net_id }
- fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
- security_groups: [{ get_param: security_group }]
-
- dns_servers:
- type: OS::Nova::Server
- properties:
- name: { get_param: dns_names }
- image: { get_param: dns_image_name }
- flavor: { get_param: dns_flavor_name }
- availability_zone: { get_param: availability_zone }
- networks:
- - port: { get_resource: dns_oam_0_port }
- metadata:
- vnf_id: { get_param: vnf_id }
- vf_module_id: { get_param: vf_module_id }
- vnf_name {get_param: vnf_name }
+ dns_oam_0_port:
+ type: OS::Neutron::Port
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_dns_oam_port
+ params:
+ VNF_NAME: {get_param: vnf_name}
+ network: { get_param: oam_net_id }
+ fixed_ips: [{ "ip_address": { get_param: dns_oam_ip }}]
+ security_groups: [{ get_param: security_group }]
+
+ dns_servers:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: dns_names }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: availability_zone }
+ networks:
+ - port: { get_resource: dns_oam_0_port }
+ metadata:
+ vnf_id: { get_param: vnf_id }
+ vf_module_id: { get_param: vf_module_id }
+ vnf_name {get_param: vnf_name }
Use of Heat ResourceGroup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The OS::Heat::ResourceGroup is a useful Heat element for creating
multiple instances of a given resource or collection of resources.
-Typically, it is used with a nested Heat template, to create, for
+Typically, it is used with a nested Heat template to create, for
example, a set of identical OS::Nova::Server resources plus their
related OS::Neutron::Port resources via a single resource in a master
template.
.. code-block:: yaml
- type: OS::Heat::ResourceGroup
- resource_def:
- type: my_nested_vm_template.yaml
- properties:
- name: {get_param: [vm_name_list, "%index%"]}
+ type: OS::Heat::ResourceGroup
+ properties:
+ . . .
+ resource_def:
+ type: my_nested_vm_template.yaml
+ properties:
+ name: {get_param: [vm_name_list, "%index%"]}
Although this appears to use the nth entry of the vm_name_list list for
the nth element of the OS::Heat::ResourceGroup, it will in fact result
.. code-block:: yaml
- type: OS::Heat::ResourceGroup
- resource_def:
- type: my_nested_vm_template.yaml
- properties:
- names: {get_param: vm_name_list}
- index: "%index%"
+ type: OS::Heat::ResourceGroup
+ properties:
+ . . .
+ resource_def:
+ type: my_nested_vm_template.yaml
+ properties:
+ names: {get_param: vm_name_list}
+ index: "%index%"
You can then reference within the nested template as:
-{ get\_param: [names, {get\_param: index} ] }
+{ get_param: [names, {get_param: index} ] }
OS::Heat::ResourceGroup Property count
++++++++++++++++++++++++++++++++++++++++
:id: R-50011
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
- A VNF's Heat Orchestration Template's 'OS::Heat::ResourceGroup'
- property 'count' **MUST** be enumerated in the VNF's
+ A VNF's Heat Orchestration Template's ``OS::Heat::ResourceGroup``
+ property ``count`` **MUST** be enumerated in the VNF's
Heat Orchestration Template's Environment File and **MUST** be
assigned a value.
.. code-block:: yaml
- type: OS::Heat::ResourceGroup
- properties:
- count: { get_param: count }
- index_var: index
- resource_def:
- type: my_nested_vm_template.yaml
- properties:
- names: {get_param: vm_name_list}
- index: index
+ type: OS::Heat::ResourceGroup
+ properties:
+ count: { get_param: count }
+ index_var: index
+ resource_def:
+ type: my_nested_vm_template.yaml
+ properties:
+ names: {get_param: vm_name_list}
+ index: index
Availability Zone and ResourceGroups
++++++++++++++++++++++++++++++++++++++++
-The resource OS::Heat::ResourceGroup and the property availability\_zone
+The resource OS::Heat::ResourceGroup and the property availability_zone
has been an "issue" with a few VNFs since ONAP only supports
-availability\_zone as a string parameter and not a
-comma\_delimited\_list. This makes it difficult to use a
-OS::Heat::ResourceGroup to create Virtual Machines in more
-than one availability zone.
+availability_zone as a string parameter and not as a
+comma_delimited_list. This makes it difficult to use a
+OS::Heat::ResourceGroup to create Virtual Machines in more than one
+availability zone.
There are numerous solutions to this issue. Below are two suggested
usage patterns.
**Option 1:** create a CDL in the OS::Heat::ResourceGroup. In the
-resource type: OS::Heat::ResourceGroup, create a comma\_delimited\_list
-availability\_zones by using the intrinsic function list\_join.
+resource type: OS::Heat::ResourceGroup, create a comma_delimited_list
+availability_zones by using the intrinsic function list_join.
.. code-block:: yaml
- <resource name>:
- type: OS::Heat::ResourceGroup
- properties:
- count: { get_param: node_count }
- index_var: index
- resource_def:
- type: nested.yaml
- properties:
- index: index
- avaialability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
+ <resource name>:
+ type: OS::Heat::ResourceGroup
+ properties:
+ count: { get_param: node_count }
+ index_var: index
+ resource_def:
+ type: nested.yaml
+ properties:
+ index: index
+ availability_zones: { list_join: [',', [ { get_param: availability_zone_0 }, { get_param: availability_zone_1 } ] ] }
In the nested heat
.. code-block:: yaml
- parameters:
- avaialability_zones:
- type: comma_delimited_list
- description:
+ parameters:
+ availability_zones:
+ type: comma_delimited_list
+ description:
- resources:
- servers:
- type: OS::Nova::Server
- properties:
- name: { get_param: [ dns_names, get_param: index ] }
- image: { get_param: dns_image_name }
- flavor: { get_param: dns_flavor_name }
- availability_zone: { get_param: [ avaialability_zones, get_param: index ] }
+ resources:
+ servers:
+ type: OS::Nova::Server
+ properties:
+ name: { get_param: [ dns_names, get_param: index ] }
+ image: { get_param: dns_image_name }
+ flavor: { get_param: dns_flavor_name }
+ availability_zone: { get_param: [ availability_zones, get_param: index ] }
**Option 2:** Create a CDL by passing the availability zone parameter
into a nested heat template. An example is provided below.
Nested Heat Template Example: OS::Heat::ResourceGroup
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-In this example, ocgapp\_volume.yml creates volumes using a
+In this example, ocgapp_volume.yml creates volumes using a
OS::Heat::ResourceGroup that uses nested heat by calling
-ocgapp_nested_volume.yml. ocgapp\_volume.yml has an outputs: parameter
-ocgapp\_volume\_ids which is declared a input parameter of type: json in
-ocgapp\_volume.yml.
+ocgapp_nested_volume.yml. ocgapp_volume.yml has an outputs: parameter
+ocgapp_volume_ids which is declared a input parameter of type: json in
+ocgapp_volume.yml.
This is an example of requirement :need:`R-07443`, where
a VNF's Heat Orchestration Templates' Cinder Volume Module Output
Parameter's name and type **MUST** match the input parameter name and type
in the corresponding Base Module or Incremental Module unless the Output
-Parameter is of the type 'comma\_delimited\_list', then the corresponding
-input parameter **MUST** be declared as type 'json'.
+Parameter is of the type ``comma_delimited_list``, then the corresponding
+input parameter **MUST** be declared as type ``json``.
-ocgapp\_volume.yml
+ocgapp_volume.yml
.. code-block:: yaml
description: the ocgapp volume uuid
value: {get_resource: ocgapp_volume_0}
+Below is a screen shot of parameter ocgapp_volume_ids from the OpenStack
+Horizon GUI showing the output.
+
+.. image:: ../../heat_picture3.png
+ :height: 334px
+ :width: 1186px
+ :scale: 50 %
+
The heat template below is a partial heat template,
ocgapp.yml
External References
^^^^^^^^^^^^^^^^^^^^^^
-Heat templates *should not* reference any HTTP-based resource
+Heat templates *must not* reference any HTTP-based resource
definitions, any HTTP-based nested configurations, or any HTTP-based
environment files.
-- During orchestration, ONAP *should not* retrieve any such resources
+- During orchestration, ONAP *must not* retrieve any such resources
from external/untrusted/unknown sources.
-- VNF images should not contain such references in user-data or other
+- VNF images must not contain external references in user-data or other
configuration/operational scripts that are specified via Heat or
encoded into the VNF image itself.
-*Note:* HTTP-based references are acceptable if the HTTP-based reference
-is accessing information with the VM private/internal network.
+*Note: HTTP-based references are acceptable if the HTTP-based reference
+is accessing information utilizing the VM private/internal network.*
Note that Namespaces in XML (defined at
http://www.w3.org/TR/2009/REC-xml-names-20091208/) are allowed if the
information. The purpose of using an URI is to give the namespace a
unique name.
-Heat Files Support (get\_file)
+Heat Files Support (get_file)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heat Templates may contain the inclusion of text files into Heat
-templates via the Heat get\_file directive. This may be used, for
+templates via the Heat get_file directive. This may be used, for
example, to define a common "user-data" script, or to inject files into
a VM on startup via the "personality" property.
:id: R-76718
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
If a VNF's Heat Orchestration Template uses the intrinsic function
- 'get\_file', the 'get\_file' target **MUST** be referenced in
+ ``get_file``, the ``get_file`` target **MUST** be referenced in
the Heat Orchestration Template by file name.
-The 'get\_file' target files are on-boarded to SDC in the same package
+The ``get_file`` target files are on-boarded to SDC in the same package
that contains the VNF's complete Heat Orchestration Template.
:id: R-41888
:target: VNF
:keyword: MUST NOT
+ :validation_mode: static
+ :updated: casablanca
A VNF's Heat Orchestration Template intrinsic function
- 'get\_file' **MUST NOT** utilize URL-based file retrieval.
+ ``get_file`` **MUST NOT** utilize URL-based file retrieval.
.. req::
:id: R-62177
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
When using the intrinsic function get_file, the included files
**MUST** have unique file names within the scope of the VNF.
:id: R-87848
:target: VNF
:keyword: MUST
+ :validation_mode: static
+ :updated: casablanca
- A VNF's Heat Orchestration Template's 'get\_file' target files
- **MUST** be in the same directory hierarchy as the VNF's Heat
- Orchestration Templates.
+ When using the intrinsic function get_file, ONAP does not support
+ a directory hierarchy for included files. All files must be in a
+ single, flat directory per VNF. A VNF's Heat Orchestration
+ Template's ``get_file`` target files **MUST** be in the same
+ directory hierarchy as the VNF's Heat Orchestration Templates.
ONAP does not support a hierarchical structure. A VNF's YAML files
must be in a single, flat directory.
-
.. req::
:id: R-05050
:target: VNF
:keyword: MAY
+ :updated: casablanca
A VNF's Heat Orchestration Templates intrinsic function
- 'get\_file' <content key> **MAY** be used:
+ ``get_file`` <content key> **MAY** be used:
* more than once in a VNF's Heat Orchestration Template
* in two or more of a VNF's Heat Orchestration Templates
generic manner which does not require the pre-requisite creation of a
keypair. The Heat should be structured in such a way as to:
-- Pass a public key as a parameter value instead of a keypair name
+ - Pass a public key as a parameter value instead of a keypair name
-- Create a new keypair within The VNF Heat Orchestration Template (in the
- base module) based on an existing public key for use within that VNF
+ - Create a new keypair within the VNF Heat templates (in the base module)
+ based on an existing public key for use within that VNF
By following this approach, the end result is the same as pre-creating
the keypair using the public key – i.e., that public key will be
.. code-block:: yaml
- parameters:
+ parameters:
vnf_name:
- type: string
+ type: string
lb_ssh_public_key:
- type: string
+ type: string
- resources:
- my_keypair:
- type: OS::Nova::Keypair
- properties:
- name:
- str_replace:
- template: VNF_NAME_key_pair
- params:
- VNF_NAME: { get_param: vnf_name }
- public_key: {get_param: lb_ssh_public_key}
- save_private_key: false
+ resources:
+ lb_keypair_0:
+ type: OS::Nova::Keypair
+ properties:
+ name:
+ str_replace:
+ template: VNF_NAME_key_pair
+ params:
+ VNF_NAME: { get_param: vnf_name }
+ public_key: {get_param: lb_ssh_public_key}
+ save_private_key: false
Security Groups
^^^^^^^^^^^^^^^^^
.. code-block:: yaml
- resources:
- db_server_group:
- type: OS::Nova::ServerGroup
- properties:
- name:
+ resources:
+ db_server_group:
+ type: OS::Nova::ServerGroup
+ properties:
+ name:
str_replace:
- params:
- $vnf_name: {get_param: vnf_name}
- template: $vnf_name-server_group1
- policies:
- - anti-affinity
-
- lb_server_group:
- type: OS::Nova::ServerGroup
- properties:
- name:
+ params:
+ $vnf_name: {get_param: vnf_name}
+ template: $vnf_name-server_group1
+ policies:
+ - anti-affinity
+ lb_server_group:
+ type: OS::Nova::ServerGroup
+ properties:
+ name:
str_replace:
- params:
- $vnf_name: {get_param: vnf_name}
- template: $vnf_name-server_group2
- policies:
- - affinity
-
- db_0:
- type: OS::Nova::Server
- properties:
- ...
- scheduler_hints:
- group: {get_resource: db_server_group}
-
- db_1:
- type: OS::Nova::Server
- properties:
- ...
- scheduler_hints:
- group: {get_resource: db_server_group}
-
- lb_0:
- type: OS::Nova::Server
- properties:
- ...
- scheduler_hints:
- group: {get_resource: lb_server_group}Â
+ params:
+ $vnf_name: {get_param: vnf_name}
+ template: $vnf_name-server_group2
+ policies:
+ - affinity
+ db_server_0:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: db_server_group}
+ db_server_1:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: db_server_group}
+ lb_server_0:
+ type: OS::Nova::Server
+ properties:
+ ...
+ scheduler_hints:
+ group: {get_resource: lb_server_group}
Resource Data Synchronization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For cases where synchronization is required in the orchestration of Heat
resources, two approaches are recommended:
-- Standard Heat depends\_on property for resources
+- Standard Heat depends_on property for resources
- Assures that one resource completes before the dependent resource
is orchestrated.
- Create OS::Heat::WaitCondition and OS::Heat::WaitConditionHandle
resources.
- - Pre-requisite resources issue *wc\_notify* commands in user\_data.
+ - Pre-requisite resources issue *wc_notify* commands in user_data.
- - Dependent resource define depends\_on in the
+ - Dependent resource define depends_on in the
OS::Heat::WaitCondition resource.
-*Example: "depends\_on" case*
+*Example: "depends_on" case*
In this example, the {network-role} has been defined as oam to represent
an oam network and the {vm-type} has been defined as oam to represent an
.. code-block:: yaml
- resources:
- oam_server_01:
- type: OS::Nova::Server
- properties:
- name: {get_param: [oam_ names, 0]}
- image: {get_param: oam_image_name}
- flavor: {get_param: oam_flavor_name}
- availability_zone: {get_param: availability_zone_0}
- networks:
- - port: {get_resource: oam01_port_0}
- - port: {get_resource: oam01_port_1}
- user_data:
- scheduler_hints: {group: {get_resource: oam_servergroup}}
- user_data_format: RAW
-
- oam_01_port_0:
- type: OS::Neutron::Port
- properties:
- network: {get_resource: oam_net_name}
- fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
- security_groups: [{get_resource: oam_security_group}]
-
- oam_01_port_1:
- type: OS::Neutron::Port
- properties:
- network: {get_param: oam_net_name}
- fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
- security_groups: [{get_resource: oam_security_group}]
-
- oam_01_vol_attachment:
- type: OS::Cinder::VolumeAttachment
- depends_on: oam_server_01
- properties:
- volume_id: {get_param: oam_vol_1}
- mountpoint: /dev/vdb
- instance_uuid: {get_resource: oam_server_01}
+ resources:
+ oam_server_01:
+ type: OS::Nova::Server
+ properties:
+ name: {get_param: [oam_names, 0]}
+ image: {get_param: oam_image_name}
+ flavor: {get_param: oam_flavor_name}
+ availability_zone: {get_param: availability_zone_0}
+ networks:
+ - port: {get_resource: oam01_port_0}
+ - port: {get_resource: oam01_port_1}
+ user_data:
+ scheduler_hints: {group: {get_resource: oam_servergroup}}
+ user_data_format: RAW
+ oam_01_port_0:
+ type: OS::Neutron::Port
+ properties:
+ network: {get_resource: oam_net_name}
+ fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 1]}}]
+ security_groups: [{get_resource: oam_security_group}]
+ oam_01_port_1:
+ type: OS::Neutron::Port
+ properties:
+ network: {get_param: oam_net_name}
+ fixed_ips: [{"ip_address": {get_param: [oam_oam_net_ips, 2]}}]
+ security_groups: [{get_resource: oam_security_group}]
+ oam_volume_attachment_0:
+ type: OS::Cinder::VolumeAttachment
+ depends_on: oam_server_01
+ properties:
+ volume_id: {get_param: oam_vol_1}
+ mountpoint: /dev/vdb
+ instance_uuid: {get_resource: oam_server_01}
{
- "created": "2018-09-12T17:22:55.929421",
+ "created": "2018-09-12T23:20:21.160620",
"current_version": "casablanca",
"project": "",
"versions": {
"needs_amount": 750
},
"casablanca": {
- "created": "2018-09-12T17:22:55.929309",
+ "created": "2018-09-12T23:20:21.160546",
"needs": {
"R-00011": {
"description": "A VNF's Heat Orchestration Template's parameter defined\nin a nested YAML file\n**MUST NOT** have a parameter constraint defined.",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"validation_mode": ""
},
"R-01101": {
- "description": "A VNF's Heat Orchestration Template **MAY**\nreference the nested heat dynamically using the resource\n'OS::Heat::ResourceGroup'.",
+ "description": "A VNF's Heat Orchestration Template **MAY**\nreference the nested heat dynamically using the resource\n``OS::Heat::ResourceGroup``.",
"full_title": "",
"hide_links": "",
"id": "R-01101",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
"validation_mode": ""
},
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"validation_mode": ""
},
"R-05050": {
- "description": "A VNF's Heat Orchestration Templates intrinsic function\n'get\\_file' <content key> **MAY** be used:\n\n * more than once in a VNF's Heat Orchestration Template\n * in two or more of a VNF's Heat Orchestration Templates\n * in a VNF's Heat Orchestration Templates nested YAML file",
+ "description": "A VNF's Heat Orchestration Templates intrinsic function\n``get_file`` <content key> **MAY** be used:\n\n * more than once in a VNF's Heat Orchestration Template\n * in two or more of a VNF's Heat Orchestration Templates\n * in a VNF's Heat Orchestration Templates nested YAML file",
"full_title": "",
"hide_links": "",
"id": "R-05050",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
"validation_mode": ""
},
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-11168": {
"description": "A VNF's Heat Orchestration Template's Resource ID that is\nassociated with an external network **MUST** include the\n'{network-role}' as part of the resource ID.",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-18001": {
"description": "If the VNF's ports connected to a unique internal network\nand the port's IP addresses are statically assigned IP Addresses,\nthe IPv4 Addresses **MAY** be from different subnets and the\nIPv6 Addresses **MAY** be from different subnets.",
"validated_by": "",
"validation_mode": "static"
},
- "R-22656": {
- "description": "The VNF Heat Orchestration Template **MUST** have a\ncorresponding environment file for a Cinder Volume Module.",
- "full_title": "",
- "hide_links": "",
- "id": "R-22656",
- "impacts": "",
- "introduced": "",
- "keyword": "MUST",
- "links": [],
- "notes": "",
- "section_name": "ONAP Heat Support of Environment Files",
- "sections": [
- "ONAP Heat Support of Environment Files"
- ],
- "status": null,
- "tags": [],
- "target": "VNF",
- "test": "",
- "test_case": "",
- "test_file": "",
- "title": "",
- "title_from_content": "",
- "type_name": "Requirement",
- "updated": "",
- "validated_by": "",
- "validation_mode": ""
- },
"R-22680": {
"description": "The xNF Package **MUST** include documentation that describes\nany requirements for the monitoring component of tools for Network\nCloud automation and management to provide these records to components\nof the xNF.",
"full_title": "",
"validation_mode": ""
},
"R-25190": {
- "description": "A VNF's Heat Orchestration Template's Resource 'OS::Cinder::Volume'\n**SHOULD NOT** declare the property 'availability_zone'.",
+ "description": "A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``\n**SHOULD NOT** declare the property ``availability_zone``.",
"full_title": "",
"hide_links": "",
"id": "R-25190",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
"validation_mode": ""
},
"validated_by": "",
"validation_mode": ""
},
- "R-35727": {
- "description": "The VNF Heat Orchestration Template **MUST** have a\ncorresponding environment file for an Incremental module.",
- "full_title": "",
- "hide_links": "",
- "id": "R-35727",
- "impacts": "",
- "introduced": "",
- "keyword": "MUST",
- "links": [],
- "notes": "",
- "section_name": "ONAP Heat Support of Environment Files",
- "sections": [
- "ONAP Heat Support of Environment Files"
- ],
- "status": null,
- "tags": [],
- "target": "VNF",
- "test": "",
- "test_case": "",
- "test_file": "",
- "title": "",
- "title_from_content": "",
- "type_name": "Requirement",
- "updated": "",
- "validated_by": "",
- "validation_mode": ""
- },
"R-35735": {
"description": "When the VNF's Heat Orchestration Template's Resource\n'OS::Neutron::Port' is attaching to an external network,\nand an IPv6 Virtual IP (VIP) address is assigned via ONAP automation\nusing the property 'allowed_address_pairs' map property 'ip_address',\nthe parameter name **MUST** follow the naming convention\n\n * '{vm-type}_{network-role}_v6_floating_ip'\n\nwhere\n\n * '{vm-type}' is the {vm-type} associated with the OS::Nova::Server\n * '{network-role}' is the {network-role} of the external network\n\nAnd the parameter **MUST** be declared as type 'string'.",
"full_title": "",
"validation_mode": ""
},
"R-41888": {
- "description": "A VNF's Heat Orchestration Template intrinsic function\n'get\\_file' **MUST NOT** utilize URL-based file retrieval.",
+ "description": "A VNF's Heat Orchestration Template intrinsic function\n``get_file`` **MUST NOT** utilize URL-based file retrieval.",
"full_title": "",
"hide_links": "",
"id": "R-41888",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-41956": {
"description": "If a VNF requires ONAP to assign a Virtual IP (VIP) Address to\nports connected an external network, the port\n**MUST NOT** have more than one IPv6 VIP address.",
"validation_mode": ""
},
"R-50011": {
- "description": "A VNF's Heat Orchestration Template's 'OS::Heat::ResourceGroup'\nproperty 'count' **MUST** be enumerated in the VNF's\nHeat Orchestration Template's Environment File and **MUST** be\nassigned a value.",
+ "description": "A VNF's Heat Orchestration Template's ``OS::Heat::ResourceGroup``\nproperty ``count`` **MUST** be enumerated in the VNF's\nHeat Orchestration Template's Environment File and **MUST** be\nassigned a value.",
"full_title": "",
"hide_links": "",
"id": "R-50011",
"sections": [
"OS::Heat::ResourceGroup Property count",
"Use of Heat ResourceGroup",
- "Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-50252": {
"description": "The xNF **MUST** write to a specific one text files that\nwill be retrieved and made available by the Ansible Server if, as part\nof a xNF action (e.g., audit), a playbook is required to return any\nxNF information. The text files must be written in the same directory as\nthe one from which the playbook is being executed. A text file must be\ncreated for the xNF playbook run targets/affects, with the name\n'<VNFname>_results.txt' into which any desired output from each\nrespective VM/xNF must be written.",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-52753": {
"description": "VNF's Heat Orchestration Template's Base Module's output parameter's\nname and type **MUST** match the VNF's Heat Orchestration Template's\nincremental Module's name and type unless the output parameter is of\ntype ``comma_delimited_list``, then the corresponding input parameter\n**MUST** be declared as type ``json``.",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-60106": {
"description": "The xNF **MUST** implement the protocol operation:\n**get(filter)** - Retrieve (a filtered subset of) the running\nconfiguration and device state information. This should include\nthe list of xNF supported schemas.",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-61354": {
"description": "The VNF **MUST** provide a mechanism (e.g., access control list) to\npermit and/or restrict access to services on the VNF by source,\ndestination, protocol, and/or port.",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-62187": {
"description": "A VNF's Heat Orchestration Template's Resource\n'OS::ContrailV2::InstanceIp' that is configuring an\nIPv4 Address on a port attached to an internal network\nResource ID **MUST** use the naming convention\n\n * {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}\n\nwhere\n\n * {vm-type} is the vm-type\n * {vm-type_index} is the instance of the {vm-type}\n * {network-role} is the network-role of the network\n that the port is attached to\n * {vmi_index} is the instance of the the virtual machine interface\n (e.g., port) on the vm-type\n attached to the network of {network-role}\n * 'IP' signifies that an IPv4 address is being configured\n * {index} is the index of the IPv4 address",
"validated_by": "",
"validation_mode": ""
},
- "R-67205": {
- "description": "The VNF Heat Orchestration Template **MUST** have a corresponding\nenvironment file for a Base Module.",
- "full_title": "",
- "hide_links": "",
- "id": "R-67205",
- "impacts": "",
- "introduced": "",
- "keyword": "MUST",
- "links": [],
- "notes": "",
- "section_name": "ONAP Heat Support of Environment Files",
- "sections": [
- "ONAP Heat Support of Environment Files"
- ],
- "status": null,
- "tags": [],
- "target": "VNF",
- "test": "",
- "test_case": "",
- "test_file": "",
- "title": "",
- "title_from_content": "",
- "type_name": "Requirement",
- "updated": "",
- "validated_by": "",
- "validation_mode": ""
- },
"R-67231": {
"description": "A VNF's Heat Orchestration template's Environment File's\n**MUST NOT** contain the ``resource_registry:`` section.",
"full_title": "",
"validated_by": "",
"validation_mode": ""
},
+ "R-70112": {
+ "description": "A VNF's Heat Orchestration Template **MUST** reference a Nested YAML\nfile by name. The use of ``resource_registry`` in the VNF's Heat\nOrchestration Templates Environment File **MUST NOT** be used.",
+ "full_title": "",
+ "hide_links": "",
+ "id": "R-70112",
+ "impacts": "",
+ "introduced": "casablanca",
+ "keyword": "MUST",
+ "links": [],
+ "notes": "",
+ "section_name": "Nested Heat Template Requirements",
+ "sections": [
+ "Nested Heat Template Requirements",
+ "Nested Heat Templates",
+ "ONAP Heat Heat Template Constructs"
+ ],
+ "status": null,
+ "tags": [],
+ "target": "VNF",
+ "test": "",
+ "test_case": "",
+ "test_file": "",
+ "title": "",
+ "title_from_content": "",
+ "type_name": "Requirement",
+ "updated": "",
+ "validated_by": "",
+ "validation_mode": "static"
+ },
"R-70266": {
"description": "The xNF **MUST** respond to an ONAP request to deliver the\ncurrent data for any of the record types defined in\n`Event Records - Data Structure Description`_ by returning the requested\nrecord, populated with the current field values. (Currently the defined\nrecord types include fault fields, mobile flow fields, measurements for\nxNF scaling fields, and syslog fields. Other record types will be added\nin the future as they become standardized and are made available.)",
"full_title": "",
"validation_mode": ""
},
"R-76718": {
- "description": "If a VNF's Heat Orchestration Template uses the intrinsic function\n'get\\_file', the 'get\\_file' target **MUST** be referenced in\nthe Heat Orchestration Template by file name.",
+ "description": "If a VNF's Heat Orchestration Template uses the intrinsic function\n``get_file``, the ``get_file`` target **MUST** be referenced in\nthe Heat Orchestration Template by file name.",
"full_title": "",
"hide_links": "",
"id": "R-76718",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-76901": {
"description": "The VNF **MUST** support a container rebuild mechanism based on existing\nimage (e.g. Glance image in Openstack environment) or a snapshot.",
"validation_mode": ""
},
"R-87848": {
- "description": "A VNF's Heat Orchestration Template's 'get\\_file' target files\n**MUST** be in the same directory hierarchy as the VNF's Heat\nOrchestration Templates.",
+ "description": "When using the intrinsic function get_file, ONAP does not support\na directory hierarchy for included files. All files must be in a\nsingle, flat directory per VNF. A VNF's Heat Orchestration\nTemplate's ``get_file`` target files **MUST** be in the same\ndirectory hierarchy as the VNF's Heat Orchestration Templates.",
"full_title": "",
"hide_links": "",
"id": "R-87848",
"title": "",
"title_from_content": "",
"type_name": "Requirement",
- "updated": "",
+ "updated": "casablanca",
"validated_by": "",
- "validation_mode": ""
+ "validation_mode": "static"
},
"R-88026": {
"description": "The xNF **MUST** include a NETCONF server enabling\nruntime configuration and lifecycle management capabilities.",
"validated_by": "",
"validation_mode": ""
},
- "R-89868": {
- "description": "The VNF Heat Orchestration Template **MUST** have unique\nfile names within the scope of the VNF for a nested heat yaml file.",
- "full_title": "",
- "hide_links": "",
- "id": "R-89868",
- "impacts": "",
- "introduced": "",
- "keyword": "MUST",
- "links": [],
- "notes": "",
- "section_name": "Nested Heat Template Requirements",
- "sections": [
- "Nested Heat Template Requirements",
- "ONAP Heat Heat Template Constructs"
- ],
- "status": null,
- "tags": [],
- "target": "VNF",
- "test": "",
- "test_case": "",
- "test_file": "",
- "title": "",
- "title_from_content": "",
- "type_name": "Requirement",
- "updated": "",
- "validated_by": "",
- "validation_mode": ""
- },
"R-89913": {
"description": "A VNF's Heat Orchestration Template's Cinder Volume Module Output\nParameter(s)\n**MUST** include the\nUUID(s) of the Cinder Volumes created in template,\nwhile others **MAY** be included.",
"full_title": "",
"section_name": "Nested Heat Template Requirements",
"sections": [
"Nested Heat Template Requirements",
+ "Nested Heat Templates",
"ONAP Heat Heat Template Constructs"
],
"status": null,
"validation_mode": ""
}
},
- "needs_amount": 715
+ "needs_amount": 712
}
}
}
\ No newline at end of file