summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/how-to-use-docs/include-documentation.rst66
-rw-r--r--docs/testing/ecosystem/overview.rst44
2 files changed, 88 insertions, 22 deletions
diff --git a/docs/how-to-use-docs/include-documentation.rst b/docs/how-to-use-docs/include-documentation.rst
new file mode 100644
index 000000000..8ad1a2753
--- /dev/null
+++ b/docs/how-to-use-docs/include-documentation.rst
@@ -0,0 +1,66 @@
+
+=============================================
+OPNFV User guide documentation instruction
+=============================================
+
+Including your Documentation
+------------------------------
+
+Add your documentation to your repository in the folder structure and according to the template listed above. The documentation template you will require are available in the opnfvdocs repository, you should copy the relevant templates to the /docs/userguide directory in your repository. For instance if I wanted to document enabling my feature set in the platform I would follow an example like:
+
+.. code-block:: bash
+ mkdir <my_repo>/docs/userguide
+ git clone ssh://<your_id>@gerrit.opnfv.org:29418/opnfvdocs.git
+ cp opnfvdocs/docs/userguide/userguide.rst <my_repo>/docs/userguide
+
+
+You should then add the relevant information to the template that will explain the usage of your feature and instructions for validating that the feature was used successfully like checking the results of specific test cases. Be sure to maintain the creative commons license from the template and ensure all your documentation files include the license information.
+
+Once your documentation is ready you should ensure they are compiled into the staging files by adding them to the master <section>.rst file in the opnfvdocs repository. The staging files are structured in such a way that you should refer to your document in the correct section of the document structure.
+
+An example of how to add your documentation to the relevant sections of the feature-usage.rst file might be:
+
+.. code-block:: bash
+ git clone ssh://<your_id>@gerrit.opnfv.org:29418/opnfvdocs.git
+ cd opnfvdocs
+ git review -s
+ vim docs/userguide/feature-usage.rst '
+
+
+At this point you should add the references to your files into the index.rst file, for instance in the feature description section you would add the line:
+The following sections of the user guide provide feature specific usage guidelines and references.
+Providing users the necessary information to leveraging the features in the platform,
+some operation in this section may refer back to the guides in the general system usage section.
+
+.. code-block:: bash
+.. include:: ../projects/promise/userguide/userguide.rst
+.. include:: ../projects/copper/userguide/userguide.rst Using Brahmaputra Features
+.. include:: ../projects/<my_repo>/userguide/userguide.rst''
+
+
+If this is the first contribution from your project to the composite document files you will need to add your project to the build-composite.sh file in the opnfvdocs directory. This is done my editing the jsdgf file and adding your repository name to the get_repo_names() function of the script. Assuming you are still in the opnfvdocs directory edit the file with the following command:
+' vim build-composite.sh '
+
+
+Once you have the file open, add your projects repository to the get_repo_names() function:
+
+.. code-block:: python
+ get_repo_names() {
+ # NOTE: Not all repositories are ready for the composite docs,
+ # so we have the repo name list here to add project docs
+ # one by one. This will be replaced by the list in project.cfg .
+ # grep -v '^#' releng/jjb/opnfvdocs/project.cfg | sort
+ echo "sdnvpn"
+ echo "<my_repo>"
+
+
+Once you have made these changes you need to push the patch back to the opnfvdocs team for review and integration.
+
+.. code-block:: bash
+ ' git add . '
+ ' git commit --signoff --all '
+ ' git review '
+
+
+
+Be sure to add the project leader of the opnfvdocs project as a reviewer of the change you just pushed in gerrit. Also be aware that once the text is available in the context of the broader release document it may require some revising and editorial work to prepare it for release.
diff --git a/docs/testing/ecosystem/overview.rst b/docs/testing/ecosystem/overview.rst
index 940e720ab..ffd4c597d 100644
--- a/docs/testing/ecosystem/overview.rst
+++ b/docs/testing/ecosystem/overview.rst
@@ -8,18 +8,20 @@ OPNFV testing
Introduction
============
-Testing is one of the key activities in OPNFV, including component level testing,
-system testing, automated deployment validation and performance characteristics
-or stress testing.
+Testing is one of the key activities in OPNFV and includes unit, feature, component, system
+level testing for development, automated deployment, performance characterization or stress
+testing.
-Some projects are fully dedicated to testing, they provide frameworks or tooling.
-The feature projects also include their own test suites.
-he test projects fulfill different roles (such as functional checks, performance
-measurement, platform and component benchmarks, and analysis) on the scenarios
-released in OPNFV.
+Test projects are dedicated to provide frameworks, tooling and test-cases catagorized as
+functional, performance or compliance testing. Test projects fulfill different roles such as
+verifying VIM functionality, benchmarking components and platforms or analysis of measured
+KPIs for the scenarios released in OPNFV.
-This document will detail the OPNFV testing ecosystem, describe the commons used
-by the projects and provide the links to project specific documentation.
+Feature projects also provide their own test suites that either run independently or within a
+test project.
+
+This document details the OPNFV testing ecosystem, describes test commonality used
+by the projects and provides links to project specific documentation.
OPNFV testing ecosystem
@@ -34,7 +36,7 @@ The OPNFV testing projects may be summarized as follows:
:align: center
:alt: Overview of OPNFV Testing projects
-The main projects of the testing projects are described in the table below:
+The major testing projects are described in the table below:
+----------------+---------------------------------------------------------+
| Project | Description |
@@ -46,8 +48,8 @@ The main projects of the testing projects are described in the table below:
| | production environment, an automatic method for |
| | executing benchmarks which plans to validate the |
| | deployment during staging is adopted. This project |
-| | provides a framework to find the bottlenecks of OPNFV |
-| | infrastructure. |
+| | forms a staging framework to find bottlenecks and to do |
+| | analysis of the OPNFV infrastructure. |
+----------------+---------------------------------------------------------+
| CPerf | SDN Controller benchmarks and performance testing, |
| | applicable to controllers in general. |
@@ -86,15 +88,13 @@ The main projects of the testing projects are described in the table below:
| | pass/fail thresholds for test, staging, and production |
| | NFVI environments. |
+----------------+---------------------------------------------------------+
-| VSperf | The Project “vSwitch Performance" develops a generic and|
-| | architecture agnostic vSwitch testing framework and |
-| | associated tests, that will serve as a basis for |
-| | validating the suitability of different vSwitch |
-| | implementations in a Telco NFV deployment environment. |
-| | The output of this project will be utilized by the OPNFV|
-| | Performance and Test group and its associated projects, |
-| | as part of OPNFV Platform and VNF level testing and |
-| | validation. |
+| VSperf | This project provides a framework for automation of NFV |
+| | data-plane performance testing and benchmarking. The |
+| | NFVI fast-path includes switch technology and network |
+| | with physical and virtual interfaces. Vsperf can be |
+| | used to evaluate the suitability of different Switch |
+| | implementations and features, quantify data-path |
+| | performance and optimize platform configurations. |
+----------------+---------------------------------------------------------+
| Yardstick | The goal of the Project is to verify the infrastructure |
| | compliance when running VNF applications. NFV Use Cases |