Status

IMPLEMENTED

Submitter
Trevor Lovett
Contributors

Hagop Bozawglanian

Proposed ReleaseDublin
JIRA Ticket(s)

Each proposal should have at least 1 JIRA ticket for tracking purposes. Please open the ticket as a Task in the VNF Requirements project.

Abstract

The VNF Requirements project denotes the "target" of the requirement (the entity that is responsible for fulfilling the requirement) in the :target: metadata field on the requirement.  In recent commits, there have been a variety of proposed targets outside of the pre-defined targets listed in the Documentation Standards.  Also with the introduction of PNF requirements and PNF CSARs the existing requirement targets are no longer sufficient.

This proposal extends and refines the set of desired targets to a fixed list.   The targets are intentionally left at a high-level to maintain their use for filtering, and enable us to keep a fixed list.  

Rationale

The metadata tag, :target: serves a couple purposes:

  1. It ensures that the scope of the VNF Requirements project stays constrained to the things the VNF must do.  This project is not intended to document what the ONAP platform should do, but rather the VNF/PNF behavior, its packaging, or the VNF provider.
  2. It provides a convenient way to filter requirements based on targets using either requirement lists in Chapter 9 or in the structured JSON version of the requirements

To meet these needs, the list of targets should be constrained to a fixed list

Proposal

The following targets are proposed


TargetWhen is it used
VNFFunctional behavior of a VNF
PNFFunctional behavior of a PNF
VNF or PNFFunction behavior to both VNFs and PNFs
{VNF|PNF|
VNF or PNF} PROVIDER		Something the provider of the VNF, PNF, or VNF/PNF must do.  This is often used to describe delivering artifacts or specific documentation that may not be part of a standard VNF package format.
VNF HEAT PACKAGEThe archive/zip file that includes  Heat templates.  The subject of the requirement my be further refined (Ex: Heat Environment File), but the metadata stay at the package level.

{VNF|PNF|VNF or PNF} CSAR PACKAGE

A requirement related to the contents of what should be in the CSAR package.  The subject of the requirement might be further refined (ex: CSAR manifest file, VNF Descriptor, etc.), but the :target: metadata would stay at the package level

{VNF|PNF|VNF or PNF} DOCUMENTATION PACKAGE

VNFs and PNFs are expected to provide human readable documentation. This may come in the form of URLs or pdfs. This documentation may vary by VNF/PNF.  The structure of the documentation is intended for human consumption and is not highly structured for machine ingestion. The human readable documentation may be provided through the VNF RFP/acquisition process.


Additionally, we recommend the tool chain be updated to restrict the list of valid values that can be used if possible.  This will prevent users from adding invalid metadata in the future.

Other Options Considered

We discussed having more fine-grained targets, but a quick review of the various subjects (text before the keyword ) used in the requirements dissuaded us from pursuing that path.  Just a sampling show the large variety of subjects used.


Here is a sample:

  • A VNF's Heat Orchestration template
  • A parameter enumerated in a
  • A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::ServiceTemplate``
  • A VNF Heat Orchestration's template's parameter
  • A VNF's Heat Orchestration Template's ``OS::Nova::Server``
  • A VNF's Heat Orchestration Template's Resource ID
  • A VNFD is a deployment template which describes a VNF in terms of
  • A shared Heat Orchestration Template resource is a resource that
  • A VNF's Heat Orchestration template's Environment File
  • If a VNF has one IPv4 OAM Management IP Address and the
  • For all GUI and command-line interfaces, the VNF
  • A VNF's Heat Orchestration Template's parameter type
  • Each architectural layer of the VNF (eg. operating system, network,
  • A VNF's Heat Orchestration Templates' Cinder Volume Module Output
  • A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
  • When the VNF's Heat Orchestration Template's Resource
  • The below table describes the data types used for LCM configuration
  • A VNF's Heat Orchestration Template's Resource
  • When the xNF sets up a HTTP or HTTPS connection to the collector, it
  • If a VNF's Heat Orchestration Template contains the property ``name``
  • A VNF's Heat Orchestration Template's Resource
  • The VNFD provided by VNF vendor may use the below described TOSCA
  • A VNF's Heat Orchestration Template's Resource
  • When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
  • A VNF's port connected to an external network
  • The VNF package Manifest file
  • When the VNF's Heat Orchestration Template's Resource
  • When the VNF's Heat Orchestration Template's Resource
  • The VNF's Heat Orchestration Template's
  • The VNF Provider
  • The VNF's Heat Orchestration Template's Resource
  • TThe xNF
  • A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
  • A VNF's Heat Orchestration Template's file extension
  • The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
  • If the PNF set up a TLS connection and mutual (two-way) authentication is
  • The VNF provider
  • A VNF's Heat Orchestration Template's Resource
  • When the VNF's Heat Orchestration Template's Resource
  • The VNF documentation
  • A VNF's Heat Orchestration Template's Resource ID that is associated with
  • When the PNF receives a Service configuration from ONAP, the PNF
  • A VNF's Heat Orchestration Template's Cinder Volume Template
  • A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
  • A VNF's Base Module
  • Login access (e.g., shell access) to the operating system layer, whether
  • The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``



  • No labels