summaryrefslogtreecommitdiffstats
path: root/docs/Chapter5.rst
diff options
context:
space:
mode:
authorBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-03-21 22:14:53 +0000
committerBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-03-21 22:19:28 +0000
commit50a0da904060eb51cb750e4c00bdbd9680008d3e (patch)
treeb03ec5597e20657cc3bb838cacc8dbb6e5833883 /docs/Chapter5.rst
parent7a0850e419756b9b61c86aa00d2dfa20f94ec395 (diff)
VNFRQTS - Updating header structure
Updated the index file as well updated the structure of the RST files to make the hierarchy more organized. Change-Id: Ic6f667f5eeafcb04bfd96b76e85aebf9869b2f1b Issue-ID: VNFRQTS-130 Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
Diffstat (limited to 'docs/Chapter5.rst')
-rw-r--r--docs/Chapter5.rst208
1 files changed, 103 insertions, 105 deletions
diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst
index 55d49c7..030925f 100644
--- a/docs/Chapter5.rst
+++ b/docs/Chapter5.rst
@@ -1,19 +1,17 @@
-:tocdepth: 2
-
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-**5. VNF Modeling Requirements**
+**VNF Modeling Requirements**
=====================================
-a. TOSCA YAML
-=============
+TOSCA YAML
+----------------------
Introduction
--------------
+^^^^^^^^^^^
This reference document is the VNF TOSCA Template Requirements for
ONAP, which provides recommendations and standards for building VNF
@@ -29,13 +27,13 @@ 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.
Scope
------
+^^^^^^^^^^^^^^^^
ONAP implementations of Network Cloud supports TOSCA Templates, also
referred to as TOSCA in this document.
@@ -45,7 +43,7 @@ document provides the mandatory, recommended, and optional requirements
associated with this format.
Overview
----------
+^^^^^^^^^^^^^^^^
The document includes three charters to help the VNF providers to use the
VNF model design tools and understand the VNF package structure and VNF
@@ -64,13 +62,13 @@ supports multiple TOSCA template yaml files, and also supports
self-defined node or other extensions.
NFV TOSCA Template
-------------------
+^^^^^^^^^^^^^^^^^^^^
TOSCA templates supported by ONAP must follow the requirements
enumerated in this section.
TOSCA Introduction
-------------------
+^^^^^^^^^^^^^^^^^^^^
TOSCA defines a Meta model for defining IT services. This Meta model
defines both the structure of a service as well as how to manage it. A
@@ -95,14 +93,14 @@ how many times the component can occur.
Figure 1: Structural Elements of Service Template and their Relations
TOSCA Modeling Principles & Data Model
---------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section describing TOSCA modeling principles and data model for
NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
V1.0], or new type based on ETSI NFV requirements, etc.
VNF Descriptor Template
------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^
The VNF Descriptor (VNFD) describes the topology of the VNF by means of
ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
@@ -189,7 +187,7 @@ specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
+--------------------------------------------------------------------+
EPA Requirements
-----------------
+^^^^^^^^^^^^^^^^
1. SR-IOV Passthrought
@@ -410,7 +408,7 @@ supports dpdk. Here is an example.
+------------------------------------------------------+
NFV TOSCA Type Definition
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^
tosca.capabilites.nfv.VirtualCompute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -426,7 +424,7 @@ tosca.capabilites.nfv.VirtualCompute
+---------------------------+-----------------------------------------+
Properties
-^^^^^^^^^^
++++++++++
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
@@ -442,7 +440,7 @@ Properties
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
Definition
-^^^^^^^^^^
++++++++++
+-----------------------------------------------------------+
| tosca.capabilities.nfv.VirtualCompute: |
@@ -495,13 +493,13 @@ NFV IFA011].**
Attributes
-^^^^^^^^^^
++++++++++
None
Capabilities
-^^^^^^^^^^^^
++++++++++++
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
| Name | Type | Constraints | Description |
@@ -518,7 +516,7 @@ Capabilities
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
Definition
-^^^^^^^^^^
++++++++++++
+-----------------------------------------------------------------------------------------------------+
| tosca.nodes.nfv.VDU.Compute: |
@@ -659,7 +657,7 @@ Definition
+-----------------------------------------------------------------------------------------------------+
Artifact
-^^^^^^^^
++++++++++++
+-----------+------------+-------------------------------+---------------+------------------------------------------------+
| Name | Required | Type | Constraints | Description |
+===========+============+===============================+===============+================================================+
@@ -689,7 +687,7 @@ used as parent for the various Cpd types.
Attributes
-^^^^^^^^^^
++++++++++++
+--------+------------+--------+---------------+---------------+
| Name | Required | Type | Constraints | Description |
@@ -697,17 +695,17 @@ Attributes
+--------+------------+--------+---------------+---------------+
Requirements
-^^^^^^^^^^^^
++++++++++++
None
Capabilities
-^^^^^^^^^^^^
++++++++++++
None
Definition
-^^^^^^^^^^
++++++++++++
+----------------------------------------------------------------------+
| tosca.nodes.nfv.Cpd: |
@@ -754,7 +752,7 @@ Definition
+----------------------------------------------------------------------+
Additional Requirement
-^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++
None.
@@ -774,7 +772,7 @@ internal VL as defined by [ETSI GS NFV-IFA 011].
+-----------------------+--------------------------+
Properties
-^^^^^^^^^^
+++++++++++++
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
@@ -787,12 +785,12 @@ Properties
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
Attributes
-^^^^^^^^^^
+++++++++++++
None
Requirements
-^^^^^^^^^^^^
+++++++++++++
+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
@@ -803,7 +801,7 @@ Requirements
+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
Definition
-^^^^^^^^^^
+++++++++++++
+----------------------------------------------------------------+
| tosca.nodes.nfv.VduCpd: |
@@ -883,7 +881,7 @@ tosca.artifacts.nfv.SwImage
+---------------------------+------------------------------------+
Properties
-^^^^^^^^^^
+++++++++++++
+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
@@ -912,7 +910,7 @@ Properties
+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
Definition
-^^^^^^^^^^
+++++++++++++
+-----------------------------------------------------+
| tosca.artifacts.nfv.SwImage: |
@@ -997,7 +995,7 @@ Definition
+-----------------------------------------------------+
vNAT Example
-------------
+^^^^^^^^^^^^^
openovnf\_\_vOpenNAT.yaml
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1550,21 +1548,21 @@ openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
:height: 2.46042in
-b. Heat
-=======
+Heat
+---------
General Guidelines
-------------------
+^^^^^^^^^^^^^^^^^
YAML Format
------------
+^^^^^^^^^^^^^^^^^
Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't
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.
@@ -1626,24 +1624,24 @@ 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.
description
-^^^^^^^^^^^
+++++++++++++++++++++++
This ONAP mandatory section allows for a description of the template.
parameter\_groups
-^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++
This ONAP optional section allows for specifying how the input
parameters should be grouped and the order to provide the parameters in.
parameters
-^^^^^^^^^^
+++++++++++++++++++++++
The parameter section is ONAP mandatory. This section allows for
specifying input parameters that have to be provided when instantiating
@@ -1789,7 +1787,7 @@ availability\_zone.
- This attribute is optional and defaults to false.
resources
-^^^^^^^^^
++++++++++++
This section is ONAP mandatory; it must be provided. This section
contains the declaration of the single resources of the template. This
@@ -1883,7 +1881,7 @@ with the following syntax.
create the resource or not. This attribute is optional.
outputs
-^^^^^^^
++++++++++
This ONAP optional section allows for specifying output parameters
available to users once the template has been instantiated. If the
@@ -1891,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)
@@ -1953,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.
@@ -1977,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.
@@ -2054,7 +2052,7 @@ nested heat file must be passed in as properties in the resource
definition defined in the parent heat template.
ONAP Parameter Classifications Overview
----------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order for ONAP to support workflow automation, Heat Orchestration
Template resource property parameters must adhere to specific naming
@@ -2093,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,
@@ -2115,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.
@@ -2143,7 +2141,7 @@ VNF instances (e.g., image, flavor). The constant parameters are
subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.**
ONAP Constant Parameters
-^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++
- ONAP Constant Parameters must be enumerated in the environment file.
These parameter values are not assigned by ONAP.
@@ -2159,7 +2157,7 @@ ONAP Constant Parameters
parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details.
VNF Constant Parameters
-^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++
- VNF Constant Parameters must be enumerated in the environment file.
These parameter values are not assigned by ONAP.
@@ -2189,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
@@ -2217,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.
@@ -2253,7 +2251,7 @@ 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
@@ -2263,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.
@@ -2283,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
@@ -2336,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
@@ -2375,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
@@ -2384,7 +2382,7 @@ This section provides the ONAP naming requirements for
2. Resource Property Parameters
{vm-type}
----------
+^^^^^^^^^^^
The Heat Orchestration Templates for a VNF must assign a VNF unique
{vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
@@ -2427,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`_.
@@ -2462,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`_
@@ -2580,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
@@ -2769,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
@@ -2877,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
@@ -3130,7 +3128,7 @@ 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.)
@@ -3154,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
@@ -3200,7 +3198,7 @@ Table 5: OS::Neutron::Port Resource Property Parameters (External
Networks)
Internal Networks
-^^^^^^^^^^^^^^^^^
+++++++++++++++++
When the parameter references an internal network
@@ -3250,7 +3248,7 @@ 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
@@ -3297,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
@@ -3345,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
@@ -3431,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
@@ -3485,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
@@ -3624,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
@@ -3805,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
@@ -3869,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
@@ -3898,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.
@@ -3994,7 +3992,7 @@ As a general rule, provide the fixed IPs for the VMs indexed first in
the CDL and then the VIPs as shown in the examples above.
ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The following items must be taken into consideration when designing Heat
Orchestration Templates that expect ONAP’s SDN-C to assign
@@ -4005,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`_.
@@ -4090,7 +4088,7 @@ the only special characters supported are:
- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
ONAP Output Parameter Names
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
@@ -4114,7 +4112,7 @@ ONAP currently defines one predefined output parameter the OAM
Management IP Addresses.
OAM Management IP Addresses
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++
A VNF may have a management interface for application controllers to
interact with and configure the VNF. Typically, this will be via a
@@ -4227,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
@@ -4240,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
@@ -4349,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
@@ -4403,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
@@ -4509,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
@@ -4546,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
@@ -4560,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
@@ -4572,10 +4570,10 @@ stack-create”, all parameters must be enumerated in the environment
file.
Heat Template Constructs
-------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nested Heat Templates
----------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP supports nested Heat templates per the OpenStack specifications.
Nested templates may be suitable for larger VNFs that contain many
@@ -4629,7 +4627,7 @@ Note that:
get\_attribute targets against the “parent” resource.
Nested Heat Template Example: Static
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++
incremental.yaml
@@ -4749,7 +4747,7 @@ You can then reference within the nested template as:
{ get\_param: [names, {get\_param: index} ] }
ResourceGroup Property count
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++
ONAP requires that the OS::Heat::ResourceGroup property count be defined
(even if the value is one) and that the value must be enumerated in the
@@ -4769,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
@@ -4820,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
@@ -4837,7 +4835,7 @@ environment files.
is accessing information with the VM private/internal network.
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
@@ -4865,7 +4863,7 @@ Support for Heat Files is subject to the following limitations:
templates
Key Pairs
----------
+^^^^^^^^^^^^^^^^^^
When Nova Servers are created via Heat templates, they may be passed a
“keypair” which provides an ssh key to the ‘root’ login on the newly
@@ -4930,7 +4928,7 @@ of lb (for load balancer)):*
save_private_key: false
Security Groups
----------------
+^^^^^^^^^^^^^^^^^^
OpenStack allows a tenant to create Security groups and define rules
within the security groups.
@@ -4945,7 +4943,7 @@ network or it can vary by VM (i.e., {vm-type}) and network type (i.e.,
{network-role}).
Anti-Affinity and Affinity Rules
---------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Anti-affinity or affinity rules are supported using normal OpenStack
OS::Nova::ServerGroup resources. Separate ServerGroups are typically
@@ -5006,7 +5004,7 @@ balancer and db for database.
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:
@@ -5076,7 +5074,7 @@ oam server.
instance_uuid: {get_resource: oam_server_01}
High Availability
------------------
+^^^^^^^^^^^^^^^^^^
VNF/VM parameters may include availability zone IDs for VNFs that
require high availability.
@@ -5088,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
@@ -5101,8 +5099,8 @@ to the Heat template.
*Note:* It is important to follow this convention to the extent possible
even in the short-term as of the long-term direction.
-c. VNFM Driver Development Steps
-================================
+VNFM Driver Development Steps
+---------------------------------------------------------
Refer to the ONAP documentation for VNF Provider instructions on integrating
vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are
@@ -5117,8 +5115,8 @@ is a microservice providing a translation interface from VF-C to
the vendor-specific VNFM. The interface definitions of vendor-specific VNFM adaptors are supplied by
the VNF Providers themselves.
-d. Creating Vendor-Specific VNFM Adaptor Microservices
-======================================================
+Creating Vendor-Specific VNFM Adaptor Microservices
+------------------------------------------------------------------------------------------------------------------
VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific VNFM to ONAP, a
vendor-specific VNFM adaptor is added to ONAP implementing the interface of the vendor-specific VNFM.