-**4. VNF Development Requirements**
+**4. VNF Development Requirements**
====================================
a. VNF Design
inter-component latency. The VNFs should be designed with a goal of
being modular and reusable to enable using best-in-breed vendors
-Section 4.1.1 in *VNF Guidelines for Network Cloud and ONAP* describes
+Section 5.a VNF Design in *VNF Guidelines* describes
the overall guidelines for designing VNFs from VNF Components (VNFCs).
Below are more detailed requirements for composing VNFs.
provide high availability versus relying on the Network Cloud to achieve
that end.
-Section 4.1.2 in *VNF Guidelines for Network Cloud and ONAP* describes
+Section 5.a Resiliency in *VNF Guidelines* describes
the overall guidelines for designing VNFs to meet resiliency goals.
Below are more detailed resiliency requirements for VNFs.
will be applicable and are outside the scope of these general
requirements.
-Section 4.1.3 in *VNF Guidelines for Network Cloud and ONAP* outlines
+Section 5.a Security in *VNF Guidelines* outlines
the five broad security areas for VNFs that are detailed in the
following sections:
VNF Modularity Overview
-----------------------
-OpenECOMP supports a modular Heat design pattern, referred to as *VNF
+ONAP supports a modular Heat design pattern, referred to as *VNF
Modularity.* With this approach, a single VNF may be composed from one
or more Heat templates, each of which represents some subset of the
overall VNF. These component parts are referred to as “\ *VNF
3. Independent Cinder Volume Modules
-The OpenECOMP Heat template naming convention must be followed (Section
-2.1). The naming convention identifies the module type.
+The ONAP Heat template naming convention must be followed (Section
+5.b Filenames). The naming convention identifies the module type.
A VNF must be composed of one “base” VNF module (also called a base
module) and zero to many “incremental” or “add on” VNF modules. The base
A module can be thought of as equivalent to a Heat template, where a
Heat template is composed of a YAML file and an environment file (also
referred to as an ENV file). A given YAML file must have a corresponding
-environment file; OpenECOMP requires it.
+environment file; ONAP requires it.
A Heat template is used to create or deploy a Heat stack. Therefore, a
module is also equivalent to a Heat Stack.
-OpenECOMP supports the concept of an optional, independent deployment of
+ONAP supports the concept of an optional, independent deployment of
a Cinder volume via separate Heat templates. This allows the volume to
persist after VNF deletion so that the volume can be reused on another
instance (e.g. during a failover activity).
Design Pattern: VNF Modularity
------------------------------
-OpenECOMP supports the concept of *VNF Modularity*. With this approach,
+ONAP supports the concept of *VNF Modularity*. With this approach,
a single VNF may be composed from one or more Heat templates, each of
which represents some subset of the overall VNF. These component parts
are referred to as “\ *VNF Modules*\ ”. During orchestration, these
3. Independent Cinder Volume Modules
-The OpenECOMP Heat template naming convention must be followed (Section
-2.1). The naming convention identifies the module type.
+The ONAP Heat template naming convention must be followed (Section
+5.b Filenames). The naming convention identifies the module type.
A VNF must be composed of one “base” VNF module (also called a base
module) and zero to many “incremental” or “add on” VNF modules. The base
A module can be thought of as equivalent to a Heat template, where a
Heat template is composed of a YAML file and an environment file. A
-given YAML file must have a corresponding environment file; OpenECOMP
+given YAML file must have a corresponding environment file; ONAP
requires it. A Heat template is used to create or deploy a Heat stack.
Therefore, a module is also equivalent to a Heat Stack.
However, there are cases where a module maybe composed of more than one
Heat stack and/or more than one YAML file.
-As discussed in Section 2.5, Independent Volume Templates, each VNF
+As discussed in Section 5.b, Independent Volume Templates, each VNF
Module may have an associated Volume template.
- When a volume template is utilized, it must correspond 1:1 with
Any shared resource defined in the base module template and used across
the entire VNF (e.g., private networks, server groups), must be exposed
to the incremental or add-on modules by declaring their resource UUIDs
-as Heat outputs (i.e., OpenECOMP Base Template Output Parameter in the
+as Heat outputs (i.e., ONAP Base Template Output Parameter in the
output section of the Heat template). Those outputs will be provided by
-OpenECOMP as input parameter values to all add-on module Heat templates
+ONAP as input parameter values to all add-on module Heat templates
in the VNF that have declared the parameter in the template.
*Note:* A Cinder volume is *not* considered a shared resource. A volume
groups, security groups)
b. Must expose all shared resources (by UUID) as “outputs” in its
- associated Heat template (i.e., OpenECOMP Base Template Output
+ associated Heat template (i.e., ONAP Base Template Output
Parameters)
c. May include initial set of VMs
growth units)
3. Each VNF Module (base or add-on) may have (optional) an associated
- Volume template (*see Section 2.5*)
+ Volume template (*see Section 5.b, Independent Volume Templates*)
a. Volume templates should correspond 1:1 with Module (base or
add-on) templates
----------------------
Scaling of a VNF may be manually driven to add new capacity (**static
-scaling**) or it may be driven in near real-time by the OpenECOMP
+scaling**) or it may be driven in near real-time by the ONAP
controllers based on a real-time need **(dynamic scaling).**
With VNF Modularity, the recommended approach for scaling is to provide
provide the NCSP with an install package consistent with the default OS
package manager (e.g. aptitude for Ubuntu, yum for Redhat/CentOS).
-Section 4.1.4 in *VNF Guidelines for Network Cloud and ONAP* describes
+Section 5.a DevOps in *VNF Guidelines* describes
the DevOps guidelines for VNFs.
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+
-**5. VNF Modeling Requirements**
+**5. VNF Modeling Requirements**
=====================================
a. TOSCA YAML
General Guidelines
------------------
-The Heat templates supported by OpenECOMP must follow the requirements
+The Heat templates supported by ONAP must follow the requirements
enumerated in this section.
Filenames
---------
-In order to enable OpenECOMP to understand the relationship between Heat
+In order to enable ONAP to understand the relationship between Heat
files, the following Heat file naming convention must be followed.
- The file name for the base module Heat template must include “base”
above base module Heat template name)
- A YAML file must have a corresponding ENV file, even if the ENV file
- enumerates no parameters. It is an OpenECOMP requirement.
+ enumerates no parameters. It is an ONAP requirement.
Valid YAML Format
------------------
Parameter Categories
~~~~~~~~~~~~~~~~~~~~
-OpenECOMP requires the Heat template parameters to follow certain
-requirements in order for it to be orchestrated or deployed. OpenECOMP
+ONAP requires the Heat template parameters to follow certain
+requirements in order for it to be orchestrated or deployed. ONAP
classifies parameters into eight broad categories.
-- **OpenECOMP Metadata**: OpenECOMP mandatory and optional metadata
+- **ONAP Metadata**: ONAP mandatory and optional metadata
parameters in the resource *OS::Nova::Server*.
- - OpenECOMP dictates the naming convention of these Metadata
- parameters and must be adhered to (See Section 4.4).
+ - ONAP dictates the naming convention of these Metadata
+ parameters and must be adhered to (See Section 5.b, Independent Volume Templates).
- Metadata parameters must not be enumerated in the environment
file.
- - The OpenECOMP Metadata are generated and/or assigned by OpenECOMP
- and supplied to the Heat by OpenECOMP at orchestration time.
+ - The ONAP Metadata are generated and/or assigned by ONAP
+ and supplied to the Heat by ONAP at orchestration time.
-- **OpenECOMP Orchestration Parameters**: The data associated with
+- **ONAP Orchestration Parameters**: The data associated with
these parameters are VNF instance specific.
- - OpenECOMP enforces the naming convention of these parameters and
- must be adhered to (See Section 4).
+ - ONAP enforces the naming convention of these parameters and
+ must be adhered to (See Parameter Naming Convention).
- These parameters must not be enumerated in the environment file.
- - The OpenECOMP Orchestration Parameters are generated and/or
- assigned by OpenECOMP and supplied to the Heat by OpenECOMP at
+ - The ONAP Orchestration Parameters are generated and/or
+ assigned by ONAP and supplied to the Heat by ONAP at
orchestration time.
- **VNF Orchestration Parameters**: The data associated with these
parameters are VNF instance specific.
- - While OpenECOMP does not enforce a naming convention, the
+ - While ONAP does not enforce a naming convention, the
parameter names should include {vm-type} and {network-role} when
- appropriate. (See Section 4)
+ appropriate. (See Parameter Naming Convention)
- These parameters must not be enumerated in the environment file.
- The VNF Orchestration Parameters Heat are generated and/or
- assigned by OpenECOMP and supplied to the Heat by OpenECOMP at
+ assigned by ONAP and supplied to the Heat by ONAP at
orchestration time.
-- **OpenECOMP Orchestration Constants**: The data associated with these
+- **ONAP Orchestration Constants**: The data associated with these
parameters must be constant across all VNF instances.
- - OpenECOMP enforces the naming convention of these parameters and
- must be adhered to (See Section 4).
+ - ONAP enforces the naming convention of these parameters and
+ must be adhered to (See Parameter Naming Convention).
- These parameters must be enumerated in the environment file.
- **VNF Orchestration Constants**: The data associated with these
parameters must be constant across all VNF instances.
- - While OpenECOMP does not enforce a naming convention, the
+ - While ONAP does not enforce a naming convention, the
parameter names should include {vm-type} and {network-role} when
- appropriate. (See Section 4)
+ appropriate. (See Parameter Naming Convention)
- These parameters must be enumerated in the environment file.
-- **OpenECOMP Base Template Output Parameters** (also referred to as
+- **ONAP Base Template Output Parameters** (also referred to as
Base Template Output Parameters): The output section of the base
template allows for specifying output parameters available to add-on
modules once the base template has been instantiated. The parameter
parameter defined in the add-on module(s) where the parameter is
used.
-- **OpenECOMP Volume Template Output Parameters** (also referred to as
+- **ONAP Volume Template Output Parameters** (also referred to as
Volume Template Output Parameters): The output section of the volume
template allows for specifying output parameters available to the
corresponding Heat template (base or add-on) once the volume template
the volume must be identical to the parameter defined in the base or
add-on module.
-- **OpenECOMP Predefined Output Parameters** (also referred to as
- Predefined Output Parameters): OpenECOMP will look for a small set of
+- **ONAP Predefined Output Parameters** (also referred to as
+ Predefined Output Parameters): ONAP will look for a small set of
pre-defined Heat output parameters to capture resource attributes for
- inventory in OpenECOMP. These parameters are specified in Section
- 4.6.
+ inventory in ONAP. These parameters are specified in Section
+ 5.b Resource Property: name.
The table below summarizes the Parameter Types. If the user is
orchestrating a manual spin up of Heat (e.g. OpenStack command line),
-the parameter values that OpenECOMP supplies must be enumerated in the
-environment file. However, when the Heat is to be loaded into OpenECOMP
-for orchestration, the parameters that OpenECOMP supplies must be
+the parameter values that ONAP supplies must be enumerated in the
+environment file. However, when the Heat is to be loaded into ONAP
+for orchestration, the parameters that ONAP supplies must be
deleted or marked with a comment (i.e., a “#” placed at the beginning of
a line).
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
| Parameter Type | Naming Convention | Parameter Value Source |
+===============================================+=====================+=================================================================================+
-| OpenECOMP Metadata | Explicit | OpenECOMP |
+| ONAP Metadata | Explicit | ONAP |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| OpenECOMP Orchestration Parameters | Explicit | OpenECOMP |
+| ONAP Orchestration Parameters | Explicit | ONAP |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| VNF Orchestration Parameters | Recommended | OpenECOMP |
+| VNF Orchestration Parameters | Recommended | ONAP |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| OpenECOMP Orchestration Constants | Explicit | Environment File |
+| ONAP Orchestration Constants | Explicit | Environment File |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
| VNF Orchestration Constants | Recommended | Environment File |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| OpenECOMP Base Template Output Parameters | Recommended | Heat Output Statement for base, OpenECOMP supplied to add-on modules |
+| ONAP Base Template Output Parameters | Recommended | Heat Output Statement for base, ONAP supplied to add-on modules |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| OpenECOMP Volume Template Output Parameters | Recommended | Heat Output Statement for volume, OpeneECOMP supplies to corresponding module |
+| ONAP Volume Template Output Parameters | Recommended | Heat Output Statement for volume, OpeneECOMP supplies to corresponding module |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
-| OpenECOMP Predefined Output Parameters | Explicit | Heat Output Statement |
+| ONAP Predefined Output Parameters | Explicit | Heat Output Statement |
+-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
Table 1 Parameter Types
Parameter Specifications
~~~~~~~~~~~~~~~~~~~~~~~~
-OpenECOMP METADATA Parameters
+ONAP METADATA Parameters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-OpenECOMP defines four “metadata” parameters: vnf\_id, vf\_module\_id,
+ONAP defines four “metadata” parameters: vnf\_id, vf\_module\_id,
vnf\_name, vf\_module\_name. These parameters must not define any
constraints in the Heat template, including length restrictions, ranges,
default value and/or allowed patterns.
-OpenECOMP Base Template & Volume Template Output Parameters
+ONAP Base Template & Volume Template Output Parameters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The base template and volume template output parameters are defined as
the Heat must be identical to the parameter name defined in the Heat
that is to receive the value.
-OpenECOMP Predefined Output Parameters
+ONAP Predefined Output Parameters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These parameters must not define any constraints in the Heat template,
including length restrictions, ranges, default value and/or allowed
patterns.
-OpenECOMP Orchestration Parameters, VNF Orchestration Parameters, OpenECOMP Orchestration Constants, VNF Orchestration Constants
+ONAP Orchestration Parameters, VNF Orchestration Parameters, ONAP Orchestration Constants, VNF Orchestration Constants
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-OpenECOMP Orchestration Parameters, VNF Orchestration Parameters,
-OpenECOMP Orchestration Constants, VNF Orchestration Constants must
+ONAP Orchestration Parameters, VNF Orchestration Parameters,
+ONAP Orchestration Constants, VNF Orchestration Constants must
adhere to the following:
- All parameters should be clearly documented in the template,
A YAML file must have a corresponding environment file (also referred to
as ENV file), even if the environment file defines no parameters. It is
-an OpenECOMP requirement.
+an ONAP requirement.
-The environment file must contain parameter values for the OpenECOMP
+The environment file must contain parameter values for the ONAP
Orchestration Constants and VNF Orchestration Constants. These
parameters are identical across all instances of a VNF type, and
-expected to change infrequently. The OpenECOMP Orchestration Constants
+expected to change infrequently. The ONAP Orchestration Constants
are associated with OS::Nova::Server image and flavor properties (See
-Section 4.3). Examples of VNF Orchestration Constants are the networking
+Section 5.b Resource: OS::Nova::Server – Parameters). Examples of VNF Orchestration Constants are the networking
parameters associated with an internal network (e.g. private IP ranges)
and Cinder volume sizes.
The environment file must not contain parameter values for parameters
-that are instance specific (OpenECOMP Orchestration Parameters, VNF
+that are instance specific (ONAP Orchestration Parameters, VNF
Orchestration Parameters). These parameters are supplied to the Heat by
-OpenECOMP at orchestration time. The parameters are generated and/or
-assigned by OpenECOMP at orchestration time
+ONAP at orchestration time. The parameters are generated and/or
+assigned by ONAP at orchestration time
Independent Volume Templates
----------------------------
-OpenECOMP supports independent deployment of a Cinder volume via
+ONAP supports independent deployment of a Cinder volume via
separate Heat templates. This allows the volume to persist after VNF
deletion so that they can be reused on another instance (e.g. during a
failover activity).
the Incremental/Base module.
- The volume template must define “outputs” for each Cinder volume
- resource universally unique identifier (UUID) (i.e. OpenECOMP
+ resource universally unique identifier (UUID) (i.e. ONAP
Volume Template Output Parameters).
- The VNF Incremental Module or Base Module must define input
- parameters that match each Volume output parameter (i.e., OpenECOMP
+ parameters that match each Volume output parameter (i.e., ONAP
Volume Template Output Parameters).
- - OpenECOMP will supply the volume template outputs automatically to
+ - ONAP will supply the volume template outputs automatically to
the bases/incremental template input parameters.
- Volume modules may utilize nested Heat templates.
**Example (volume template):**
In this example, the {vm-type} has been left as a variable.
- {vm-type} is described in section 4.1. If the VM was a load
+ {vm-type} is described in section 5.b {vm-type}. If the VM was a load
balancer, the {vm-type} could be defined as “lb”
.. code-block:: python
Nested Heat Templates
---------------------
-OpenECOMP supports nested Heat templates per the OpenStack
+ONAP supports nested Heat templates per the OpenStack
specifications. Nested templates may be suitable for larger VNFs that
contain many repeated instances of the same VM type(s). A common usage
pattern is to create a nested template for each VM type along with its
may then reference these component templates either statically (by
repeated definition) or dynamically (via *OS::Heat::ResourceGroup*).
-Nested template support in OpenECOMP is subject to the following
+Nested template support in ONAP is subject to the following
limitations:
-- Heat templates for OpenECOMP must only have one level of nesting.
- OpenECOMP only supports one level of nesting.
+- Heat templates for ONAP must only have one level of nesting.
+ ONAP only supports one level of nesting.
- Nested templates must be referenced by file name in the master
template
- Nested templates must have unique file names within the scope of the
VNF
-- OpenECOMP does not support a directory hierarchy for nested
+- ONAP does not support a directory hierarchy for nested
templates. All templates must be in a single, flat directory (per
VNF)
- External networks must be orchestrated separately, so they can be
shared by multiple VNFs and managed independently. When the external
network is created, it must be assigned a unique {network-role} (See
- section 4.2).
+ section 5.b {network-role}).
- External networks must be passed into the VNF template as parameters,
including the network-id (i.e. the neutron network UUID) and optional
- VNFs may use DHCP assigned IP addresses or assign fixed IPs when
attaching VMs to an external network.
-- OpenECOMP enforces a naming convention for parameters associated with
+- ONAP enforces a naming convention for parameters associated with
external networks.
- Parameter values associated with an external network will be
- generated and/or assigned by OpenECOMP at orchestration time.
+ generated and/or assigned by ONAP at orchestration time.
- Parameter values associated with an external network must not be
enumerated in the environment file.
- In the modular approach, internal networks must be created in the
Base Module template, with their resource IDs exposed as outputs
- (i.e., OpenECOMP Base Template Output Parameters) for use by all
+ (i.e., ONAP Base Template Output Parameters) for use by all
add-on module templates. When the external network is created, it
- must be assigned a unique {network-role} (See section 4.2).
+ must be assigned a unique {network-role} (See section 5.b {network-role}).
- VNFs may use DHCP assigned IP addresses or assign fixed IPs when
attaching VMs to an internal network.
-- OpenECOMP does not enforce a naming convention for parameters for
+- ONAP does not enforce a naming convention for parameters for
internal network, however, a naming convention is provided that
should be followed.
- Parameter values associated with an internal network must either be
- passed as output parameter from the base template (i.e., OpenECOMP
+ passed as output parameter from the base template (i.e., ONAP
Base Template Output Parameters) into the add-on modules or be
enumerated in the environment file.
- VMs connect to internal networks using either fixed (e.g. statically
assigned) IP addresses or DHCP assigned IP addresses.
-- Neutron Floating IPs must not be used. OpenECOMP does not support
+- Neutron Floating IPs must not be used. ONAP does not support
Neutron Floating IPs.
-- OpenECOMP supports the OS::Neutron::Port property
- “allowed\_address\_pairs.” See Section 4.4.3.
+- ONAP supports the OS::Neutron::Port property
+ “allowed\_address\_pairs.” See Section 5.b Property: allowed_address_pairs.
Parameter Naming Convention
---------------------------
template in naming parameters, for each VM type in the VNF with the
following exceptions:
-- The four OpenECOMP Metadata parameters must not be prefixed with a
+- The four ONAP Metadata parameters must not be prefixed with a
common {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
*vf\_module\_id*, *vf\_module\_name*.
identifier.
- {vm-type} must be unique to the VNF. It does not have to be globally
- unique across all VNFs that OpenECOMP supports.
+ unique across all VNFs that ONAP supports.
{network-role}
--------------
“External” networks must be passed into the VNF template as parameters.
Examples include the network-id (i.e. the neutron network UUID) and
-optional subnet ID. See section 4.4.3.
+optional subnet ID. See section 5.b Property: network & subnet.
Any parameter that is associated with an external network must include
the {network-role} as part of the parameter name.
---------------------------------------
The following OS::Nova::Server Resource Property Parameter Names must
-follow the OpenECOMP parameter Naming Convention. All the parameters
-associated with OS::Nova::Server are classified as OpenECOMP
+follow the ONAP parameter Naming Convention. All the parameters
+associated with OS::Nova::Server are classified as ONAP
Orchestration Parameters.
+----------------------+-----------------------------------------+------------------+
| OS::Nova::Server |
+======================+=========================================+==================+
-| Property | OpenECOMP Parameter Naming Convention | Parameter Type |
+| Property | ONAP Parameter Naming Convention | Parameter Type |
+----------------------+-----------------------------------------+------------------+
| image | {*vm-type*}\_image\_name | string |
+----------------------+-----------------------------------------+------------------+
Property: image
~~~~~~~~~~~~~~~
-Image is an OpenECOMP Orchestration Constant parameter. The image must
+Image is an ONAP Orchestration Constant parameter. The image must
be referenced by the Network Cloud Service Provider (NCSP) image name,
with the parameter enumerated in the Heat environment file.
Property: flavor
~~~~~~~~~~~~~~~~
-Flavor is an OpenECOMP Orchestration Constant parameter. The flavors
+Flavor is an ONAP Orchestration Constant parameter. The flavors
must be referenced by the Network Cloud Service Provider (NCSP) flavor
name, with the parameter enumerated in the Heat environment file.
~~~~~~~~~~~~~~
Name is an OpenEOMP Orchestration parameter; the value is provided to
-the Heat template by OpenECOMP.
+the Heat template by ONAP.
VM names (hostnames) for assignment to VM instances must be passed to
Heat templates either as
Property: availability\_zone
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Availability\_zone is an OpenECOMP Orchestration parameter; the value is
-provided to the Heat template by OpenECOMP.
+Availability\_zone is an ONAP Orchestration parameter; the value is
+provided to the Heat template by ONAP.
Availability zones must be passed as individual numbered parameters (not
as arrays) so that VNFs with multi-availability zone requirements can
Resource: OS::Nova::Server - Metadata
-------------------------------------
-This section describes the OpenECOMP Metadata parameters.
+This section describes the ONAP Metadata parameters.
-OpenECOMP Heat templates must include the following three parameters
+ONAP Heat templates must include the following three parameters
that are used as metadata under the resource OS::Nova:Server: vnf\_id,
vf\_module\_id, vnf\_name
-OpenECOMP Heat templates may include the following parameter that is
+ONAP Heat templates may include the following parameter that is
used as metadata under the resource OS::Nova:Server: vf\_module\_name.
-These parameters are all classified as OpenECOMP Metadata.
+These parameters are all classified as ONAP Metadata.
+---------------------------+------------------+----------------------+
| Metadata Parameter Name | Parameter Type | Mandatory/Optional |
| vf\_module\_name | string | optional |
+---------------------------+------------------+----------------------+
- Table 3 OpenECOMP Metadata
+ Table 3 ONAP Metadata
Required Metadata Elements
~~~~~~~~~~~~~~~~~~~~~~~~~~
The vnf\_id, vf\_module\_id, and vnf\_name metadata elements are
required (must) for *OS::Nova::Server* resources. The metadata
-parameters will be used by OpenECOMP to associate the servers with the
+parameters will be used by ONAP to associate the servers with the
VNF instance.
- vnf\_id
- - *“vnf\_id”* parameter value will be supplied by OpenECOMP.
- OpenECOMP generates the UUID that is the vnf\_id and supplies it
+ - *“vnf\_id”* parameter value will be supplied by ONAP.
+ ONAP generates the UUID that is the vnf\_id and supplies it
to the Heat at orchestration time.
- vf\_module\_id
- “\ *vf\_module\_id”* parameter value will be supplied by
- OpenECOMP. OpenECOMP generates the UUID that is the vf\_module\_id
+ ONAP. ONAP generates the UUID that is the vf\_module\_id
and supplies it to the Heat at orchestration time.
- vnf\_name
- “\ *vnf\_name”* parameter value will be generated and/or assigned
- by OpenECOMP and supplied to the Heat by OpenECOMP at
+ by ONAP and supplied to the Heat by ONAP at
orchestration time.
Optional Metadata Elements
process.
- *“vf\_module\_name”* parameter value, when used, will be supplied
- by OpenECOMP to the Heat at orchestration time. The parameter will
- be generated and/or assigned by OpenECOMP and supplied to the Heat
- by OpenECOMP at orchestration time.
+ by ONAP to the Heat at orchestration time. The parameter will
+ be generated and/or assigned by ONAP and supplied to the Heat
+ by ONAP at orchestration time.
*Example*
----------------------------------------
The following four OS::Neutron::Port Resource Property Parameters must
-adhere to the OpenECOMP parameter naming convention.
+adhere to the ONAP parameter naming convention.
- network
{network-role} in its name.
When the parameter references an external network, the parameter is an
-OpenECOMP Orchestration Parameter. The parameter value must be supplied
-by OpenECOMP. The parameters must adhere to the OpenECOMP parameter
+ONAP Orchestration Parameter. The parameter value must be supplied
+by ONAP. The parameters must adhere to the ONAP parameter
naming convention.
+---------------------------+-----------------------------------------------+------------------+
When the parameter references an internal network, the parameter is a
VNF Orchestration Parameters. The parameter value(s) must be supplied
-either via an output statement(s) in the base module (i.e., OpenECOMP
+either via an output statement(s) in the base module (i.e., ONAP
Base Template Output Parameters) or be enumerated in the environment
file. The parameters must adhere to the following parameter naming
convention.
“Floating IP” resources, for which OpenStack manages a pool of public IP
addresses that are mapped to specific VM ports. In that case, the
individual VMs are not even aware of the public IPs, and all assignment
-of public IPs to VMs is via OpenStack commands. OpenECOMP does not
+of public IPs to VMs is via OpenStack commands. ONAP does not
support Neutron-style Floating IPs.
Both IPv4 and IPv6 “allowed\_address\_pairs” addresses are supported.
-----------------------
The parameter naming standard for the resource OS::Nova::Server has been
-defined in Section 4.3.3. This section describes how the name property
+defined in Section 5.b Resource: OS::Nova::Server – Parameters. This section describes how the name property
of all other resources must be defined.
Heat templates must use the Heat “str\_replace” function in conjunction
-with the OpenECOMP supplied metadata parameter *vnf\_name* or
+with the ONAP supplied metadata parameter *vnf\_name* or
*vnf\_module\_id* to generate a unique name for each VNF instance. This
prevents the use of unique parameters values for resource “name”
properties to be enumerated in a per instance environment file.
Output Parameters
-----------------
-OpenECOMP defines three type of Output Parameters.
+ONAP defines three type of Output Parameters.
Base Template Output Parameters:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Predefined Output Parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-OpenECOMP currently defines one predefined output parameter.
+ONAP currently defines one predefined output parameter.
OAM Management IP Addresses
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Many VNFs will have a management interface for application controllers
to interact with and configure the VNF. Typically, this will be via a
specific VM that performs a VNF administration function. The IP address
-of this interface must be captured and inventoried by OpenECOMP. This
+of this interface must be captured and inventoried by ONAP. This
might be a VIP if the VNF contains an HA pair of management VMs, or may
be a single IP address assigned to one VM.
definitions, any HTTP-based nested configurations, or any HTTP-based
environment files.
-- During orchestration, OpenECOMP *should not* retrieve any such
+- During orchestration, ONAP *should not* retrieve any such
resources from external/untrusted/unknown sources.
- VNF images should not contain such references in user-data or other
Support for Heat Files is subject to the following limitations:
- The ‘get\_files’ targets must be referenced in Heat templates by file
- name, and the corresponding files should be delivered to OpenECOMP
+ name, and the corresponding files should be delivered to ONAP
along with the Heat templates.
- URL-based file retrieval must not be used; it is not supported.
- The included files must have unique file names within the scope of
the VNF.
-- OpenECOMP does not support a directory hierarchy for included files.
+- ONAP does not support a directory hierarchy for included files.
- All files must be in a single, flat directory per VNF.
related *OS::Neutron::Port* resources via a single resource in a master
template.
-*ResourceGroup* may be used in OpenECOMP to simplify the structure of a
+*ResourceGroup* may be used in ONAP to simplify the structure of a
Heat template that creates multiple instances of the same VM type.
However, there are important caveats to be aware of.
OpenStack Tenant. As a result, they are usable only by the User that
created the keypair. This causes a problem when a Heat template attempts
to reference a keypair by name, because it assumes that the keypair was
-previously created by a specific OpenECOMP user ID.
+previously created by a specific ONAP user ID.
When a keypair is assigned to a server, the SSH public-key is
provisioned on the VMs at instantiation time. They keypair itself is not
provisioned in the new VM. However, this recommended approach also makes
sure that a known public key is supplied (instead of having OpenStack
generate a public/private pair to be saved and tracked outside of
-OpenECOMP). It also removes any access/ownership issues over the created
+ONAP). It also removes any access/ownership issues over the created
keypair.
The public keys may be enumerated as a VNF Orchestration Constant in the
environment file (since it is public, it is not a secret key), or passed
-at run-time as an instance-specific parameters. OpenECOMP will never
+at run-time as an instance-specific parameters. ONAP will never
automatically assign a public/private key pair.
*Example (create keypair with an existing ssh public-key for {vm-type}
-**7. ONAP Management Requirements**
+**7. ONAP Management Requirements**
=====================================
a. Service Design
| | | | |
| | - Scaling/growth VM specifications. | | |
| | | | |
-| | Note: Must comply with the *VNF Heat Template Requirements for ONAP*. | | |
+| | Note: Must comply with the *Heat requirements in 5.b*. | | |
+--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
| | The VNF Vendor must provide the binaries and images needed to instantiate the VNF (VNF and VNFC images). | Must | 10180 |
+--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
**Table 6. VNF Configuration via Chef**
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| **Principle** | **Description** | **Type** | **ID #** |
-+============================+===============================================================================================================================================================================================================================================================================================================+============+============+
-| Chef Server Requirements | ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [3]_: | Must | 12310 |
-| | | | |
-| | - **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF. If this choice is used then it is required that the VNF Vendor provide all relevant cookbooks to ONAP to be loaded on the Chef Server. | | |
-| | | | |
-| | - **Chef Server hosted in Tenant Space**: The Chef Server may also be hosted external to ONAP in tenant space. Same guidelines as ONAP Chef Server apply. In addition, the owner is required to provide appropriate credentials to ONAP in order to interact with the Chef Server. | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Chef Client | It is required that as part of the installation process, the chef-client on the VNF be preloaded with validator keys and configuration to register with the designated Chef Server. | Must | 12320 |
-| | | | |
-| Requirements | | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | All the endpoints (VMs) of a VNF that contain chef-clients are required to have routable FQDNs which are used to register with the Chef Server. As part of invoking VNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF, if required. | Must | 12330 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that each VNF expose a single endpoint that is responsible for all functionality. | May | 12331 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that the VNF be installed with | Must | 12340 |
-| | | | |
-| | - Chef-Client >= 12.0 | | |
-| | | | |
-| | - Chef push jobs client >= 2.0 | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Chef Roles/ | Each VNF Vendor is required to make available for loading on appropriate Chef Server, all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP. | Must | 12350 |
-| | | | |
-| Requirements | | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | For each supported VNF action, the VNF Vendor is required to provide a run list of roles/cookbooks/recipes that will perform the desired VNF action in its entirety as specified by ONAP (see Section 3.5 for list of VNF actions and requirements), when triggered by a chef-client run list in JSON file. | Must | 12360 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Roles/cookbooks/recipes invoked for a VNF action must not contain any instance specific parameters for the VNF. Instead they must accept all necessary instance specific data from the environment or node object attributes. | Must | 12370 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that all configurable parameters in the roles, cookbooks and recipes that can be set by ONAP, over-ride any default values. | Must | 12380 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that when executing a VNF action, if the chef-client run encounters any critical errors/failures, it update status on the Chef Server appropriately (e.g., via a fail or raise an exception). | Must | 12390 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | If the VNF action requires the output of a chef-client run be made available (e.g., get running configuration), an attribute, defined as node[‘PushJobOutput’] must be populated with the desired output on all nodes in the push job that execute chef-client run. | Must | 12400 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that, for actions that change state of the VNF (e.g., configure), the Vendor design appropriate cookbooks that can automatically ‘rollback’ to the original state in case of any errors. | Must | 12410 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that any chef-client run associated with a VNF action support callback URLs to return information to ONAP upon completion of the chef-client run. | Should | 12420 |
-| | | | |
-| | - As part of the push job, ONAP will provide two parameters in the environment of the push job JSON object: | | |
-| | | | |
-| | - ‘RequestId’ a unique Id to be used to identify the request, | | |
-| | | | |
-| | - ‘CallbackUrl’, the URL to post response back. | | |
-| | | | |
-| | - If the CallbackUrl field is empty or missing in the push job, then the chef-client run need not post the results back via callback. | | |
-| | | | |
-| | - If the chef-client run list includes a cookbook/recipe that is callback capable, it is required to, upon completion of the chef-client run, POST back on the callback URL, a JSON object as described in Table A2. | | |
-| | | | |
-| | - Failure to POST on the Callback Url should not be considered a critical error. That is, if the chef-client successfully completes the VNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not. | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| **Principle** | **Description** | **Type** | **ID #** |
++============================+===================================================================================================================================================================================================================================================================================================================================================+============+============+
+| Chef Server Requirements | ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [3]_: | Must | 12310 |
+| | | | |
+| | - **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF. If this choice is used then it is required that the VNF Vendor provide all relevant cookbooks to ONAP to be loaded on the Chef Server. | | |
+| | | | |
+| | - **Chef Server hosted in Tenant Space**: The Chef Server may also be hosted external to ONAP in tenant space. Same guidelines as ONAP Chef Server apply. In addition, the owner is required to provide appropriate credentials to ONAP in order to interact with the Chef Server. | | |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| Chef Client | It is required that as part of the installation process, the chef-client on the VNF be preloaded with validator keys and configuration to register with the designated Chef Server. | Must | 12320 |
+| | | | |
+| Requirements | | | |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | All the endpoints (VMs) of a VNF that contain chef-clients are required to have routable FQDNs which are used to register with the Chef Server. As part of invoking VNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF, if required. | Must | 12330 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is recommended that each VNF expose a single endpoint that is responsible for all functionality. | May | 12331 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is required that the VNF be installed with | Must | 12340 |
+| | | | |
+| | - Chef-Client >= 12.0 | | |
+| | | | |
+| | - Chef push jobs client >= 2.0 | | |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| Chef Roles/ | Each VNF Vendor is required to make available for loading on appropriate Chef Server, all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP. | Must | 12350 |
+| | | | |
+| Requirements | | | |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | For each supported VNF action, the VNF Vendor is required to provide a run list of roles/cookbooks/recipes that will perform the desired VNF action in its entirety as specified by ONAP (see Section 8.c, ONAP Controller APIs and Behavior, for list of VNF actions and requirements), when triggered by a chef-client run list in JSON file. | Must | 12360 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | Roles/cookbooks/recipes invoked for a VNF action must not contain any instance specific parameters for the VNF. Instead they must accept all necessary instance specific data from the environment or node object attributes. | Must | 12370 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is required that all configurable parameters in the roles, cookbooks and recipes that can be set by ONAP, over-ride any default values. | Must | 12380 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is required that when executing a VNF action, if the chef-client run encounters any critical errors/failures, it update status on the Chef Server appropriately (e.g., via a fail or raise an exception). | Must | 12390 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | If the VNF action requires the output of a chef-client run be made available (e.g., get running configuration), an attribute, defined as node[‘PushJobOutput’] must be populated with the desired output on all nodes in the push job that execute chef-client run. | Must | 12400 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is recommended that, for actions that change state of the VNF (e.g., configure), the Vendor design appropriate cookbooks that can automatically ‘rollback’ to the original state in case of any errors. | Must | 12410 |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+| | It is recommended that any chef-client run associated with a VNF action support callback URLs to return information to ONAP upon completion of the chef-client run. | Should | 12420 |
+| | | | |
+| | - As part of the push job, ONAP will provide two parameters in the environment of the push job JSON object: | | |
+| | | | |
+| | - ‘RequestId’ a unique Id to be used to identify the request, | | |
+| | | | |
+| | - ‘CallbackUrl’, the URL to post response back. | | |
+| | | | |
+| | - If the CallbackUrl field is empty or missing in the push job, then the chef-client run need not post the results back via callback. | | |
+| | | | |
+| | - If the chef-client run list includes a cookbook/recipe that is callback capable, it is required to, upon completion of the chef-client run, POST back on the callback URL, a JSON object as described in Table A2. | | |
+| | | | |
+| | - Failure to POST on the Callback Url should not be considered a critical error. That is, if the chef-client successfully completes the VNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not. | | |
++----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
ONAP Chef API Usage
~~~~~~~~~~~~~~~~~~~
| | | |
| ConfigModify | | |
+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Health | Executes a VNF health check and returns the result. A health check is VNF-specific. | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 3.2. |
+| Health | Executes a VNF health check and returns the result. A health check is VNF-specific. | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 8.c VNF REST APIs. |
| | | |
| Check | | |
+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| | | |
| | NodeList must list sample FQDNs that are required to conduct a chef-client run for this VNF Action. | |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Health | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 3.2. | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 3.2. |
+| Health | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 8.c VNF REST APIs. | The ONAP health check interface is defined over REST and requires the target VNF to expose a standardized HTTP(S) interface for that purpose. See Section 8.c VNF REST APIs. |
| | | |
| Check | | |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+----------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
| | The VNF must respond with content encoded in JSON, as described in the RESTCONF specification. This way the encoding of a synchronous communication will be consistent with Avro. | Must | 13070 |
+----------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | ONAP may request the VNF to deliver the current data for any of the record types defined in Section 4.2 below. The VNF must respond by returning the requested record, populated with the current field values. (Currently the defined record types include the common header record, technology independent records such as Fault, Heartbeat, State Change, Syslog, and technology specific records such as Mobile Flow, Signaling and Voice Quality records. Additional record types will be added in the future as they are standardized and become available.) | Must | 13080 |
+| | ONAP may request the VNF to deliver the current data for any of the record types defined in Section 8.d Data Model for Event Records below. The VNF must respond by returning the requested record, populated with the current field values. (Currently the defined record types include the common header record, technology independent records such as Fault, Heartbeat, State Change, Syslog, and technology specific records such as Mobile Flow, Signaling and Voice Quality records. Additional record types will be added in the future as they are standardized and become available.) | Must | 13080 |
+----------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
| | ONAP may request the VNF to deliver granular data on device or subsystem status or performance, referencing the YANG configuration model for the VNF. The VNF must respond by returning the requested data elements. | Must | 13090 |
+----------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
Code Review / vnfrqts / requirements.git / commitdiff