VNFRQTS - update HEAT Batch 2

Including changes for sections 5.6 - 5.9

Issue-ID: VNFRQTS-438

Change-Id: I9bfcaf52cd41a523ff6f6b4dd1cd32bc731d47d2
Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>

4 files changed, 409 insertions, 392 deletions

diff --git a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
index 90fb33b..8c10e4b 100644
--- a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst
@@ -45,8 +45,8 @@ while others **MAY** be included.
 As stated in :need:`R-07443`, 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'.
+the Output Parameter is of the type ``comma_delimited_list``,
+then the corresponding input parameter **MUST** be declared as type ``json``.
 
 A single volume module must create only the volumes
 required by a single Incremental module or Base module.
@@ -79,94 +79,90 @@ Optional Property availability_zone
     :id: R-25190
     :target: VNF
     :keyword: SHOULD NOT
+    :updated: casablanca
 
-    A VNF's Heat Orchestration Template's Resource 'OS::Cinder::Volume'
-    **SHOULD NOT** declare the property 'availability_zone'.
+    A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
+    **SHOULD NOT** declare the property ``availability_zone``.
 
 If the property is used, the value **MUST**
-be enumerated in the environment file and must be set to nova', which
+be enumerated in the environment file and must be set to ``nova``, which
 is the default. There are no requirements on the parameter naming
 convention with the exception that the naming convention **MUST NOT** be the
-same as the 'OS::Nova::Server' property 'availability_zone' (i.e.,
-'availability_zone_{index}').
+same as the ``OS::Nova::Server`` property ``availability_zone`` (i.e.,
+``availability_zone_{index}``).
 
 Optional Property volume_type
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-OpenStack supports multiple volume types. If the OS::Cinder::Volume optional
-property volume_type is not specified, the OpenStack default volume type is
-used. If a specific volume type is required, the property is used and
-the value **MUST** be enumerated in the environment file. There are no
-requirements on the parameter naming convention
+OpenStack supports multiple volume types. If the ``OS::Cinder::Volume``
+optional property ``volume_type`` is not specified, the OpenStack default
+``volume type`` is used. If a specific volume type is required, the property
+is used and the value **MUST** be enumerated in the environment file. There
+are no requirements on the parameter naming convention.
 
 Cinder Volume Examples
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 *Examples: Volume Template*
 
-A VNF has a Cinder volume module, named incremental\_volume.yaml, that
-creates an independent Cinder volume for a VM in the module
-incremental.yaml. The incremental\_volume.yaml defines a parameter in
-the output section, lb\_volume\_id\_0 which is the UUID of the cinder
-volume. lb\_volume\_id\_0 is defined as a parameter in incremental.yaml.
-ONAP captures the UUID value of lb\_volume\_id\_0 from the volume module
+A VNF has a Cinder volume module, named incremental_volume.yaml,
+that creates an independent Cinder volume for a VM in the module
+incremental.yaml. The incremental_volume.yaml defines a parameter in
+the output section, dns_volume_id_0 which is the UUID of the cinder volume.
+dns_volume_id_0 is defined as a parameter in incremental.yaml.
+ONAP captures the UUID value of dns_volume_id_0 from the volume module
 output statement and provides the value to the incremental module.
 
 Note that the example below is not a complete Heat Orchestration
-Template. The {vm-type} has been defined as "lb" for load balancer
+Template. The {vm-type} has been defined as "dns".
 
-incremental\_volume.yaml
+incremental_volume.yaml
 
 .. code-block:: yaml
 
- parameters:
+  parameters:
     vnf_name:
-       type: string
-    lb_volume_size_0:
-       type: number
-    ...
+      type: string
+    dns_volume_size_0:
+      type: number
+  ...
 
- resources:
+  resources:
     dns_volume_0:
-       type: OS::Cinder::Volume
-       properties:
-          name:
-             str_replace:
-                template: VNF_NAME_volume_0
-                params:
-                   VNF_NAME: { get_param: vnf_name }
-          size: {get_param: dns_volume_size_0}
-    ...
-
- outputs:
-    lb_volume_id_0:
-       value: {get_resource: dns_volume_0}
-    ...
-
+      type: OS::Cinder::Volume
+      properties:
+        name:
+          str_replace:
+            template: VNF_NAME_volume_0
+            params:
+              VNF_NAME: { get_param: vnf_name }
+        size: {get_param: dns_volume_size_0}
+  ...
+  outputs:
+    dns_volume_id_0:
+      value: {get_resource: dns_volume_0}
+  ...
 
 incremental.yaml
 
 .. code-block:: yaml
 
- parameters:
-    lb_name_0:
-       type: string
-    lb_volume_id_0:
-       type: string
-    ...
-
- resources:
-    lb_0:
-       type: OS::Nova::Server
-       properties:
-          name: {get_param: dns_name_0}
-          networks:
-          ...
-
-    lb_0_volume_attach:
-       type: OS::Cinder::VolumeAttachment
-       properties:
-          instance_uuid: { get_resource: lb_0 }
-          volume_id: { get_param: lb_volume_id_0 }
-
-
+  parameters:
+    dns_server_0:
+      type: string
+    dns_volume_id_0:
+      type: string
+  ...
+
+  resources:
+    dns_server_0:
+      type: OS::Nova::Server
+      properties:
+        name: {get_param: dns_name_0}
+        networks:
+  ...
+    dns_volume_attach_0:
+      type: OS::Cinder::VolumeAttachment
+      properties:
+        instance_uuid: { get_resource: dns_server_0 }
+        volume_id: { get_param: dns_volume_id_0 }
diff --git a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
index ba8cd68..aed56e5 100644
--- a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst
@@ -12,32 +12,14 @@ mandatory. A Heat Orchestration Template uploaded to ONAP must have a
 corresponding environment file, even if no parameters are required to
 be enumerated.
 
-(Note that ONAP does not programmatically enforce the use of
-an environment file.)
+*(Note that ONAP does not programmatically enforce the use of
+an environment file.)*
 
-.. req::
-    :id: R-67205
-    :target: VNF
-    :keyword: MUST
+As stated in :need:`R-38474`, :need:`R-81725`, and :need:`R-53433`:
 
-    The VNF Heat Orchestration Template **MUST** have a corresponding
-    environment file for a Base Module.
-
-.. req::
-    :id: R-35727
-    :target: VNF
-    :keyword: MUST
-
-    The VNF Heat Orchestration Template **MUST** have a
-    corresponding environment file for an Incremental module.
-
-.. req::
-    :id: R-22656
-    :target: VNF
-    :keyword: MUST
-
-    The VNF Heat Orchestration Template **MUST** have a
-    corresponding environment file for a Cinder Volume Module.
+  * A VNF's Base Module **MUST** have a corresponding Environment File.
+  * A VNF's Incremental Module **MUST** have a corresponding Environment File.
+  * A VNF's Cinder Volume Module **MUST** have a corresponding environment File.
 
 A nested heat template must not have an environment file; OpenStack does
 not support it.
diff --git a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
index f24d2f4..76ec0c1 100644
--- a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
+++ b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst
@@ -21,11 +21,13 @@ either statically by repeated definition or dynamically by using the
 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
@@ -39,42 +41,50 @@ Incremental Module, and Cinder Volume Module may use nested heat.
     :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
@@ -97,10 +107,16 @@ the second level of nesting.
     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
@@ -108,66 +124,64 @@ the second level of nesting.
 
 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.
@@ -181,71 +195,71 @@ incremental.yaml
 
 .. 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.
@@ -267,11 +281,13 @@ OS::Heat::ResourceGroup:
 
 .. 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
@@ -285,16 +301,18 @@ ResourceGroup:
 
 .. 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
 ++++++++++++++++++++++++++++++++++++++++
@@ -304,9 +322,11 @@ 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.
 
@@ -314,63 +334,63 @@ This is required for ONAP to build the TOSCA model for the VNF.
 
 .. 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.
@@ -426,21 +446,21 @@ az_list_generate.yaml
 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
 
@@ -532,6 +552,14 @@ ocgapp_nested_volume.yml
    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
@@ -571,19 +599,19 @@ 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
@@ -597,11 +625,11 @@ Name (URN). The namespace URI is not used by XML the parser to look up
 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.
 
@@ -612,12 +640,14 @@ Support for Heat Files is subject to the following limitations:
     :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.
 
 
@@ -625,14 +655,18 @@ 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.
@@ -641,22 +675,26 @@ that contains the VNF's complete Heat Orchestration Template.
     :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
@@ -687,10 +725,10 @@ Due to this behavior, the recommended usage of keypairs is in a more
 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
@@ -709,23 +747,23 @@ of lb (for load balancer)):*
 
 .. 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
 ^^^^^^^^^^^^^^^^^
@@ -759,49 +797,45 @@ balancer and db for database.
 
 .. 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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -809,7 +843,7 @@ 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.
@@ -823,12 +857,12 @@ resources, two approaches are recommended:
    -  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
@@ -836,41 +870,38 @@ oam server.
 
 .. 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}
 
 
diff --git a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
index 70ba197..7e1ebe3 100644
--- a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
+++ b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst
@@ -15,12 +15,12 @@ referred to as *VNF Modules*. During orchestration, these modules
 are deployed incrementally to create the complete VNF.
 
 As stated in :need:`R-33132`, a VNF's Heat Orchestration Template **MAY** be
-     1.) Base Module Heat Orchestration Template (also referred to as a
-      Base Module),
-     2.) Incremental Module Heat Orchestration Template (referred to as
-      an Incremental Module), or
-     3.) a Cinder Volume Module Heat Orchestration Template (referred to as
-      Cinder Volume  Module).
+     1. Base Module Heat Orchestration Template (also referred to as a
+        Base Module),
+     2. Incremental Module Heat Orchestration Template (referred to as
+        an Incremental Module), or
+     3. a Cinder Volume Module Heat Orchestration Template (referred to as
+        Cinder Volume  Module).
 
 As stated in :need:`R-20974`, at orchestration time, the VNF's Base Module **MUST**
 be deployed first, prior to any incremental modules.
@@ -39,6 +39,9 @@ As stated in :need:`R-37028` and :need:`R-13196`, a VNF **MUST** be composed
 of one Base Module and *MAY** be composed of zero to many Incremental
 Modules.
 
+As stated in :need:`R-20974`, at orchestration time, the VNF's Base Module
+**MUST** be deployed first, prior to any incremental modules.
+
 ONAP also supports the concept of an optional, independently deployed
 Cinder volume via a separate Heat Orchestration Templates, referred to
 as a Cinder Volume Module. This allows the volume to persist after a VM
@@ -58,6 +61,8 @@ Incremental Module.
     :id: R-61001
     :target: VNF
     :keyword: MUST
+    :validation_mode: static
+    :updated: casablanca
 
     A shared Heat Orchestration Template resource must be defined
     in the base module. A shared resource is a resource that that will
@@ -71,6 +76,9 @@ When the shared resource needs to be referenced by a resource in an
 incremental module, the UUID of the shared resource must be exposed by
 declaring an ONAP Base Module Output Parameter.
 
+Note that a Cinder volume is not a shared resource. A volume template
+must correspond 1:1 with a base module or incremental module.
+
 An example of a shared resource is the resource
 OS::Neutron::SecurityGroup. Security groups are sets of IP filter rules
 that are applied to a VNF’s networking. The resource OS::Neutron::Port