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>
This section contains a list of normative and informative references along with information on acquiring the identified references. Normative references are required to be implemented by this document. Informative references are for informational purposes only.
Normative References
-^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^
+---------------+---------------------------------------------------------------------------------------------------------------+
| Reference | Description |
+===============+===============================================================================================================+
+---------------+---------------------------------------------------------------------------------------------------------------+
Informative References
-^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
+---------------+---------------------------------------------------------------------------------------------------------------+
| Reference | Description |
+===============+===============================================================================================================+
+---------------+---------------------------------------------------------------------------------------------------------------+
Reference Acquisition
-^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^
IETF Specifications:
- Internet Engineering Task Force (IETF) Secretariat, 48377 Fremont Blvd., Suite 117, Fremont, California 94538, USA; Phone: +1-510-492-4080, Fax: +1-510-492-4001.
Below are more detailed resiliency requirements for VNFs.
All Layer Redundancy
-^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^
Design the VNF to be resilient to the failures of the underlying
virtualized infrastructure (Network Cloud). VNF design considerations
* R-36843 The VNF **MUST** support the ability of the VNFC to be deployable in multi-zoned cloud sites to allow for site support in the event of cloud zone failure or upgrades.
Minimize Cross Data-Center Traffic
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Avoid performance-sapping data center-to-data center replication delay
by applying techniques such as caching and persistent transaction paths
* R-92935 The VNF **SHOULD** minimize the propagation of state information across multiple data centers to avoid cross data center traffic.
Application Resilient Error Handling
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ensure an application communicating with a downstream peer is equipped
to intelligently handle all error conditions. Make sure code can handle
System Resource Optimization
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ensure an application is using appropriate system resources for the task
at hand; for example, do not use network or IO operations inside
Application Configuration Management
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Leverage configuration management audit capability to drive conformity
to develop gold configurations for technologies like Java, Python, etc.
Intelligent Transaction Distribution & Management
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Leverage Intelligent Load Balancing and redundant components (hardware
and modules) for all transactions, such that at any point in the
* R-27995 The VNF **SHOULD** include control loop mechanisms to notify the consumer of the VNF of their exceeding SLA thresholds so the consumer is able to control its load against the VNF.
Deployment Optimization
-^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
Reduce opportunity for failure, by human or by machine, through smarter
deployment practices and automation. This can include rolling code
* R-16039 The VNF **SHOULD** test for adherence to the defined resiliency rating recommendation at each layer, during each delivery cycle so that the resiliency rating is measured and feedback is provided where software resiliency requirements are not met.
Monitoring & Dashboard
-^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^
Promote dashboarding as a tool to monitor and support the general
operational health of a system. It is critical to the support of the
requirements associated with data protection.
VNF General Security Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section provides details on the VNF general security requirements
on various security areas such as user access control, network security,
* R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API, authenticate system to system communications where one system accesses the resources of another system, and must never conceal individual accountability.
VNF Identity and Access Management Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following security requirements for logging, identity, and access
management need to be met by the solution in a virtual environment:
VNF API Security Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section covers API security requirements when these are used by the
VNFs. Key security areas covered in API security are Access Control,
VNF Security Analytics Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section covers VNF security analytics requirements that are mostly
applicable to security monitoring. The VNF Security Analytics cover the
* R-84160 The VNF **MUST** have security logging for VNFs and their OSs be active from initialization. Audit logging includes automatic routines to maintain activity records and cleanup programs to ensure the integrity of the audit/logging systems.
VNF Data Protection Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section covers VNF data protection requirements that are mostly
applicable to security monitoring.
---------------------------
ONAP Heat Orchestration Templates: Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP supports a modular Heat Orchestration Template design pattern,
referred to as *VNF Modularity.*
ONAP VNF Modularity Overview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With VNF Modularity, a single VNF may be composed from one or more Heat
Orchestration Templates, each of which represents a subset of the
ONAP VNF Modularity
-^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^
ONAP supports a modular Heat Orchestration Template design pattern,
referred to as *VNF Modularity.* With this approach, a single VNF may be
template.
Suggested Patterns for Modular VNFs
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are numerous variations of VNF modularity. Below are two suggested
usage patterns.
options.
Modularity Rules
-^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
There are some rules to follow when building modular VNF templates:
name in the add-on module
VNF Modularity Examples
-^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
*Example: Base Module creates SecurityGroup*
Introduction
-^^^^^^^^^^^
+^^^^^^^^^^^^^^
This reference document is the VNF TOSCA Template Requirements for
ONAP, which provides recommendations and standards for building VNF
Threading, SRIOV， etc.
Intended Audience
-^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
This document is intended for persons developing VNF TOSCA templates
that will be orchestrated by ONAP.
+--------------------------------------------------------------------+
EPA Requirements
-^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
1. SR-IOV Passthrought
+------------------------------------------------------+
NFV TOSCA Type Definition
-^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
tosca.capabilites.nfv.VirtualCompute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------+-----------------------------------------+
| **Shorthand Name** | VirtualCompute |
+---------------------------+-----------------------------------------+
Properties
-+++++++++
+++++++++++++
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
+-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
Definition
-+++++++++
+++++++++++++
+-----------------------------------------------------------+
| tosca.capabilities.nfv.VirtualCompute: |
+-----------------------------------------------------------+
tosca.nodes.nfv.VDU.Compute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NFV Virtualization Deployment Unit (VDU) compute node type
represents a VDU entity which it describes the deployment and
Attributes
-+++++++++
++++++++++++
None
Capabilities
-+++++++++++
+++++++++++++++
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
| Name | Type | Constraints | Description |
+-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
Definition
-+++++++++++
++++++++++++++
+-----------------------------------------------------------------------------------------------------+
| tosca.nodes.nfv.VDU.Compute: |
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
Attributes
-+++++++++++
++++++++++++++
+--------+------------+--------+---------------+---------------+
| Name | Required | Type | Constraints | Description |
+--------+------------+--------+---------------+---------------+
Requirements
-+++++++++++
++++++++++++++
None
Capabilities
-+++++++++++
++++++++++++++
None
Definition
-+++++++++++
+++++++++++++
+----------------------------------------------------------------------+
| tosca.nodes.nfv.Cpd: |
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
+-----------------------+--------------------------+
Properties
-++++++++++++
+++++++++++++++
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
None
Requirements
-++++++++++++
+++++++++++++++
+--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
| Name | Required | Type | Constraints | Description |
+----------------------------------------------------------------+
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
+---------------------------+--------------------------------------+
tosca.artifacts.nfv.SwImage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------+------------------------------------+
| **Shorthand Name** | SwImage |
+------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
Definition
-++++++++++++
+++++++++++++++
+-----------------------------------------------------+
| tosca.artifacts.nfv.SwImage: |
+-----------------------------------------------------+
vNAT Example
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
openovnf\_\_vOpenNAT.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------+
| imports: |
+-------------------------------------------------------------+
openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------+
| imports: |
+------------------------------------------------------------+
openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------+
| data\_types: |
---------
General Guidelines
-^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^
YAML Format
^^^^^^^^^^^^^^^^^
programming languages. See http://www.yaml.org/.
Heat Orchestration Template Format
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heat Orchestration templates must be defined in YAML.
(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
- 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.
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)
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
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.
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.
“base”.
Base Modules
-~~~~~~~~~~~~
+~~~~~~~~~~~~~~
The file name for the base module must include “base” in the filename
and must match one of the following options:
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
- 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
4. Output parameters.
ONAP Metadata Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~
There are both mandatory and optional ONAP metadata parameters
associated with the resource OS::Nova::Server.
Parameters**
ONAP Orchestration Parameters
-+++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++
ONAP Orchestration Parameters are per instance parameters where the
value is assigned via ONAP automation. (Note that in some cases,
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.
additional details.
Constant Parameters
-~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
The constant parameters are parameters that remain constant across many
VNF instances (e.g., image, flavor). The constant parameters are
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
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
`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.
`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
image upgrades.
Networking
-+++++++++++++
+~~~~~~~~~~~~
ONAP defines two types of networks: External Networks and Internal
Networks.
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
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
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
identifier. availability\_zone is described in `Property: availability_zone`_.
{network-role}
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
The assignment of a {network-role} is discussed in `Networking`_.
matches the {network-role} case in the Resource IDs.
Resource IDs
-^^^^^^^^^^^
+^^^^^^^^^^^^^^
Heat Orchestration Template resources are described in `resources`_
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
Table 3 Resource Property Parameter Names
Property: image
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
The parameter associated with the property image is an ONAP Constant
parameter.
description: {vm-type} server image
Property: flavor
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
The parameter associated with the property flavor is an ONAP Constant
parameter.
description: {vm-type} flavor
Property: Name
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
The parameter associated with the property name is an ONAP Orchestration
parameter.
...
Contrail Issue with Values for OS::Nova::Server Property Name
-+++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The Contrail GUI has a limitation displaying special characters. The
issue is documented in
- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_
Property: availability\_zone
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The parameter associated with the property availability\_zone is an ONAP
Orchestration parameter.
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.
. . .
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
Table 4: ONAP Metadata
vnf\_id
-~~~~~~~
+~~~~~~~~~
The vnf\_id parameter is mandatory; it must be included in the Heat
Orchestration Template.
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.
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.
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.
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.
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
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:
networks are defined in `Networking`_.
External Networks
-++++++++++++++++
+++++++++++++++++++
When the parameter references an external network
Networks)
Internal Networks
-++++++++++++++++
+++++++++++++++++++
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
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
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
- 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
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
- “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
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
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
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.
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`_.
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
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
- 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
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
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
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
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
get\_attribute targets against the “parent” resource.
Nested Heat Template Example: Static
-+++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
incremental.yaml
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
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
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
Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_.
NETCONF Standards and Capabilities
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP Controllers and their Adapters utilize device YANG model and
NETCONF APIs to make the required changes in the VNF state and
* R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, “Using the Network Configuration Protocol over Secure Shell”.
VNF REST APIs
-^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
Healthcheck is a command for which no NETCONF support exists. Therefore, this must be supported using a RESTful interface (defined in this section) or
with a Chef cookbook/Ansible playbook (defined in sections `Chef Standards and Capabilities`_ and `Ansible Standards and Capabilities`_).
Chef Standards and Capabilities
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP will support configuration of VNFs via Chef subject to the
requirements and guidelines defined in this section.
(https://downloads.chef.io/).
VNF Configuration via Chef Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chef Client Requirements
-++++++++++++++++++++++
++++++++++++++++++++++++++
* R-79224 The xNF **MUST** have the chef-client be preloaded with validator keys and configuration to register with the designated Chef Server as part of the installation process.
* R-72184 The xNF **MUST** have routable FQDNs for all the endpoints (VMs) of a xNF that contain chef-clients which are used to register with the Chef Server. As part of invoking xNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a xNF, if required.
- Chef push jobs client >= 2.0
Chef Roles/Requirements
-++++++++++++++++++++++
+++++++++++++++++++++++++++
* R-27310 The xNF Package **MUST** include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute xNF actions requested by ONAP for loading on appropriate Chef Server.
* R-26567 The xNF Package **MUST** include a run list of roles/cookbooks/recipes, for each supported xNF action, that will perform the desired xNF action in its entirety as specified by ONAP (see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF actions and requirements), when triggered by a chef-client run list in JSON file.
Object attribute node[‘PushJobOutput’].
Ansible Standards and Capabilities
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP will support configuration of VNFs via Ansible subject to the
requirements and guidelines defined in this section.
will host and run playbooks to manage VNFs that support Ansible.
VNF Configuration via Ansible Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ansible Client Requirements
-++++++++++++++++++++++++
++++++++++++++++++++++++++++++
* R-32217 The xNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a xNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [3]_.
* R-54373 The xNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a xNF on which an Ansible playbook will be executed.
* R-91745 The VNF **MUST** update the Ansible Server and other entities storing and using the SSH key for authentication when the SSH key used by Ansible is regenerated/updated.
Ansible Playbook Requirements
-++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++
An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action.
See `VNF REST APIs`_ for additional details on HealthCheck.
ONAP Controller / Ansible API Usage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section outlines the workflow that ONAP Controller invokes when it receives an action request against an Ansible managed VNF.
ONAP Controller APIs and Behavior
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ONAP Controllers such as APPC expose a northbound API to clients which offer a set of commands. The following commands are expected to be supported
on all VNF’s if applicable, either directly (via the Netconf interface) or indirectly (via a Chef or Ansible server). There are additional commands
data directly to the ONAP collection layer using standardized interfaces.
Data Model for Event Records
-^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This section describes the data model for the collection of telemetry data from VNFs
by Service Providers (SPs) to manage VNF health and runtime lifecycle. This data
Figure 1. Data Model for Event Records
Event Records - Data Structure Description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The data structure for event records consists of:
sequence number, etc.
Technology Independent Records – Fault Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Fault Record, describing a condition in the Fault domain, contains
information about the fault such as the entity under fault, the
severity, resulting status, etc.
Technology Independent Records – Heartbeat Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Heartbeat Record provides an optional structure for communicating
information about heartbeat or watchdog signaling events. It can
implementation.
Technology Independent Records – State Change Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The State Change Record provides a structure for communicating information
about data flow through the VNF. It can contain information about state
when cards or port name of the entity that has changed state.
Technology Independent Records – Syslog Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Syslog Record provides a structure for communicating any type of
information that may be logged by the VNF. It can contain information
about system internal events, status, errors, etc.
Technology Independent Records – Threshold Crossing Alert Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Threshold Crossing Alert (TCA) Record provides a structure for
communicating information about threshold crossing alerts. It can
and physical or logical details.
Technology Independent Records - VNF Scaling Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The VNF Scaling\* (short for measurementForVfScalingFields –
actual name used in JSON specification) Record contains information
the management of the resources for purposes of elastic scaling.
Technology Independent Records – otherFields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The otherFields Record defines fields for events belonging to the
otherFields domain of the Technology Independent domain enumeration.
type is discouraged and should be minimized.
Technology Specific Records – Mobile Flow Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Mobile Flow Record provides a structure for communicating
information about data flow through the VNF. It can contain
elements for mobile service, such as between LTE reference points, etc.
Technology Specific Records – Signaling Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Signaling Record provides a structure for communicating information
about signaling messages, parameters and signaling state. It can
multimedia communication sessions such as voice and video calls.
Technology Specific Records – Voice Quality Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Voice Quality Record provides a structure for communicating information
about voice quality statistics including media connection information,
such as transmitted octet and packet counts, packet loss, packet delay
variation, round-trip delay, QoS parameters and codec selection.
Technology Specific Records – Future Domains
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The futureDomains Record is a placeholder for additional technology
specific areas of interest that will be defined and described
in the future documents.
Data Structure Specification of the Event Record
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For additional information on the event record formats of the data
structures mentioned above, please refer to `VES Event
Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__.
Transports and Protocols Supporting Resource Interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Delivery of data from VNFs to ONAP must use the common transport mechanisms and protocols
for all VNFs as defined in this document. Transport mechanisms and protocols have been
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VNF telemetry via standardized interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* R-51910 The xNF **MUST** provide all telemetry (e.g., fault event records, syslog records, performance records etc.) to ONAP using the model, format and mechanisms described in this section.
Encoding and Serialization
-~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
Content delivered from VNFs to ONAP is to be encoded and serialized using JSON:
Reporting Frequency
-~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
* R-98191 The xNF **MUST** vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together. For example, alarms and alerts are expected to be delivered as soon as they appear. In contrast, other content, such as performance measurements, KPIs or reported network signaling may have various ways of packaging and delivering content. Some content should be streamed immediately; or content may be monitored over a time interval, then packaged as collection of records and delivered as block; or data may be collected until a package of a certain size has been collected; or content may be summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered.
* R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses as data destinations for each xNF, and may be changed by Policy while the xNF is in operation. We expect the xNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another.
Asynchronous and Synchronous Data Delivery
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* R-06924 The xNF **MUST** deliver asynchronous data as data becomes available, or according to the configured frequency.
* R-73285 The xNF **MUST** must encode, address and deliver the data as described in the previous paragraphs.
* R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in “Encoding and Serialization” section.
Security
-~~~~~~~
+~~~~~~~~~~
* R-42366 The xNF **MUST** support secure connections and transports such as Transport Layer Security (TLS) protocol [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to the best current practices outlined in `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
* R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms.
===============
Chef JSON Key Value Description
---------------------------------------------------------------
+-------------------------------------
The following provides the key value pairs that must be contained in the
JSON file supporting Chef action.
Table A1. Chef JSON File key value description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------+
| **Field Name** | **Description** | **Type** | **Comment** |
The following table describes the JSON dictionary to post in Callback.
Table A2. JSON Dictionary to Post in Callback
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-------------------------------------------------------------+
| **Key** | **Description** | **Type** | **Comment** |
| PushJobOutput | Any output from the chef-client run that needs to be returned to ONAP. | Optional | Depends on VNF action. If empty, it must not be included. |
+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-------------------------------------------------------------+
-
Ansible JSON Key Value Description
-------------------------------------------------------------
JSON file supporting Ansible action.
Table B1. Ansible JSON File key value description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+
| **Field Name** | **Description** | **Type** | **Comment** |
Table C1 defines the required and optional fields for licenses.
Table C1. Required Fields for General Information
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
| **Field Name** | **Description** | **Data Type** | **Type** |
following fields:
Table C2. Required Fields for Entitlements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
| **Field Name** | **Description** | **Data Type** | **Type** |
be defined; each one consists of the following fields:
Table C3. Required Fields for License Keys
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------------------+---------------------------------------------------------------------------------------------------------------+-----------------+-------------+
| **Field Name** | **Description** | **Data Type** | **Type** |
which follow the guidelines.
Guidelines for Playbooks to properly integrate with APPC
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: To support concurrent requests to multiple VNF instances of same
or different type, VNF hosts and other files with VNF specific default
precedence over any defaults stored in Ansible Server.
Ansible Playbooks – Notes On Artifacts Required to Run Playbooks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Inventory hosts file: should be VNF instance specific.
------------------------------
.. toctree::
- :maxdepth: 2
+ :maxdepth: 3
:numbered:
Chapter1
VNF Requirements Release Notes
-==================
+================================
Version: 1.0.0
---------------
Code Review / vnfrqts / requirements.git / commitdiff