summaryrefslogtreecommitdiffstats
path: root/docs/Chapter5.rst
diff options
context:
space:
mode:
authorBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-03-22 20:31:19 +0000
committerBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-03-22 20:34:20 +0000
commit0aee46b7642b8cd4729822b7db52f40d259c5b3c (patch)
treeece0ec88085477bb3e8b735070f558278325d524 /docs/Chapter5.rst
parent50a0da904060eb51cb750e4c00bdbd9680008d3e (diff)
VNFRQTS - Header fix for table of contents
Highest level of the headers was only shown, fix applied to show another level of depth. Change-Id: I5006e1eb42b40da72df11e754cd635857f7213da Issue-ID: VNFRQTS-193 Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
Diffstat (limited to 'docs/Chapter5.rst')
-rw-r--r--docs/Chapter5.rst184
1 files changed, 92 insertions, 92 deletions
diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst
index 030925f..a71a313 100644
--- a/docs/Chapter5.rst
+++ b/docs/Chapter5.rst
@@ -11,7 +11,7 @@ TOSCA YAML
Introduction
-^^^^^^^^^^^
+^^^^^^^^^^^^^^
This reference document is the VNF TOSCA Template Requirements for
ONAP, which provides recommendations and standards for building VNF
@@ -27,7 +27,7 @@ Network Cloud. It has the following features:
Threading, SRIOV, etc.
Intended Audience
-^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
This document is intended for persons developing VNF TOSCA templates
that will be orchestrated by ONAP.
@@ -187,7 +187,7 @@ specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
+--------------------------------------------------------------------+
EPA Requirements
-^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
1. SR-IOV Passthrought
@@ -408,10 +408,10 @@ supports dpdk. Here is an example.
+------------------------------------------------------+
NFV TOSCA Type Definition
-^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
tosca.capabilites.nfv.VirtualCompute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------+-----------------------------------------+
| **Shorthand Name** | VirtualCompute |
@@ -424,7 +424,7 @@ tosca.capabilites.nfv.VirtualCompute
+---------------------------+-----------------------------------------+
Properties
-+++++++++
+++++++++++++
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
@@ -440,7 +440,7 @@ Properties
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
Definition
-+++++++++
+++++++++++++
+-----------------------------------------------------------+
| tosca.capabilities.nfv.VirtualCompute: |
@@ -473,7 +473,7 @@ Definition
+-----------------------------------------------------------+
tosca.nodes.nfv.VDU.Compute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NFV Virtualization Deployment Unit (VDU) compute node type
represents a VDU entity which it describes the deployment and
@@ -493,13 +493,13 @@ NFV IFA011].**
Attributes
-+++++++++
++++++++++++
None
Capabilities
-+++++++++++
+++++++++++++++
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
| Name | Type | Constraints | Description |
@@ -516,7 +516,7 @@ Capabilities
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
Definition
-+++++++++++
++++++++++++++
+-----------------------------------------------------------------------------------------------------+
| tosca.nodes.nfv.VDU.Compute: |
@@ -671,7 +671,7 @@ Artifact
tosca.nodes.nfv.Cpd
-~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
The TOSCA Cpd node represents network connectivity to a compute resource
or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
@@ -687,7 +687,7 @@ used as parent for the various Cpd types.
Attributes
-+++++++++++
++++++++++++++
+--------+------------+--------+---------------+---------------+
| Name | Required | Type | Constraints | Description |
@@ -695,17 +695,17 @@ Attributes
+--------+------------+--------+---------------+---------------+
Requirements
-+++++++++++
++++++++++++++
None
Capabilities
-+++++++++++
++++++++++++++
None
Definition
-+++++++++++
+++++++++++++
+----------------------------------------------------------------------+
| tosca.nodes.nfv.Cpd: |
@@ -757,7 +757,7 @@ Additional Requirement
None.
tosca.nodes.nfv.VduCpd
-~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~
The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
network connectivity between a VNFC instance (based on this VDU) and an
@@ -772,7 +772,7 @@ internal VL as defined by [ETSI GS NFV-IFA 011].
+-----------------------+--------------------------+
Properties
-++++++++++++
+++++++++++++++
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
@@ -790,7 +790,7 @@ Attributes
None
Requirements
-++++++++++++
+++++++++++++++
+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
@@ -844,7 +844,7 @@ Definition
+----------------------------------------------------------------+
tosca.nodes.nfv.VDU.VirtualStorage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NFV VirtualStorage node type represents a virtual storage entity
which it describes the deployment and operational behavior of a virtual
@@ -868,7 +868,7 @@ presentation. Slide 8. With specific rules of “valid\_target\_type”
+---------------------------+--------------------------------------+
tosca.artifacts.nfv.SwImage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------+------------------------------------+
| **Shorthand Name** | SwImage |
@@ -910,7 +910,7 @@ Properties
+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
Definition
-++++++++++++
+++++++++++++++
+-----------------------------------------------------+
| tosca.artifacts.nfv.SwImage: |
@@ -995,10 +995,10 @@ Definition
+-----------------------------------------------------+
vNAT Example
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
openovnf\_\_vOpenNAT.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------+
| imports: |
@@ -1297,7 +1297,7 @@ openovnf\_\_vOpenNAT.yaml
+-------------------------------------------------------------+
openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------+
| imports: |
@@ -1340,7 +1340,7 @@ openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
+------------------------------------------------------------+
openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------+
| data\_types: |
@@ -1552,7 +1552,7 @@ Heat
---------
General Guidelines
-^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^
YAML Format
^^^^^^^^^^^^^^^^^
@@ -1562,7 +1562,7 @@ Markup Language) is a human friendly data serialization standard for all
programming languages. See http://www.yaml.org/.
Heat Orchestration Template Format
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heat Orchestration templates must be defined in YAML.
@@ -1576,7 +1576,7 @@ YAML rules include:
(e.g., "ThIs", is not the same as "thiS")
Heat Orchestration Template Structure
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Heat Orchestration template structure follows the following format, as
defined by OpenStack at
@@ -1624,7 +1624,7 @@ sections:
- outputs:
heat\_template\_version
-++++++++++++++++++++++
++++++++++++++++++++++++++
This section is ONAP mandatory. The heat\_template\_version must be set
to a date that is supported by the OpenStack environment.
@@ -1889,7 +1889,7 @@ section is specified, it will need to adhere to specific requirements.
See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details.
Environment File Format
-^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^
The environment file is a yaml text file.
(https://docs.openstack.org/developer/heat/template_guide/environment.html)
@@ -1935,7 +1935,7 @@ the mandatory parameter section.
programmatically enforce the use of an environment file.)
SDC Treatment of Environment Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Parameter values enumerated in the environment file are used by SDC as
the default value. However, the SDC user may use the SDC GUI to
@@ -1951,7 +1951,7 @@ environment file and what parameter must not be enumerated in the
environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details.
Nested Heat Orchestration Templates Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP supports nested Heat Orchestration Templates per OpenStack
specifications.
@@ -1975,7 +1975,7 @@ dynamically (via OS::Heat::ResourceGroup).
See `Nested Heat Templates`_ for additional details.
ONAP Heat Orchestration Template Filenames
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order to enable ONAP to understand the relationship between Heat
files, the following Heat file naming convention must be utilized.
@@ -1985,7 +1985,7 @@ must not contain any special characters and must not contain the word
“base”.
Base Modules
-~~~~~~~~~~~~
+~~~~~~~~~~~~~~
The file name for the base module must include “base” in the filename
and must match one of the following options:
@@ -2002,7 +2002,7 @@ The base module’s corresponding environment file must be named identical
to the base module with “.y[a]ml” replaced with “.env”.
Incremental Modules
-~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
There is no explicit naming convention for the incremental modules. As
noted above, <text> represents any alphanumeric string that must not
@@ -2023,7 +2023,7 @@ following naming options for modules:
- module.y[a]ml
Cinder Volume Modules
-~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~
The file name for the Cinder volume module must be named the same as the
corresponding module it is supporting (base module or incremental
@@ -2069,7 +2069,7 @@ Broadly, ONAP categorizes parameters into four categories:
4. Output parameters.
ONAP Metadata Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~
There are both mandatory and optional ONAP metadata parameters
associated with the resource OS::Nova::Server.
@@ -2091,7 +2091,7 @@ categories: **ONAP Orchestration Parameters** and **VNF Orchestration
Parameters**
ONAP Orchestration Parameters
-+++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++
ONAP Orchestration Parameters are per instance parameters where the
value is assigned via ONAP automation. (Note that in some cases,
@@ -2113,7 +2113,7 @@ prior to instantiation.)
additional details.
VNF Orchestration Parameters
-+++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++
VNF Orchestration Parameters are per instance parameters where the
values are assigned manually. They are not supported by ONAP automation.
@@ -2134,7 +2134,7 @@ The per instance values are loaded into ONAP prior to VNF instantiation.
additional details.
Constant Parameters
-~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
The constant parameters are parameters that remain constant across many
VNF instances (e.g., image, flavor). The constant parameters are
@@ -2174,7 +2174,7 @@ VNF Constant Parameters
additional details.
Output Parameters
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
The output parameters are parameters defined in the output section of a
Heat Orchestration Template. The ONAP output parameters are subdivided
@@ -2187,7 +2187,7 @@ into three categories:
3. ONAP Predefined Output Parameters.
ONAP Base Module Output Parameters
-+++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++
ONAP Base Module Output Parameters are declared in the outputs: section
of the base module Heat Orchestration Template. A Base Module Output
@@ -2215,7 +2215,7 @@ Additional details on ONAP Base Module Output Parameters are provided in
`ONAP Output Parameter Names`_ and ONAP VNF Modularity.
ONAP Volume Module Output Parameters
-++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++
The volume template output parameters are only available for the module
(base or add on) that the volume is associated with.
@@ -2244,14 +2244,14 @@ Additional details on ONAP Base Module Output Parameters are provided in
`ONAP Output Parameter Names`_ and `Cinder Volume Templates`_.
ONAP Predefined Output Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP will look for a small set of pre-defined Heat output parameters to
capture resource attributes for inventory in ONAP. These output
parameters are optional and are specified in `OAM Management IP Addresses`_.
Support of heat stack update
-+++++++++++++++++++++++++++++
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VNF Heat Orchestration Templates must not be designed to utilize the
OpenStack heat stack-update command for scaling (growth/de-growth). ONAP
@@ -2261,7 +2261,7 @@ It is important to note that ONAP only supports heat stack-update for
image upgrades.
Networking
-+++++++++++++
+~~~~~~~~~~~~
ONAP defines two types of networks: External Networks and Internal
Networks.
@@ -2281,7 +2281,7 @@ only connects VMs in a single VNF. It must not connect to other VNFs or
an external gateway or router.
External Networks
-+++++++++++++++++++
+~~~~~~~~~~~~~~~~~~
VNF Heat Orchestration Templates must not include any resources for
external networks connected to the VNF. External networks must be
@@ -2334,7 +2334,7 @@ VNF Heat Orchestration Templates must pass the appropriate external
network IDs into nested VM templates when nested Heat is used.
Internal Networks
-+++++++++++++++++
+~~~~~~~~~~~~~~~~~~
The VNF Heat Orchestration Templates must include the resource(s) to
create the internal network. The internal network must be either a
@@ -2373,7 +2373,7 @@ parameters for internal network. However, a naming convention is
provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
ONAP Resource ID and Parameter Naming Convention
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section provides the ONAP naming requirements for
@@ -2425,7 +2425,7 @@ There are two exceptions to the above rules:
identifier. availability\_zone is described in `Property: availability_zone`_.
{network-role}
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
The assignment of a {network-role} is discussed in `Networking`_.
@@ -2460,7 +2460,7 @@ It is recommended that the {network-role} case in the parameter names
matches the {network-role} case in the Resource IDs.
Resource IDs
-^^^^^^^^^^^
+^^^^^^^^^^^^^^
Heat Orchestration Template resources are described in `resources`_
@@ -2578,7 +2578,7 @@ only associated with one {vm-type} and/or one network.
Table 2: Example Contrail Heat resource ID
Resource: OS::Nova::Server - Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The resource OS::Nova::Server manages the running virtual machine (VM)
instance within an OpenStack cloud. (See
@@ -2620,7 +2620,7 @@ parameter for a given OS::Nova::Server resource.
Table 3 Resource Property Parameter Names
Property: image
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
The parameter associated with the property image is an ONAP Constant
parameter.
@@ -2647,7 +2647,7 @@ maximum clarity and flexibility.
description: {vm-type} server image
Property: flavor
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
The parameter associated with the property flavor is an ONAP Constant
parameter.
@@ -2674,7 +2674,7 @@ provides maximum clarity and flexibility.
description: {vm-type} flavor
Property: Name
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
The parameter associated with the property name is an ONAP Orchestration
parameter.
@@ -2767,7 +2767,7 @@ balancer.
...
Contrail Issue with Values for OS::Nova::Server Property Name
-+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Contrail GUI has a limitation displaying special characters. The
issue is documented in
@@ -2778,7 +2778,7 @@ characters must be used, the only special characters supported are:
- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
Property: availability\_zone
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The parameter associated with the property availability\_zone is an ONAP
Orchestration parameter.
@@ -2795,7 +2795,7 @@ The parameter must be declared as type: string
The parameter must not be declared as type: comma\_delimited\_list
Example
-~~~~~~~
+~~~~~~~~~
The example below depicts part of a Heat Orchestration Template that
uses the four OS::Nova::Server properties discussed in this section.
@@ -2875,7 +2875,7 @@ for dns and a string for oam.
. . .
Resource: OS::Nova::Server – Metadata Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The resource OS::Nova::Server has an OpenStack optional property
metadata. The metadata property is mandatory for ONAP Heat Orchestration
@@ -2924,7 +2924,7 @@ additional details.
Table 4: ONAP Metadata
vnf\_id
-~~~~~~~
+~~~~~~~~~
The vnf\_id parameter is mandatory; it must be included in the Heat
Orchestration Template.
@@ -2949,7 +2949,7 @@ The parameter must not be enumerated in the Heat environment file.
description: Unique ID for this VNF instance
vf\_module\_id
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
The vf\_module\_id parameter is mandatory; it must be included in the
Heat Orchestration Template.
@@ -2974,7 +2974,7 @@ The parameter must not be enumerated in the Heat environment file.
description: Unique ID for this VNF module instance
vnf\_name
-~~~~~~~~~
+~~~~~~~~~~~
The vnf\_name parameter is mandatory; it must be included in the Heat
Orchestration Template.
@@ -2999,7 +2999,7 @@ The parameter must not be enumerated in the Heat environment file.
description: Unique name for this VNF instance
vf\_module\_name
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
The vf\_module\_name parameter is optional; it may be included in the
Heat Orchestration Template.
@@ -3025,7 +3025,7 @@ The parameter must not be enumerated in the Heat environment file.
description: Unique name for this VNF Module instance
vm\_role
-~~~~~~~~
+~~~~~~~~~
The vm\_role parameter is optional; it may be included in the Heat
Orchestration Template.
@@ -3085,7 +3085,7 @@ In this example, the {vm-role} is enumerated in the environment file.
vm_role: { get_param: vm_role }
Example
-~~~~~~~
+~~~~~~~~
The example below depicts part of a Heat Orchestration Template that
uses the five of the OS::Nova::Server metadata parameter discussed in
@@ -3128,13 +3128,13 @@ this section. The {vm-type} has been defined as lb for load balancer.
vm_role: lb
Resource: OS::Neutron::Port - Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The resource OS::Neutron::Port is for managing Neutron ports (See
https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.)
Introduction
-~~~~~~~~~~~~
+~~~~~~~~~~~~~~
Four properties of the resource OS::Neutron::Port that must follow the
ONAP parameter naming convention. The four properties are:
@@ -3152,7 +3152,7 @@ external network or internal network. External networks and internal
networks are defined in `Networking`_.
External Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter references an external network
@@ -3198,7 +3198,7 @@ Table 5: OS::Neutron::Port Resource Property Parameters (External
Networks)
Internal Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter references an internal network
@@ -3241,14 +3241,14 @@ When the parameter references an internal network
Table 6: Port Resource Property Parameters (Internal Networks)
Property: network
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
The property networks in the resource OS::Neutron::Port must be
referenced by Neutron Network ID, a UUID value, or by the network name
defined in OpenStack.
External Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter associated with the property network is referencing
an “external” network, the parameter must adhere to the following naming
@@ -3295,7 +3295,7 @@ to assign IP addresses.
network: { get_param: oam_net_id }
Internal Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter associated with the property network is referencing
an “internal” network, the parameter must adhere to the following naming
@@ -3343,7 +3343,7 @@ Note that DHCP assignment of IP addresses is also referred to as cloud
assigned IP addresses.
Subnet of an External Networks
-+++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
When the parameter is referencing a subnet of an “external” network, the
property fixed\_ips and Map Property subnet\_id parameter must adhere to
@@ -3429,7 +3429,7 @@ balancer.
- subnet_id: { get_param: oam_v6_subnet_id }
Internal Networks
-++++++++++++++++
++++++++++++++++++++
When the parameter is referencing the subnet of an “internal” network,
the property fixed\_ips and Map Property subnet\_id parameter must
@@ -3483,7 +3483,7 @@ network, the parameter name must contain {vm-type} and
int\_{network-role}.
IP Address Assignments on External Networks
-+++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++
When the property fixed\_ips and Map Property ip\_address is used to
assign IP addresses to an external network, the parameter name is
@@ -3622,7 +3622,7 @@ database.
- “ip_address”: {get_param: db_oam_v6_ip_1}}]
IP Address Assignment on Internal Networks
-++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++
When the property fixed\_ips and Map Property ip\_address is used to
assign IP addresses to an internal network, the parameter name is
@@ -3803,7 +3803,7 @@ of public IPs to VMs is via OpenStack commands. ONAP does not support
Neutron-style Floating IPs.
External Networks
-++++++++++++++++
++++++++++++++++++++
When the parameter is referencing an “external” network, the property
allowed\_address\_pairs and Map Property ip\_address parameter must
@@ -3867,7 +3867,7 @@ an oam network and the {vm-type} has been defined as db for database.
allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}]
Internal Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter is referencing an “internal” network, the property
allowed\_address\_pairs and Map Property ip\_address parameter must
@@ -3896,7 +3896,7 @@ The parameter must be enumerated in the Heat environment file.
description: VIP for {vm-type} VMs on the int_{network-role} network
Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The parameter {vm-type}\_{network-role}\_floating\_ip provides only one
allowed address pair IPv4 address per {vm-type} and {network-role} pair.
@@ -4003,7 +4003,7 @@ The VMs must be of the same {vm-type}.
The VMs must be created in the same module (base or incremental).
Resource Property “name”
-^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The parameter naming convention of the property name for the resource
OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_.
@@ -4225,7 +4225,7 @@ oam\_management\_v4\_address
value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] }
Contrail Resource Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP requires the parameter names of certain Contrail Resources to
follow specific naming conventions. This section provides these
@@ -4238,7 +4238,7 @@ Contrail based resources may require references to a Contrail network
using the network FQDN.
External Networks
-++++++++++++++++
++++++++++++++++++++
When the parameter associated with the Contrail Network is referencing
an “external” network, the parameter must adhere to the following naming
@@ -4347,7 +4347,7 @@ The parameter must not be enumerated in the Heat environment file.
- service_instance_refs_data_interface_type: { get_param: int_fw_interface_type }
Parameter Names in Contrail Resources
-++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++
Contrail Heat resource properties will use, when appropriate, the same
naming convention as OpenStack Heat resources. For example, the resource
@@ -4401,7 +4401,7 @@ represent an oam protected network and the {vm-type} has been defined as
subnet_uuid: { get_param: oam_protected_subnet_id }
Cinder Volume Templates
-^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP supports the independent deployment of a Cinder volume via separate
Heat Orchestration Templates, the Cinder Volume module. This allows the
@@ -4507,7 +4507,7 @@ incremental.yaml
volume_id: { get_param: lb_volume_id_0 }
ONAP Support of Environment Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The use of an environment file in OpenStack is optional. In ONAP, it is
mandatory. A Heat Orchestration Template uploaded to ONAP must have a
@@ -4544,7 +4544,7 @@ Orchestration Parameters). These parameters are supplied to the Heat by
ONAP at orchestration time.
SDC Treatment of Environment Files
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Parameter values enumerated in the environment file are used by SDC as
the default value. However, the SDC user may use the SDC GUI to
@@ -4558,7 +4558,7 @@ updates, the SDC generated environment file will contain the same values
as the uploaded file.
Use of Environment Files when using OpenStack “heat stack-create” CLI
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When ONAP is instantiating the Heat Orchestration Template, certain
parameter must not be enumerated in the environment file. This document
@@ -4627,7 +4627,7 @@ Note that:
get\_attribute targets against the “parent” resource.
Nested Heat Template Example: Static
-+++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
incremental.yaml
@@ -4767,7 +4767,7 @@ the VNF.
index: index
Availability Zone and ResourceGroups
-+++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
The resource OS::Heat::ResourceGroup and the property availability\_zone
has been an “issue” with a few VNFs since ONAP only supports
@@ -4818,7 +4818,7 @@ In the nested heat
OS::Heat::ResourceGroup is created for each availability zone.
External References
-^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^
Heat templates *should not* reference any HTTP-based resource
definitions, any HTTP-based nested configurations, or any HTTP-based
@@ -5086,7 +5086,7 @@ availability zone IDs:
availability zones as desired
Post Orchestration & VNF Configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heat templates should contain a minimum amount of post-orchestration
configuration data. For instance, *do not* embed complex user-data