Page Comparison

Table of Contents

Overview

The goal of the VNF Guidelines and Requirements project is to provide guidance to VNF providers on the guidelines, rules, and specifications to which a VNF must adhere to correctly onboard and operate within ONAP.  These rules span across the VNF's lifecycle and are influenced by the various components that comprise ONAP as well as various industry standards that are required for interoperability.

This project welcomes and encourages contributions, feedback, and inquiries through a variety of mechanisms.  The intent of this guide is to inform a potential contributor of the various options available to them, and provide instructions on how to use those mechanisms.

Since this project is sub-an approved project of the ONAP community, most of the ways to contribute our are consistent with the standard tools used across ONAP.  Please refer to the Getting involved with the ONAP community page for general information on getting involved with ONAP.

...

...

• Linux Foundation ID: You will need this to access JIRA and Gerrit.  You can register for an ID here.

• Knowledge

  of

  reStructuredText

  (RST):

  All

  documentation

  at

  ONAP

  is

  authored

  in

  RST. 

  For

  the

  most

  part

  you

  can

  follow

  the

  style

  of

  other

  requirements

  and

  content

  without

  being

  an

  RST

  expert,

  but

  understanding

  basics

  may

  be

  useful. 

  The

  ONAP

  Documentation

  project

  has

  some

  useful

  guides

  and

  tutorials

  here.

• Python

  2.7,

  3.6+: You will not need to write any Python code, but it is required to generate the documentation from reStructuredText.  If needed, you can find installation instructions for your system here.

• Git: This is the version control tool used by ONAP. If not present on your system, then refer to Git's Getting Started - Installation Guide for more information
• Git Review: This is the command line extension to Git to enable changes to be submitted to review to Geritt.  This needs to be installed after you have installed Git and Python.

• Tox: This is a tool to run the build.  It must be installed after you install Python.  Install it using pip.

  Code Block
  > pip install tox

  
  

• VNF Requirements Standards:

   Familiarize

   Familiarize yourself with the VNFRQTS Requirement and Documentation Standards

Setup

Before submitting your first change, you will need to configure Git and Gerrit to work together.  That is outside the scope of this guide, but you can find more information here.

...

1. Before submitting a change, open a JIRA ticket to introduce the change.
   1. Project: VNF Requirements
   2. Issue Type: Story for changes that can be incorporated via a single change, Epic if the updates will require multiple commits.  If you need an Epic, then you will need a story for each set of changes you wish to make.  If the changes you are proposing are substantial, then you may need to create an entry in VNF Requirements Proposals for discussion before proceeding with your requirement changes.
   3. Summary: Descriptive summary of the changes to be made
   4. Fix Version: Target ONAP release for your changes
2. Clone the appropriate repository for your content (see VNFRQTS Requirement and Documentation Standards for guidance and links).   
   
   1. Example: git clone ssh://git@gerrit.onap.org:29418/vnfrqts/epics
3. Navigate to the directory you cloned the repository into

4. Run the following command to generate the documentation and verify everything works properly
   
   

   Code Block
   language bash title build docs
   <project-dir> tox -e docs

   
   

5. If everything works properly, this will generate the HTML documentation in the docs\_build\html directory

Editing the Documents

1. If you The first order of business will be adding requirements (NOTE: this is only applicable when working on the vnfrqts/requirements repository), then you will need a block of requirement IDs to use.  Determine the number of requirements you intend to add and use the make_ids.py to generate the requirement IDs (don't worry you can always generate more)


   The following command will generate 5 random, unique requirement IDs for your use.  The requirement IDs you generate will not conflict with any requirement already in the document, but they are not strictly reserved.  The build process will throw an error if your requirement ID is a duplicate.

   Code Block
   language bash title Generate Requirement IDs
   <project-dir> python make_ids.py 5 R-##### R-##### R-##### R-##### R-#####

   Edit the RST documents in the docs folder.  Be sure to format any requirements according using the .. req:: directive as defined in the standards. determining if this requirement should be contributed to the latest version of the requirements, or if it is intended for a prior release.  If you simply, just need to make a change to the latest content then jump to step 3
2. If you wish to change content in a prior release, then you must checkout that branch.  For example, if the master branch is now associated with Dublin, but the change you need to make is for Casablanca, then you will need to do the following:

   1. Fetch the remote branches and checkout the appropriate release branch

      Code Block
      > git fetch > get checkout casablanca (Or whatever the appropriate release branch name is)

      
      

3. If you are adding a new requirement, then you can leave out the :id: and :introduced: attributes as those will be automatically added when you run either ``tox -e docs`` or ``check.py``

   
   

   Code Block
   language text title Example Requirement
   .. req:: :keyword: MUST :target: VNF PACKAGE :impacts: sdc :validation_mode: static The VNF Package **MUST** include element XYZ as part of the CSAR package in the ABC directory

   
   

4. If you are editing the a requirement, then please ensure that the metdata fields are updated appropriately to reflect your changes (example:  :updated: should be set to the current release,  :keyword: and :target: should still match the requirement, etc.)
   
   

   Code Block
   language text title Example Requirement
   .. req:: :id: R-12345 :keyword: MUST :target: VNF PACKAGE :introduced: casablanca :impacts: sdc :validation_mode: static The VNF Package **MUST** include element XYZ as part of the CSAR package in the ABC directory

   
   

5. After you have made your changes, rebuild the documentation using the tox -e docs command, and view the changes in browser to ensure they are formatted correctly.  This will also regenerate the JSON version of the requirements that are located in docs/data/needs.json.  This is the file make_ids.py uses to ensure new requirement IDs do not conflict and the JSON version is also downloadable via the Requirements List chapter of the Requirements document.perform a variety of quality checks and updates.  Please ensure all warnings are addressed before submitting your changes.
   1. Warnings:
      1. Requirement missing required attributes
      2. Invalid values for attributes/metadata
      3. Invalid section header usage in any file
      4. :keyword: and requirement mismatch
   2. Auto Updates:
      1. Assigning :id: on new requirements where an ID missing
      2. Adding :introduced: attribute on new requirements
      3. Adding/correcting :updated: attribute on changed requirements
6. Once you are satisfied with your change, then it will be time to commit and submit your changes for review

...

1. Initialize your repository to work with Gerrit

   Code Block
   > git review -s

   
   

2. Add your changes to git

   Code Block
   > git add --all

   
   

3. Commit your changes

   Code Block
   > git commit -s

   
   

4. Your default, configured editor will open to provide a commit message.  Please ensure that your commit message adheres to the ONAP Commit Messages standards or your submission will be automatically rejected by Gerrit. 
   1. NOTE: At the bottom of your commit message be sure to include the line Issue-ID: VNFRQTS-####  that corresponds to the JIRA ticket you opened for this change.
5. Now you are ready to push your changes to Gerrit using git review
   

   
   

   Code Block
   > git review {branch name} where {branch name} is the name of your target branch (ex: casablanca). If you are submitting to master, then you you can leave off branch name

   
   

6. Once you have successfully pushed the change up, please log into Gerrit and add reviewers

   1. Log into your dashboard
   2. See your Outgoing Reviews and click on the link corresponding to your review
   3. Click Add to add reviewers
   4. 
   5. Add the following reviewers to your review
      1. Steven Wright
      2. Hagop BozawglanianTrevor Lovett
      3. Junfeng Wang
      4. Alan Weinstock
      5. Any additional reviewers you feel would add value
7. Please pay attention to your inbox following the creation of your review.  The ONAP Jobbuilder will attempt to build your documentation and may reject the change if there are problems.  Please see review it's messages and resolve any issues that it raises.
   
   

...

1. Often there will be changes you will need to make to get this working correctly.
2. Make any changes locally based on the feedback and add those those changes to be committed.

...

4. Finally resubmit your change via git review and your change will be updated

> get reviewgit review {branch name}  where {branch name} is the name of your target branch (ex: casablanca

After Your Changes Are Accepted and Merged

...