Refine and Standardize Requirement Target Metadata
Status | Implemented |
---|---|
Submitter | @Trevor Lovett |
Contributors | @Hagop Bozawglanian |
Proposed Release | Dublin |
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:
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.
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
Target | When is it used |
---|---|
VNF | Functional behavior of a VNF |
PNF | Functional behavior of a PNF |
VNF or PNF | Function behavior to both VNFs and PNFs |
{VNF|PNF| | 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 PACKAGE | The 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``