Added doc directories

Change-Id: I671d7c3ad4f4e5e476c98f53780d867dc94b3089
Signed-off-by: Stuart Mackie <wsmackie@juniper.net>

77 files changed, 4310 insertions, 0 deletions

diff --git a/docs/_static/favicon.ico b/docs/_static/favicon.ico
new file mode 100755
index 0000000..bbe55ab
--- /dev/null
+++ b/docs/_static/favicon.ico
diff --git a/docs/_static/images/OPNFV_testing_group.png b/docs/_static/images/OPNFV_testing_group.png
new file mode 100644
index 0000000..4b8c2c0
--- /dev/null
+++ b/docs/_static/images/OPNFV_testing_group.png
diff --git a/docs/_static/images/opnfvplatformgraphic.png b/docs/_static/images/opnfvplatformgraphic.png
new file mode 100644
index 0000000..9d6074f
--- /dev/null
+++ b/docs/_static/images/opnfvplatformgraphic.png
diff --git a/docs/_static/my-styles.css b/docs/_static/my-styles.css
new file mode 100644
index 0000000..94e72cd
--- /dev/null
+++ b/docs/_static/my-styles.css
@@ -0,0 +1,28 @@
+body{
+	font-family:"Arial", Helvetica, sans-serif;
+}
+
+.navbar-brand img {
+    height: 200%;
+    margin-top: -5%;
+}
+
+.navbar, h1, h2, h3, h4, h5, h6 {
+	font-family: "Arial",sans-serif;
+}
+
+.navbar-fixed-top {
+    top: 10px
+}
+
+.navbar-text{
+	color: #676767;
+}
+
+.navbar-form.navbar-right{
+	padding: 0;
+}
+
+.navbar-form .form-control{
+	width: 150px;
+}
\ No newline at end of file
diff --git a/docs/_static/opnfv-logo.png b/docs/_static/opnfv-logo.png
new file mode 100644
index 0000000..1519503
--- /dev/null
+++ b/docs/_static/opnfv-logo.png
diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html
new file mode 100644
index 0000000..08baa3e
--- /dev/null
+++ b/docs/_templates/layout.html
@@ -0,0 +1,5 @@
+{# Import the theme's layout. #}
+{% extends "!layout.html" %}
+
+{# Custom CSS overrides #}
+{% set bootswatch_css_custom = ['_static/my-styles.css'] %}
\ No newline at end of file
diff --git a/docs/_templates/my_custom_sidebar.html b/docs/_templates/my_custom_sidebar.html
new file mode 100644
index 0000000..6b259bc
--- /dev/null
+++ b/docs/_templates/my_custom_sidebar.html
@@ -0,0 +1,3 @@
+<ul class="globaltoc">
+{{ toctree(maxdepth=theme_globaltoc_depth|toint, collapse=False,includehidden=theme_globaltoc_includehidden|tobool) }}
+</ul>
\ No newline at end of file
diff --git a/docs/_templates/relations.html b/docs/_templates/relations.html
new file mode 100644
index 0000000..5bad0b5
--- /dev/null
+++ b/docs/_templates/relations.html
@@ -0,0 +1,15 @@
+<center>
+<div class="btn-group" role="group" aria-label="...">
+    {% if prev %}
+    <a class="btn btn-default" href="{{ prev.link|e }}">Prev Page</a>
+    {% else %}
+    <button type="button" class="btn btn-default disabled">Prev Page</button>
+    {% endif %}
+
+    {% if next %}
+    <a class="btn btn-default" href="{{ next.link|e }}">Next Page</a>
+    {% else %}
+    <button type="button" class="btn btn-default disabled">Next Page</button>
+    {% endif %}
+</div>
+</center>
\ No newline at end of file
diff --git a/docs/conf.py b/docs/conf.py
new file mode 100644
index 0000000..38a8c81
--- /dev/null
+++ b/docs/conf.py
@@ -0,0 +1,282 @@
+import sphinx_bootstrap_theme
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+# needs_sphinx = '1.0'
+needs_sphinx = '1.3'
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['sphinxcontrib.httpdomain', 'sphinx.ext.autodoc',
+              'sphinx.ext.viewcode', 'sphinx.ext.napoleon']
+# Disable javasphinx generation until we have a solution to long build
+# times. readthedocs timesout after 902 seconds.
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+# source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = ''
+copyright = '2017, OPNFV. Licensed under CC BY 4.0'
+author = 'Open Platform for NFV'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = 'Danube'
+# The full version, including alpha/beta/rc tags.
+release = 'Danube'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+# today = ''
+# Else, today_fmt is used as the format for a strftime call.
+# today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This patterns also effect to html_static_path and html_extra_path
+exclude_patterns = []
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+# default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+# add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+# add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+# show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+# modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+# keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'bootstrap'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+# html_theme_options = {}
+html_theme_options = {
+    'bootswatch_theme': "journal",
+    'navbar_sidebarrel': False,
+}
+
+# Add any paths that contain custom themes here, relative to this directory.
+# html_theme_path = []
+html_theme_path = sphinx_bootstrap_theme.get_html_theme_path()
+
+# The name for this set of Sphinx documents.
+# "<project> v<release> documentation" by default.
+# html_title = 'OpenDaylight Documentation v0.3.0'
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+# html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+html_logo = '_static/opnfv-logo.png'
+
+# The name of an image file (relative to this directory) to use as a favicon of
+# the docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+html_favicon = '_static/favicon.ico'
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+# html_extra_path = []
+
+# If not None, a 'Last updated on:' timestamp is inserted at every page
+# bottom, using the given strftime format.
+# The empty string is equivalent to '%b %d, %Y'.
+# html_last_updated_fmt = None
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+# html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+# html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+# html_additional_pages = {}
+
+# If false, no module index is generated.
+# html_domain_indices = True
+
+# If false, no index is generated.
+# html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+# html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+# html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+# html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+# html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+# html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+# html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'h', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'r', 'sv', 'tr', 'zh'
+# html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# 'ja' uses this config value.
+# 'zh' user can custom change `jieba` dictionary path.
+# html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+# html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'OPNFV'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+    # The paper size ('letterpaper' or 'a4paper').
+    #'papersize': 'letterpaper',
+
+    # The font size ('10pt', '11pt' or '12pt').
+    #'pointsize': '10pt',
+
+    # Additional stuff for the LaTeX preamble.
+    #'preamble': '',
+
+    # Latex figure (float) alignment
+    #'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'OPNFV.tex', 'OPNFV Documentation',
+     'OPNFV Project', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+# latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+# latex_use_parts = False
+
+# If true, show page references after internal links.
+# latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+# latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+# latex_appendices = []
+
+# If false, no module index is generated.
+# latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'OPNFVDocs', 'OPNFV Documentation',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+# man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'OPNFVDocs', 'OPNFV Documentation',
+     author, 'OPNFV', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+html_sidebars = {'**': ['localtoc.html', 'relations.html'],}
+# Documents to append as an appendix to all manuals.
+# texinfo_appendices = []
+
+# If false, no module index is generated.
+# texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+# texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+# texinfo_no_detailmenu = False
+
+# intersphinx_mapping =
+# {'RTD':('http://opnfvdocsdemo.readthedocs.io/projects/', None)}
diff --git a/docs/development/feature.templates/scenarios/scenario.name/index.rst b/docs/development/feature.templates/scenarios/scenario.name/index.rst
new file mode 100644
index 0000000..59ada34
--- /dev/null
+++ b/docs/development/feature.templates/scenarios/scenario.name/index.rst
@@ -0,0 +1,16 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+===================================
+<scenario> overview and description
+===================================
+.. This document will be used to provide a description of the scenario for an end user.
+.. You should explain the purpose of the scenario, the types of capabilities provided and
+..  the unique components that make up the scenario including how they are used.
+
+.. toctree::
+   :maxdepth: 3
+
+   ./scenario.description.rst
+
diff --git a/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst b/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst
new file mode 100644
index 0000000..afd5879
--- /dev/null
+++ b/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst
@@ -0,0 +1,32 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+Introduction
+============
+.. In this section explain the purpose of the scenario and the types of capabilities provided
+
+Scenario components and composition
+===================================
+.. In this section describe the unique components that make up the scenario,
+.. what each component provides and why it has been included in order
+.. to communicate to the user the capabilities available in this scenario.
+
+Scenario usage overview
+=======================
+.. Provide a brief overview on how to use the scenario and the features available to the
+.. user.  This should be an "introduction" to the userguide document, and explicitly link to it,
+.. where the specifics of the features are covered including examples and API's
+
+Limitations, Issues and Workarounds
+===================================
+.. Explain scenario limitations here, this should be at a design level rather than discussing
+.. faults or bugs.  If the system design only provide some expected functionality then provide
+.. some insight at this point.
+
+References
+==========
+
+For more information on the OPNFV Colorado release, please visit
+http://www.opnfv.org/colorado
+
diff --git a/docs/development/feature.templates/userguide/feature.userguide.rst b/docs/development/feature.templates/userguide/feature.userguide.rst
new file mode 100644
index 0000000..b8adfa5
--- /dev/null
+++ b/docs/development/feature.templates/userguide/feature.userguide.rst
@@ -0,0 +1,19 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+<Feature> description
+=====================
+.. Describe the specific features and how it is realised in the scenario in a brief manner
+.. to ensure the user understand the context for the user guide instructions to follow.
+
+<Feature> capabilities and usage
+================================
+.. Describe the specific capabilities and usage for <XYZ> feature.
+.. Provide enough information that a user will be able to operate the feature on a deployed scenario.
+
+<Feature and API usage guidelines and example>
+-----------------------------------------------
+.. Describe with examples how to use specific features, provide API examples and details required to
+.. operate the feature on the platform.
+
diff --git a/docs/development/feature.templates/userguide/index.rst b/docs/development/feature.templates/userguide/index.rst
new file mode 100644
index 0000000..cc84670
--- /dev/null
+++ b/docs/development/feature.templates/userguide/index.rst
@@ -0,0 +1,23 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+====================
+<feature> user guide
+====================
+
+.. The feature user guide should provide an OPNFV user with enough information to
+.. use the features provided by the feature project in the supported scenarios.
+.. This guide should walk a user through the usage of the features once a scenario
+.. has been deployed and is active according to the installation guide provided
+.. by the installer project.
+
+.. toctree::
+   :maxdepth: 3
+
+.. The feature.userguide.rst file should contain the text for this document
+.. additional documents can be added to this directory and added in the right order
+.. to this file as a list below.
+
+   ./feature.userguide.rst
+
diff --git a/docs/development/opnfvsecguide/_static/temp b/docs/development/opnfvsecguide/_static/temp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/development/opnfvsecguide/_static/temp
diff --git a/docs/development/opnfvsecguide/_templates/temp b/docs/development/opnfvsecguide/_templates/temp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/development/opnfvsecguide/_templates/temp
diff --git a/docs/development/opnfvsecguide/audit.rst b/docs/development/opnfvsecguide/audit.rst
new file mode 100644
index 0000000..cdeecba
--- /dev/null
+++ b/docs/development/opnfvsecguide/audit.rst
@@ -0,0 +1,9 @@
+Audit
+----------------
+
+.. toctree::
+   :maxdepth: 2
+
+   audit/audit_reqs
+   audit/configuring
+
diff --git a/docs/development/opnfvsecguide/audit/audit_reqs.rst b/docs/development/opnfvsecguide/audit/audit_reqs.rst
new file mode 100644
index 0000000..ce76d01
--- /dev/null
+++ b/docs/development/opnfvsecguide/audit/audit_reqs.rst
@@ -0,0 +1,110 @@
+Requirements references related to OPNFV Audit
+
+------------------
+Source information
+------------------
+
+http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/003/01.01.01_60/gs_NFV-INF003v010101p.pdf
+http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/004/01.01.01_60/gs_NFV-INF004v010101p.pdf
+
+* ETSI GS NFV-SEC 003 V1.1.1 (2014-12)
+
+  - Network Functions Virtualisation NFV);
+  - NFV Security; Security and Trust Guidance
+  - NFV-SEC-003_.
+
+
+.. _NFV-SEC-003: http://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/003/01.01.01_60/gs_NFV-SEC003v010101p.pdf
+* ETSI GS NFV 004 V1.1.1 (2013-10)
+
+  - Network Functions Virtualisation (NFV);
+  - Virtualisation Requirements
+  - NFV-SEC-004_.
+
+.. _NFV-SEC-004: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf
+
+Requirements on Auditing framework
+----------------------------------
+
+Audit records shall be maintained within protected binary logs so that the record of
+malicious actions cannot be deleted from the logs.
+
+Necessary auditable events
+--------------------------
+
+* access control management
+
+  - Adding a user account
+  - Modifying user account
+  - Deleting a user account
+  - login event
+  - logout event
+  - IP whitelisting update
+  - IP blacklisting update
+
+* VNFC Creation
+
+  - The instantiation of a newly-defined VNFC
+  - The instantiation of a VNFC with pre-configured state
+  - The cloning of an existing VNFC
+
+* VNFC Deletion
+
+  - The deletion of VNFC and of all of its instances (e.g. snapshots, backups, archives, cloned images)
+
+* Software management
+
+  - patching e.g. opreating system, drivers, VM components
+  - dynamic updates to the configuration e.g. DNS, DHCP
+  - application software updates
+  - software component updates
+
+* Data management
+
+  - Root level access to NFVI file system
+  - User level access to NFVI file system
+  - Secured wipe, disk and memory
+  - Verified destruction
+  - Certificate revocation
+
+* VNFC Migration
+
+  - VNFC original host identity
+  - VNFC target host identity
+  - high availability
+  - recovery
+  - data-in-motion changes
+
+* Other VNFC Operational State Changes
+
+  - Hibernation, sleep, resumption, abort, restore, suspension
+  - Power-on and power-off (either physical or virtual)
+  - Integrity verification failure, crash and OS compromise
+
+* VNFC Topology Changes
+
+  - Network IP address and VLAN updates
+  - Service chaining
+  - Failover and disaster recovery
+
+* traffic inspection
+
+  - enabling virtual port mirroring
+  - enabling hypervisor introspection
+  - enabling in-line traffic inspection
+  - application insertion
+
+* initial provisioning of a public/private key pair
+
+  - Self-generation of key pairs for later validation by an external party:
+
+     - Certificate Authority
+     - VNFM
+
+  - Provision by trusted party
+
+     - network
+     - storage
+
+  - Injection by hypervisor
+
diff --git a/docs/development/opnfvsecguide/compute.rst b/docs/development/opnfvsecguide/compute.rst
new file mode 100644
index 0000000..d6c1a01
--- /dev/null
+++ b/docs/development/opnfvsecguide/compute.rst
@@ -0,0 +1,8 @@
+Compute Security
+----------------
+
+.. toctree::
+   :maxdepth: 2
+
+   compute/dacmaccontrols.rst
+   compute/trust.rst
diff --git a/docs/development/opnfvsecguide/compute/dacmaccontrols.rst b/docs/development/opnfvsecguide/compute/dacmaccontrols.rst
new file mode 100644
index 0000000..08cd7ee
--- /dev/null
+++ b/docs/development/opnfvsecguide/compute/dacmaccontrols.rst
@@ -0,0 +1,3 @@
+DAC & MAC Controls
+------------------
+
diff --git a/docs/development/opnfvsecguide/compute/trust.rst b/docs/development/opnfvsecguide/compute/trust.rst
new file mode 100644
index 0000000..3022e59
--- /dev/null
+++ b/docs/development/opnfvsecguide/compute/trust.rst
@@ -0,0 +1,124 @@
+Trusted Compute
+---------------
+
+Trusted compute is centered on insuring the complete lifecycle of a VM, and
+the VM's underlying infrastructure is of a 'trustful' state.
+
+**Trusted computing in a cloud environment**
+
+To ensure overall security in an OPNFV deployment, both the launch and the
+operation of virtualized resources need to be secure. To build a trusted
+computing in a cloud environment the following core features are essential:
+
+* boot integrity - the hardware platform can guarantee a trustworthy RoT for the overall cloud environment
+* secure management of VMs – to secure the launch and migration of VMs in the cloud environment
+
+In this section we will cover some aspects of what is considered compute
+security, such as secure/trusted boot, although of course these can be
+extended to other actors such as neutron networking nodes.
+
+Secure Boot
+###########
+
+Secure boot, a UEFI-based feature that has become controversial lately,
+ensures that nodes in an OPNFV deployment boot only software that is trusted
+by the admin or end user.
+
+In order to understand the secure boot procedure, we need to explain the related technology
+and specification.
+
+**Unified Extensible Firmware Interface (UEFI)**
+
+UEFI is a specification intended to be the replacement and improvement on the
+old BIOS (Basic Input/Output System).
+
+One UEFI-based feature that has become controversial lately is the secure boot feature.
+
+The UEFI specification is a standard that’s handled by a non-profit organization
+with representatives of Intel, AMD, Microsoft, Apple, Dell, HP, IBM and others,
+called the Unified EFI Forum.
+
+UEFI supports 32 and 64 bit processors and can be used with Itanium, x86,
+x64 and ARM processors.
+
+**Trusted Execution Environment (TEE) vs Trusted Platform Mobile (TPM)**
+
+Two main components of platform security:
+
+* Trusted Execution Environment
+* Trusted Platform Module
+
+These are not designed as a replacement of the other. TEE is the bulletproof
+safe, while TPM is the 128-digit combination lock for the safe. Both are
+needed to ensure the safe is protected.
+
+TPM is a dependency of TEE but not the other way around.
+
+The TPM is where TEE will store the measurements - hash of components - of the platform.
+
+If TEE is not supported by a platform but a TPM is still present you still have
+all these features:
+
+* Integrity measurement – securely measure the platform's components (hashes stored within the TPM)
+
+* Authenticated boot – a process by which a platform's state (the sum of its
+  components) is reliably measured and stored
+
+* SRTM - Static Root of Trust for Measurements
+
+* Sealed Storage - encrypt data based on the current state of the platform
+  or in other words, what has been measured (the PCR hash values stored in the
+  TPM) - seal operation
+
+* Attestation - securely report to other parties the state of the platform
+
+
+Trusted Compute Pools
+#####################
+
+**Trusted Boot**
+
+Trusted boot (tboot) is an open source, pre- kernel/VMM module that uses
+Intel(R) Trusted Execution Technology (Intel(R) TXT) to perform a measured
+and verified launch of an OS kernel/VMM. The root of trust is in the hardware
+and a TPM is required. Compute nodes in an OPNFV deployment boot with Intel
+TXT technology enabled.
+
+Read more about `Trusted Boot <http://www.trustedcomputinggroup.org/resources/trusted_boot>`_ and
+`Trusted Computing. <http://www.trustedcomputinggroup.org/trusted_computing>`_
+
+**Trusted Execution Environments (TEE)**
+
+The Trusted Execution Environment is an isolated execution environment which
+provides higher level of security such as isolated execution, integrity of
+Trusted Applications along with confidentiality of their assets.
+
+**Goals of a Trusted Execution Environments:**
+
+* Isolated Execution
+* Secure Storage
+* Remote Attestation
+* Secure Provisioning
+* Trusted Path
+
+**TEE platforms/implementations**
+
+* Intel’s TXT (Trusted Execution Technology)
+* AMD Secure Execution Environment
+* ARM TrustZone
+
+All three of these TEE implementations provide a virtualized Execution
+Environment for the secure OS and applications.
+
+To switch between the secure world and the normal world, Intel provides SMX
+Instructions, while ARM uses SMC. Programmatically, they all achieve very
+similar results.
+
+Read more about Trusted Execution Environments `here. <http://www.openvirtualization.org/open-source-arm-trustzone.html>`_
+
+`NIST SP800-147 <http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf>`_
+, is a  guidelines for firmware security, to ensure that the firmware itself is secure.
+
+Read more about "Trusted compute pools", in the
+`OpenStack Security Guide. <http://docs.openstack.org/admin-guide-cloud/compute-security.html>`_
+
diff --git a/docs/development/opnfvsecguide/contribution.rst b/docs/development/opnfvsecguide/contribution.rst
new file mode 100644
index 0000000..683aa2d
--- /dev/null
+++ b/docs/development/opnfvsecguide/contribution.rst
@@ -0,0 +1,45 @@
+How to Contribute
+-----------------
+
+Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation.
+To do so, you will however need to first get an enviroment set up.
+
+Development Environment
+#######################
+
+All project data such as formatting guidelines, and upstream mapping is documented via sphinx
+which uses reStructuredText
+
+It is recommended that you use a python virtualenv to keep things clean and contained.
+
+VirtualEnv
+**********
+
+Use of a virtual environment is recommended, as not only is it a quick easy form of
+getting the needed modules in place, it isolates the module versions to a project.
+
+From within your inspector directory, set up a new virtualenv::
+
+    virtualenv venv
+
+Activate the new virtual environment::
+
+    source venv/bin/activate
+
+Install requirements::
+
+    pip install -r requirements.txt
+
+Sphinx Basics
+*************
+
+To get started with sphinx, visit the main tutorial which will provide a primer `http://sphinx-doc.org/tutorial.html`
+
+Hack your changes into opnfv-security-guide/source
+
+To compile changes:
+
+    make html
+
+From here you can run a basic python web server or just navigate to the
+file:///<repo>/opnfv-security-guide/build/html/index.html in your browser
diff --git a/docs/development/opnfvsecguide/getting_started.rst b/docs/development/opnfvsecguide/getting_started.rst
new file mode 100644
index 0000000..e09507d
--- /dev/null
+++ b/docs/development/opnfvsecguide/getting_started.rst
@@ -0,0 +1,41 @@
+Getting Started
+---------------
+
+Development Environment
+#######################
+
+All project data such as formatting guidelines, and upstream mapping is documented via sphinx
+which uses reStructuredText
+
+VirtualEnv
+**********
+
+Use of a virtual environment is recommended, as not only is it a quick easy form of
+getting the needed modules in place, it isolates the module versions to a project.
+
+From within your inspector directory, set up a new virtualenv::
+
+    virtualenv venv
+
+Activate the new virtual environment::
+
+    source venv/bin/activate
+
+Install requirements::
+
+    pip install -r requirements.txt
+
+Sphinx Basics
+*************
+
+To get started with sphinx, visit the main tutorial which will provide a primer
+`http://sphinx-doc.org/tutorial.html`
+
+Hack your changes into opnfv-security-guide/source
+
+To compile changes:
+
+    make html
+
+From here you can run a basic python web server or just navigate to the
+file:///<repo>/opnfv-security-guide/build/html/index.html in your browser
diff --git a/docs/development/opnfvsecguide/index.rst b/docs/development/opnfvsecguide/index.rst
new file mode 100644
index 0000000..ecefd61
--- /dev/null
+++ b/docs/development/opnfvsecguide/index.rst
@@ -0,0 +1,21 @@
+.. OPNFV Security Guide documentation master file, created by
+   sphinx-quickstart on Tue Oct 27 19:30:29 2015.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to OPNFV Security Guide
+================================================
+
+This guide seeks to inform operators who to secure and maintain the security of the OPNFV Platform and its components.
+
+Contents:
+
+.. toctree::
+   :maxdepth: 2
+
+   introduction
+   compute
+   network
+   contribution
+   audit
+
diff --git a/docs/development/opnfvsecguide/introduction.rst b/docs/development/opnfvsecguide/introduction.rst
new file mode 100644
index 0000000..ad80831
--- /dev/null
+++ b/docs/development/opnfvsecguide/introduction.rst
@@ -0,0 +1,15 @@
+Introduction
+---------------
+
+The OPNFV Security Guide is the collaborative work of many individuals,
+involved in both the OPNFV Security Group and the wider OPNFV community.
+
+The purpose of this guide is to provide the best practice security guidelines for
+deploying the OPNFV platfornm. It is a living document that is updated as
+new changes are merged into it's repository.
+
+.. toctree::
+   :maxdepth: 2
+
+   introduction/background
+   introduction/acknowledgements
diff --git a/docs/development/opnfvsecguide/introduction/acknowledgements.rst b/docs/development/opnfvsecguide/introduction/acknowledgements.rst
new file mode 100644
index 0000000..60c687d
--- /dev/null
+++ b/docs/development/opnfvsecguide/introduction/acknowledgements.rst
@@ -0,0 +1,3 @@
+Acknowledgements
+----------------
+
diff --git a/docs/development/opnfvsecguide/introduction/background.rst b/docs/development/opnfvsecguide/introduction/background.rst
new file mode 100644
index 0000000..bd7e44d
--- /dev/null
+++ b/docs/development/opnfvsecguide/introduction/background.rst
@@ -0,0 +1,38 @@
+Background
+----------
+
+Pre-virtualization security protection was largely centered on the network.
+Malicious attacks from hostile machines, would seek to exploit network based
+operating systems and applications, with the goal of compromising their
+target node.
+
+Physical security had always been a much simpler business, with most focus on
+the secure access of the data center hardware.
+In-turn security was built up in layers (defense in depth) where machines
+would be
+daisy chained with network cables via  security appliances to provide
+controlled segmentation and isolation.
+This form of security was built upon the principle of an 'air gap'
+being present,
+whereby machines were separate physical units, joined largely by the
+network stack.
+
+With the advent of virtualization (namely the hypervisor), new attack
+vectors have
+surfaced as the 'air-gap' is no longer key design aspect for security.
+Further to this elements orchestation nodes and network controllers
+lead to an even wider attack surface:
+
+* Guests breaking isolation of the hypervisor.
+
+* Unauthorized access and control of supporting orchestration nodes.
+
+* Unauthorized access and control of supporting overlay network control systems.
+
+The hypervisor and the overlay network have now become the 'Achilles heel'
+whereby all tenant data isolation is enforced within the hypervisor and its
+abstraction
+of hardware and the virtualized overlay network.
+
+This guide has been formulated, in order to assist users of the OPNFV platform
+in securing an Telco NFV / SDN environment.
diff --git a/docs/development/opnfvsecguide/network.rst b/docs/development/opnfvsecguide/network.rst
new file mode 100644
index 0000000..b174479
--- /dev/null
+++ b/docs/development/opnfvsecguide/network.rst
@@ -0,0 +1,8 @@
+Network Security
+----------------
+
+
+.. toctree::
+   :maxdepth: 2
+
+   network/neutron
diff --git a/docs/development/opnfvsecguide/network/neutron.rst b/docs/development/opnfvsecguide/network/neutron.rst
new file mode 100644
index 0000000..e7ca060
--- /dev/null
+++ b/docs/development/opnfvsecguide/network/neutron.rst
@@ -0,0 +1,2 @@
+Neutron Security
+----------------
diff --git a/docs/development/scenario/featurematrix.rst b/docs/development/scenario/featurematrix.rst
new file mode 100644
index 0000000..2d00a40
--- /dev/null
+++ b/docs/development/scenario/featurematrix.rst
@@ -0,0 +1,39 @@
+Each scenario provides a set of platform capabilities and features that it supports.  It is
+possible to identify which features are provided by reviewing the scenario name, however
+not all features and capabilities are discernible from the name itself.
+
+Brahmaputra feature support matrix
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following table provides an overview of the available scenarios and supported features
+in the Brahmaputra release of OPNFV.
+
+.. image:: ../images/brahmaputrafeaturematrix.jpg
+   :alt: OPNFV Brahmaputra Feature Matrix
+
+The table above provides an overview of which scenarios will support certain feature capabilities.
+The table does not indicate if the feature or scenario has limitations. Refer to the
+`Configuration Guide <http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/configguide/configoptions.html#opnfv-scenarios>`_
+for details on the state of each scenario and further information.
+
+Feature development in the Brahmaputra release often consisted of the development of specific
+requirements and the further integration and validation of those requirements.  This results in some
+features only being supported on the platform when a specific scenario, providing the
+capabilities necessary to run the feature, is deployed.
+
+Scenario Naming
+^^^^^^^^^^^^^^^
+
+In OPNFV, scenarios are identified by short scenario names.  These names follow a scheme that
+identifies the key components and behaviours of the scenario, the rules for scenario naming are as follows:
+
+  os-[controller]-[feature]-[mode]-[option]
+
+For example: *os-nosdn-kvm-noha* provides an OpenStack based deployment using neutron including
+the OPNFV enhanced KVM hypervisor.
+
+The [feature] tag in the scenario name describes the main feature provided by the scenario.
+This scenario may also provide support for features, such as advanced fault management, which are
+not apparent in the scenario name.
+The following section describes the features available in each scenario.
+
diff --git a/docs/development/scenario/scenariointro.rst b/docs/development/scenario/scenariointro.rst
new file mode 100644
index 0000000..dd80843
--- /dev/null
+++ b/docs/development/scenario/scenariointro.rst
@@ -0,0 +1,13 @@
+OPNFV Scenarios
+---------------
+
+The OPNFV project provides an integration and deployment environment for a variety of components
+that can make up a virtualisation platform.  OPNFV identifies these variations on the composition of
+the platform as scenarios.
+
+A scenario in OPNFV can be defined as "a deployment of a specific set of platform components".  The
+composition of a scenario may include specific SDN controller technologies, specific accelerate
+switching technologies, or even specific configurations of components to achieve targeted platform
+capabilities.  Each scenario behaves differetly and it is important to understand the behaviour you
+want in order to target the specific scenario you wish to deploy prior to working with the
+OPNFV platform.
diff --git a/docs/development/scenario/scenariomatrix.rst b/docs/development/scenario/scenariomatrix.rst
new file mode 100644
index 0000000..64e1150
--- /dev/null
+++ b/docs/development/scenario/scenariomatrix.rst
@@ -0,0 +1,100 @@
+Scenarios are implemented as deployable compositions through integration with an installation tool.
+OPNFV supports multiple installation tools and for any given release not all tools will support all
+scenarios. While our target is to establish parity across the installation tools to ensure they
+can provide all scenarios, the practical challenge of achieving that goal for any given feature and
+release results in some disparity.
+
+Brahmaputra scenario overeview
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following table provides an overview of the installation tools and available scenario's
+in the Brahmaputra release of OPNFV.
+
+.. image:: ../images/brahmaputrascenariomatrix.jpg
+   :alt: OPNFV Brahmaputra Scenario Matrix
+
+Scenario status is indicated by a weather pattern icon. All scenarios listed with
+a weather pattern are possible to deploy and run in your environment or a Pharos lab,
+however they may have known limitations or issues as indicated by the icon.
+
+Weather pattern icon legend:
+
++---------------------------------------------+----------------------------------------------------------+
+| Weather Icon                                | Scenario Status                                          |
++=============================================+==========================================================+
+| .. image:: ../images/weather-clear.jpg      | Stable, no known issues                                  |
++---------------------------------------------+----------------------------------------------------------+
+| .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations                           |
++---------------------------------------------+----------------------------------------------------------+
+| .. image:: ../images/weather-overcast.jpg   | Deployable, stability or feature limitations             |
++---------------------------------------------+----------------------------------------------------------+
+| .. image:: ../images/weather-dash.jpg       | Not deployed with this installer                         |
++---------------------------------------------+----------------------------------------------------------+
+
+Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised
+and updates will be made on the stable/brahmaputra branch. While we intend that all Brahmaputra
+scenarios should be stable it is worth checking regularly to see the current status.  Due to
+our dependency on upstream communities and code some issues may not be resolved prior to the C release.
+
+Scenario Naming
+^^^^^^^^^^^^^^^
+
+In OPNFV scenarios are identified by short scenario names, these names follow a scheme that
+identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows:
+
+  os-[controller]-[feature]-[mode]-[option]
+
+Details of the fields are
+  * os: mandatory
+
+    * Refers to the platform type used
+    * possible value: os (OpenStack)
+
+* [controller]: mandatory
+
+    * Refers to the SDN controller integrated in the platform
+    * example values: nosdn, ocl, odl, onos
+
+  * [feature]: mandatory
+
+    * Refers to the feature projects supported by the scenario
+    * example values: nofeature, kvm, ovs, sfc
+
+  * [mode]: mandatory
+
+    * Refers to the deployment type, which may include for instance high availability
+    * possible values: ha, noha
+
+  * [option]: optional
+
+    * Used for the scenarios those do not fit into naming scheme.
+    * The optional field in the short scenario name should not be included if there is no optional scenario.
+
+Some examples of supported scenario names are:
+
+  * os-nosdn-kvm-noha
+
+    * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor
+
+  * os-onos-nofeature-ha
+
+    * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller
+
+  * os-odl_l2-sfc
+
+    * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features
+
+Installing your scenario
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are two main methods of deploying your target scenario, one method is to follow this guide which will
+walk you through the process of deploying to your hardware using scripts or ISO images, the other method is
+to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master.
+
+For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed
+virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing
+virtual deployments can be found in the installer specific installation instructions.
+
+To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide.
+<http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html>`_
+
diff --git a/docs/development/scenario/scenariovalidation.rst b/docs/development/scenario/scenariovalidation.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/development/scenario/scenariovalidation.rst
diff --git a/docs/featureprojects.rst b/docs/featureprojects.rst
new file mode 100644
index 0000000..ad60461
--- /dev/null
+++ b/docs/featureprojects.rst
@@ -0,0 +1,265 @@
+.. _opnfv-featureprojects:
+
+OPNFV Projects
+================
+
+Apex
+----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/apex/docs/development/overview/index
+   ../submodules/apex/docs/development/requirements/index
+   ../submodules/apex/docs/release/installation/index
+   ../submodules/apex/docs/release/configguide/index
+   ../submodules/apex/docs/release/userguide/index
+   ../submodules/apex/docs/development/design/index
+   ../submodules/apex/docs/development/manuals/index
+
+
+Armband
+-------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/armband/docs/development/overview/index
+   ../submodules/armband/docs/development/requirements/index
+   ../submodules/armband/docs/release/installation/index
+   ../submodules/armband/docs/release/configguide/index
+   ../submodules/armband/docs/release/userguide/index
+   ../submodules/armband/docs/development/design/index
+   ../submodules/armband/docs/development/manuals/index
+
+
+Availability
+------------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/availability/docs/development/overview/index
+   ../submodules/availability/docs/development/requirements/index
+   ../submodules/availability/docs/release/installation/index
+   ../submodules/availability/docs/release/configguide/index
+   ../submodules/availability/docs/release/userguide/index
+   ../submodules/availability/docs/development/design/index
+   ../submodules/availability/docs/development/manuals/index
+
+
+Barometer
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/barometer/docs/development/overview/index
+   ../submodules/barometer/docs/development/requirements/index
+   ../submodules/barometer/docs/release/installation/index
+   ../submodules/barometer/docs/release/configguide/index
+   ../submodules/barometer/docs/release/userguide/index
+   ../submodules/barometer/docs/development/design/index
+   ../submodules/barometer/docs/development/manuals/index
+
+
+Compass4Nfv
+-----------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/compass4nfv/docs/development/overview/index
+   ../submodules/compass4nfv/docs/development/requirements/index
+   ../submodules/compass4nfv/docs/release/installation/index
+   ../submodules/compass4nfv/docs/release/configguide/index
+   ../submodules/compass4nfv/docs/release/userguide/index
+   ../submodules/compass4nfv/docs/development/design/index
+   ../submodules/compass4nfv/docs/development/manuals/index
+
+
+Copper
+------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/copper/docs/development/overview/index
+   ../submodules/copper/docs/development/requirements/index
+   ../submodules/copper/docs/release/installation/index
+   ../submodules/copper/docs/release/configguide/index
+   ../submodules/copper/docs/release/userguide/index
+   ../submodules/copper/docs/development/design/index
+   ../submodules/copper/docs/development/manuals/index
+
+
+Daisy4NFV
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/daisy/docs/development/design/index
+   ../submodules/daisy/docs/release/configguide/index
+   ../submodules/daisy/docs/release/installation/index
+
+
+Doctor
+------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/doctor/docs/development/overview/index
+   ../submodules/doctor/docs/development/requirements/index
+   ../submodules/doctor/docs/release/installation/index
+   ../submodules/doctor/docs/release/configguide/index
+   ../submodules/doctor/docs/release/userguide/index
+   ../submodules/doctor/docs/development/design/index
+   ../submodules/doctor/docs/development/manuals/index
+
+
+Domino
+------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/domino/docs/development/overview/index
+   ../submodules/domino/docs/development/requirements/index
+   ../submodules/domino/docs/release/installation/index
+   ../submodules/domino/docs/release/configguide/index
+   ../submodules/domino/docs/release/userguide/index
+   ../submodules/domino/docs/development/design/index
+   ../submodules/domino/docs/development/manuals/index
+
+
+IPV6
+----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/ipv6/docs/development/overview/index
+   ../submodules/ipv6/docs/development/requirements/index
+   ../submodules/ipv6/docs/release/installation/index
+   ../submodules/ipv6/docs/release/configguide/index
+   ../submodules/ipv6/docs/release/userguide/index
+   ../submodules/ipv6/docs/development/design/index
+   ../submodules/ipv6/docs/development/manuals/index
+
+
+Joid
+----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/joid/docs/development/overview/index
+   ../submodules/joid/docs/development/requirements/index
+   ../submodules/joid/docs/release/installation/index
+   ../submodules/joid/docs/release/configguide/index
+   ../submodules/joid/docs/release/userguide/index
+   ../submodules/joid/docs/development/design/index
+   ../submodules/joid/docs/development/manuals/index
+
+
+Kvmfornfv
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/kvmfornfv/docs/development/overview/index
+   ../submodules/kvmfornfv/docs/development/requirements/index
+   ../submodules/kvmfornfv/docs/release/installation/index
+   ../submodules/kvmfornfv/docs/release/configguide/index
+   ../submodules/kvmfornfv/docs/release/userguide/index
+   ../submodules/kvmfornfv/docs/development/design/index
+   ../submodules/kvmfornfv/docs/development/manuals/index
+
+
+Multisite
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/multisite/docs/development/overview/index
+   ../submodules/multisite/docs/development/requirements/index
+   ../submodules/multisite/docs/release/installation/index
+   ../submodules/multisite/docs/release/configguide/index
+   ../submodules/multisite/docs/release/userguide/index
+   ../submodules/multisite/docs/development/design/index
+   ../submodules/multisite/docs/development/manuals/index
+
+
+Netready
+--------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/netready/docs/development/overview/index
+   ../submodules/netready/docs/development/requirements/index
+   ../submodules/netready/docs/release/installation/index
+   ../submodules/netready/docs/release/configguide/index
+   ../submodules/netready/docs/release/userguide/index
+   ../submodules/netready/docs/development/design/index
+   ../submodules/netready/docs/development/manuals/index
+
+
+Opera
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/opera/docs/development/overview/index
+   ../submodules/opera/docs/development/requirements/index
+   ../submodules/opera/docs/release/installation/index
+   ../submodules/opera/docs/release/configguide/index
+   ../submodules/opera/docs/release/userguide/index
+   ../submodules/opera/docs/development/design/index
+   ../submodules/opera/docs/development/manuals/index
+
+
+Parser
+------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/parser/docs/development/overview/index
+   ../submodules/parser/docs/development/requirements/index
+   ../submodules/parser/docs/release/installation/index
+   ../submodules/parser/docs/release/configguide/index
+   ../submodules/parser/docs/release/userguide/index
+   ../submodules/parser/docs/development/design/index
+   ../submodules/parser/docs/development/manuals/index
+
+
+Promise
+-------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/promise/docs/development/overview/index
+   ../submodules/promise/docs/development/requirements/index
+   ../submodules/promise/docs/release/installation/index
+   ../submodules/promise/docs/release/configguide/index
+   ../submodules/promise/docs/release/userguide/index
+   ../submodules/promise/docs/development/design/index
+   ../submodules/promise/docs/development/manuals/index
+
+
+SDNVPN
+--------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/sdnvpn/docs/development/overview/index
+   ../submodules/sdnvpn/docs/development/requirements/index
+   ../submodules/sdnvpn/docs/release/installation/index
+   ../submodules/sdnvpn/docs/release/configguide/index
+   ../submodules/sdnvpn/docs/release/userguide/index
+   ../submodules/sdnvpn/docs/development/design/index
+
+
+SFC
+---
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/sfc/docs/development/overview/index
+   ../submodules/sfc/docs/development/requirements/index
+   ../submodules/sfc/docs/release/installation/index
+   ../submodules/sfc/docs/release/configguide/index
+   ../submodules/sfc/docs/release/userguide/index
+   ../submodules/sfc/docs/development/design/index
+   ../submodules/sfc/docs/development/manuals/index
+
diff --git a/docs/glossary/index.rst b/docs/glossary/index.rst
new file mode 100644
index 0000000..be5b6d7
--- /dev/null
+++ b/docs/glossary/index.rst
@@ -0,0 +1,117 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Christopher Price (Ericsson AB)
+
+**************
+OPNFV Glossary
+**************
+
+========
+Contents
+========
+
+This glossary provides a common definition of phrases and words commonly used in OPNFV.
+
+--------
+
+A
+-
+
+Arno
+
+  A river running through Tuscany and the name of the first OPNFV release.
+
+API
+    Application Programming Interface
+
+--------
+
+B
+-
+
+Brahmaputra
+
+  A river running through Asia and the name of the Second OPNFV release.
+
+--------
+
+C
+-
+
+Colorado
+
+  A river in Argentina and the name of the Third OPNFV release.
+
+--------
+
+D
+-
+
+DPDK
+
+  Data Plane Development Kit
+
+DPI
+
+  Deep Packet Inspection
+
+DSCP
+
+  Differentiated Services Code Point
+
+--------
+
+I
+-
+
+IGMP
+
+  Internet Group Management Protocol
+
+IOPS
+
+  Input/Output Operations Per Second
+
+--------
+
+N
+-
+
+NFV
+
+  Network Functions Virtualisation, an industry initiative to leverage virtualisation technologies in carrier networks.
+
+NFVI
+
+  Network Function Virtualization Infrastructure
+
+NIC
+
+  Network Interface Controller
+
+--------
+
+O
+-
+
+OPNFV
+
+  Open Platform for NFV, an open source project developing an NFV reference platform and features.
+
+--------
+
+V
+-
+
+VLAN
+
+  A virtual local area network, typically an isolated ethernet network.
+
+VM
+
+  Virtual machine, an emulation in software of a computer system.
+
+VNF
+
+  Virtual network function, typically a networking application or function running in a virtual environment.
+
diff --git a/docs/how-to-use-docs/Submodules.jpg b/docs/how-to-use-docs/Submodules.jpg
new file mode 100644
index 0000000..aeb7956
--- /dev/null
+++ b/docs/how-to-use-docs/Submodules.jpg
diff --git a/docs/how-to-use-docs/addendum.rst b/docs/how-to-use-docs/addendum.rst
new file mode 100644
index 0000000..90ab1c7
--- /dev/null
+++ b/docs/how-to-use-docs/addendum.rst
@@ -0,0 +1,80 @@
+========
+Addendum
+========
+
+Index File
+==========
+
+The index file must relatively refence your other rst files in that directory.
+
+Here is an example index.rst :
+
+.. code-block:: bash
+
+    *******************
+    Documentation Title
+    *******************
+
+    .. toctree::
+       :numbered:
+       :maxdepth: 2
+
+       documentation-example
+
+Source Files
+============
+
+Document source files have to be written in reStructuredText format (rst).
+Each file would be build as an html page.
+
+Here is an example source rst file :
+
+.. code-block:: bash
+
+    =============
+    Chapter Title
+    =============
+
+    Section Title
+    =============
+
+    Subsection Title
+    ----------------
+
+    Hello!
+
+Writing RST Markdown
+====================
+
+See http://sphinx-doc.org/rest.html .
+
+**Hint:**
+You can add dedicated contents by using 'only' directive with build type
+('html' and 'singlehtml') for OPNFV document. But, this is not encouraged to
+use since this may make different views.
+
+.. code-block:: bash
+
+    .. only:: html
+        This line will be shown only in html version.
+
+Verify Job
+----------
+
+The verify job name is **docs-verify-rtd-{branch}**.
+
+When you send document changes to gerrit, jenkins will create your documents
+in HTML formats (normal and single-page) to verify that new document can be
+built successfully. Please check the jenkins log and artifact carefully.
+You can improve your document even though if the build job succeeded.
+
+Merge Job
+----------
+
+The merge job name is **docs-merge-rtd-{branch}**.
+
+Once the patch is merged, jenkins will automatically trigger building of
+the new documentation. This might take about 15 minutes while readthedocs
+builds the documentatation. The newly built documentation shall show up
+as appropriate placed in docs.opnfv.org/{branch}/path-to-file.
+
diff --git a/docs/how-to-use-docs/documentation-guide.rst b/docs/how-to-use-docs/documentation-guide.rst
new file mode 100644
index 0000000..fed42a4
--- /dev/null
+++ b/docs/how-to-use-docs/documentation-guide.rst
@@ -0,0 +1,135 @@
+===================
+Documentation Guide
+===================
+
+This page intends to cover the documentation handling for OPNFV. OPNFV projects are expected to create a variety of document types,
+according to the nature of the project. Some of these are common to projects that develop/integrate features into the OPNFV platform, e.g.
+Installation Instructions and User/Configurations Guides. Other document types may be project-specific.
+
+.. contents::
+   :depth: 3
+   :local:
+
+Getting Started with Documentation for Your Project
+---------------------------------------------------
+OPNFV documentation is automated and integrated into our git & gerrit toolchains.
+
+We use RST document templates in our repositories and automatically render to HTML and PDF versions of the documents in our artifact
+store, our WiKi is also able to integrate these rendered documents directly allowing projects to use the revision controlled documentation
+process for project information, content and deliverables.
+Read :ref:`this page <include-documentation>` which elaborates on how documentation is to be included within opnfvdocs.
+
+Licencing your documentation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+All contributions to the OPNFV project are done in accordance with the OPNFV licensing requirements. Documentation in OPNFV is contributed
+in accordance with the `Creative Commons 4.0 <https://creativecommons.org/licenses/by/4.0/>`_  and the `SPDX https://spdx.org/>`_ licence.
+All documentation files need to be licensed using the text below. The license may be applied in the first lines of
+all contributed RST files:
+
+.. code-block:: bash
+
+ .. This work is licensed under a Creative Commons Attribution 4.0 International License.
+ .. SPDX-License-Identifier: CC-BY-4.0
+ .. (c) <optionally add copywriters name>
+
+ These lines will not be rendered in the html and pdf files.
+
+How and where to store the document content files in your repository
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+All documentation for your project should be structured and stored in the :code:`<repo>/docs/` directory. The documentation toolchain will
+look in these directories and be triggered on events in these directories when generating documents.
+
+Document structure and contribution
+-----------------------------------
+A general structure is proposed for storing and handling documents that are common across many projects but also for documents that may be
+project specific. The documentation is divided into three areas Release, Development and Testing. Templates for these areas can be found
+under :code:`opnfvdocs/docs/templates/`.
+
+Project teams are encouraged to use templates provided by the opnfvdocs project to ensure that there is consistency across the community.
+Following representation shows the expected structure:
+
+::
+
+        docs/
+        ├── development
+        │   ├── design
+        │   ├── overview
+        │   └── requirements
+        ├── release
+        │   ├── configguide
+        │   ├── installation
+        │   ├── release-notes
+        │   ├── scenarios
+        │   │   └── scenario.name
+        │   └── userguide
+        └── testing
+            ├── developer
+            └── user
+
+
+Release documentation
+^^^^^^^^^^^^^^^^^^^^^
+Release documentation is the set of documents that are published for each OPNFV release. These documents are created and developed
+following the OPNFV release process and milestones and should reflect the content of the OPNFV release.
+These documents have a master index.rst file in the <opnfvdocs> repository and extract content from other repositories.
+To provide content into these documents place your <content>.rst files in a directory in your repository that matches the master document
+and add a reference to that file in the correct place in the corresponding index.rst file in :code:`opnfvdocs/docs/release/`.
+
+**Platform Overview**: :code:`opnfvdocs/docs/release/overview`
+
+- Note this document is not a contribution driven document
+- Content for this is prepared by the Marketing team together with the opnfvdocs team
+
+**Installation Instruction**: :code:`<repo>/docs/release/installation`
+
+- Folder for documents describing how to deploy each installer and scenario descriptions
+- Release notes will be included here <To Confirm>
+- Security related documents will be included here
+- Note that this document will be compiled into 'OPNFV Installation Instruction'
+
+**User Guide**: :code:`<repo>/docs/release/userguide`
+
+- Folder for manuals to use specific features
+- Folder for documents describing how to install/configure project specific components and features
+- Can be the directory where API reference for project specific features are stored
+- Note this document will be compiled into 'OPNFV userguide'
+
+**Configuration Guide**: :code:`<repo>/docs/release/configguide`
+
+- Brief introduction to configure OPNFV with its dependencies.
+
+**Release Notes**: :code:`<repo>/docs/release/release-notes`
+
+- Changes brought about in the release cycle.
+- Include version details.
+
+Testing documentation
+^^^^^^^^^^^^^^^^^^^^^
+Documentation created by test projects can be stored under two different sub directories /user or /developemnt.
+Release notes will be stored under <repo>/docs/release/release-notes
+
+**User documentation**: :code:`<repo>/testing/user/`
+Will collect the documentation of the test projects allowing the end user to perform testing towards a OPNFV SUT
+e.g. Functest/Yardstick/Vsperf/Storperf/Bottlenecks/Qtip installation/config & user guides.
+
+**Development documentation**: :code:`<repo>/testing/developent/`
+Will collect documentation to explain how to create your own test case and leverage existing testing frameworks e.g. developer guides.
+
+Development Documentation
+^^^^^^^^^^^^^^^^^^^^^^^^^
+Project specific documents such as design documentation, project overview or requirement documentation can be stored under
+/docs/development. Links to generated documents will be dislayed under Development Documentaiton section on docs.opnfv.org.
+You are encouraged to establish the following basic structure for your project as needed:
+
+**Requirement Documentation**: :code:`<repo>/docs/development/requirements/`
+
+- Folder for your requirement documentation
+- For details on requirements projects' structures see the `Requirements Projects <https://wiki.opnfv.org/display/PROJ/Requirements+Projects>`_ page.
+
+**Design Documentation**: :code:`<repo>/docs/development/design`
+
+- Folder for your upstream design documents (blueprints, development proposals, etc..)
+
+**Project overview**: :code:`<repo>/docs/development/overview`
+
+- Folder for any project specific documentation.
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 0000000..d1a5a62
--- /dev/null
+++ b/docs/how-to-use-docs/include-documentation.rst
@@ -0,0 +1,254 @@
+.. _include-documentation:
+============================
+Including your Documentation
+============================
+
+.. contents::
+   :depth: 3
+   :local:
+
+In your project repository
+--------------------------
+
+Add your documentation to your repository in the folder structure and
+according to the templates listed above. The documentation templates you
+will require are available in opnfvdocs/docs/templates/ repository, you should
+copy the relevant templates to your <repo>/docs/ directory in your repository.
+For instance if you want to document userguide, then your steps shall be
+as follows:
+
+.. code-block:: bash
+
+   git clone ssh://<your_id>@gerrit.opnfv.org:29418/opnfvdocs.git
+   cp -p opnfvdocs/docs/userguide/* <my_repo>/docs/userguide/
+
+
+You should then add the relevant information to the template that will
+explain the documentation. When you are done writing, you can commit
+the documentation to the project repository.
+
+.. code-block:: bash
+
+   git add .
+   git commit --signoff --all
+   git review
+
+In OPNFVDocs Composite Documentation
+------------------------------------
+
+In toctree
++++++++++++
+
+To import project documents from project repositories, we use submodules.
+ Each project is stored in :code:`opnfvdocs/docs/submodule/` as follows:
+
+.. image:: Submodules.jpg
+   :scale: 50 %
+
+To include your project specific documentation in the composite documentation,
+first identify where your project documentation should be included.
+Say your project userguide should figure in the ‘OPNFV Userguide’, then:
+
+
+.. code-block:: bash
+
+   vim opnfvdocs/docs/release/userguide.introduction.rst
+
+This opens the text editor. Identify where you want to add the userguide.
+If the userguide is to be added to the toctree, simply include the path to
+it, example:
+
+
+.. code-block:: bash
+
+   .. toctree::
+       :maxdepth: 1
+
+    submodules/functest/docs/userguide/index
+    submodules/bottlenecks/docs/userguide/index
+    submodules/yardstick/docs/userguide/index
+    <submodules/path-to-your-file>
+
+As Hyperlink
+++++++++++++
+
+It's pretty common to want to reference another location in the
+OPNFV documentation and it's pretty easy to do with
+reStructuredText. This is a quick primer, more information is in the
+`Sphinx section on Cross-referencing arbitrary locations
+<http://www.sphinx-doc.org/en/stable/markup/inline.html#ref-role>`_.
+
+Within a single document, you can reference another section simply by::
+
+   This is a reference to `The title of a section`_
+
+Assuming that somewhere else in the same file there a is a section
+title something like::
+
+   The title of a section
+   ^^^^^^^^^^^^^^^^^^^^^^
+
+It's typically better to use ``:ref:`` syntax and labels to provide
+links as they work across files and are resilient to sections being
+renamed. First, you need to create a label something like::
+
+   .. _a-label:
+
+   The title of a section
+   ^^^^^^^^^^^^^^^^^^^^^^
+
+.. note:: The underscore (_) before the label is required.
+
+Then you can reference the section anywhere by simply doing::
+
+    This is a reference to :ref:`a-label`
+
+or::
+
+    This is a reference to :ref:`a section I really liked <a-label>`
+
+.. note:: When using ``:ref:``-style links, you don't need a trailing
+          underscore (_).
+
+Because the labels have to be unique, it usually makes sense to prefix
+the labels with the project name to help share the label space, e.g.,
+``sfc-user-guide`` instead of just ``user-guide``.
+
+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.
+
+'doc8' Validation
+-----------------
+It is recommended that all rst content is validated by `doc8 <https://pypi.python.org/pypi/doc8>`_ standards.
+To validate your rst files using doc8, install doc8.
+
+.. code-block:: bash
+
+   sudo pip install doc8
+
+doc8 can now be used to check the rst files. Execute as,
+
+.. code-block:: bash
+
+   doc8 --ignore D000,D001 <file>
+
+
+Testing: Build Documentation Locally
+------------------------------------
+
+Composite OPNFVDOCS documentation
++++++++++++++++++++++++++++++++++
+To build whole documentation under opnfvdocs/, follow these steps:
+
+Install virtual environment.
+
+.. code-block:: bash
+
+   sudo pip install virtualenv
+   cd /local/repo/path/to/project
+
+Download the OPNFVDOCS repository.
+
+.. code-block:: bash
+
+   git clone https://gerrit.opnfv.org/gerrit/opnfvdocs
+
+Change directory to opnfvdocs & install requirements.
+
+.. code-block:: bash
+
+   cd opnfvdocs
+   sudo pip install -r etc/requirements.txt
+
+Update submodules, build documentation using tox & then open using any browser.
+
+.. code-block:: bash
+
+   cd opnfvdocs
+   git submodule update --init
+   tox -edocs
+   firefox docs/_build/html/index.html
+
+.. note:: Make sure to run `tox -edocs` and not just `tox`.
+
+Individual project documentation
+++++++++++++++++++++++++++++++++
+To test how the documentation renders in HTML, follow these steps:
+
+Install virtual environment.
+
+.. code-block:: bash
+
+   sudo pip install virtualenv
+   cd /local/repo/path/to/project
+
+Download the opnfvdocs repository.
+
+.. code-block:: bash
+
+   git clone https://gerrit.opnfv.org/gerrit/opnfvdocs
+
+Change directory to opnfvdocs & install requirements.
+
+.. code-block:: bash
+
+   cd opnfvdocs
+   sudo pip install -r etc/requirements.txt
+
+Move the conf.py file to your project folder where RST files have been kept:
+
+.. code-block:: bash
+
+   mv opnfvdocs/docs/conf.py <path-to-your-folder>/
+
+Move the static files to your project folder:
+
+.. code-block:: bash
+
+   mv opnfvdocs/_static/ <path-to-your-folder>/
+
+Build the documentation from within your project folder:
+
+.. code-block:: bash
+
+   sphinx-build -b html <path-to-your-folder> <path-to-output-folder>
+
+Your documentation shall be built as HTML inside the
+specified output folder directory.
+
+.. note:: Be sure to remove the `conf.py`, the static/ files and the output folder from the `<project>/docs/`. This is for testing only. Only commit the rst files and related content.
+
+
+Adding your project repository as a submodule
+--------------------------
+
+Clone the opnfvdocs repository and your submodule to .gitmodules following the convention of the file
+
+.. code-block:: bash
+
+  cd docs/submodules/
+  git submodule add https://gerrit.opnfv.org/gerrit/$reponame
+  git submodule init $reponame/
+  git submodule update $reponame/
+  git add .
+  git commit -sv
+  git review
+
+Removing a project repository as a submodule
+--------------------------
+  git rm docs/submodules/$reponame
+  rm -rf .git/modules/$reponame
+  git config -f .git/config --remove-section submodule.$reponame 2> /dev/null
+  git add .
+  git commit -sv
+  git review
+
diff --git a/docs/how-to-use-docs/index.rst b/docs/how-to-use-docs/index.rst
new file mode 100644
index 0000000..424f471
--- /dev/null
+++ b/docs/how-to-use-docs/index.rst
@@ -0,0 +1,12 @@
+.. _documentation-guide:
+
+===================
+Documentation Guide
+===================
+
+.. toctree::
+   :maxdepth: 2
+
+   documentation-guide
+   include-documentation
+   addendum
diff --git a/docs/images/OPNFV_testing_working_group.png b/docs/images/OPNFV_testing_working_group.png
new file mode 100644
index 0000000..f1688cf
--- /dev/null
+++ b/docs/images/OPNFV_testing_working_group.png
diff --git a/docs/images/opnfvplatformgraphic.png b/docs/images/opnfvplatformgraphic.png
new file mode 100644
index 0000000..8039bcd
--- /dev/null
+++ b/docs/images/opnfvplatformgraphic.png
diff --git a/docs/images/reporting_danube_page.png b/docs/images/reporting_danube_page.png
new file mode 100644
index 0000000..50bbf60
--- /dev/null
+++ b/docs/images/reporting_danube_page.png
diff --git a/docs/images/reporting_page.png b/docs/images/reporting_page.png
new file mode 100644
index 0000000..d8f46a4
--- /dev/null
+++ b/docs/images/reporting_page.png
diff --git a/docs/index.rst b/docs/index.rst
new file mode 100644
index 0000000..c5ca836
--- /dev/null
+++ b/docs/index.rst
@@ -0,0 +1,52 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+
+OPNFV Documentation
+===================
+
+Open Platform for NFV (OPNFV) facilitates the development and evolution
+of NFV components across various open source ecosystems. Through
+system level integration, deployment and testing, OPNFV creates a
+reference NFV platform to accelerate the transformation of enterprise
+and service provider networks. Participation is open to anyone,
+whether you are an employee of a member company or just passionate
+about network transformation.
+
+Release
+-------
+
+.. toctree::
+   :maxdepth: 1
+
+   release/overview
+   release/installation.introduction
+   release/userguide.introduction
+   release/release-notes
+
+
+Test Frameworks
+---------------
+
+.. toctree::
+   :maxdepth: 1
+
+   testing/ecosystem/index
+   testing/testing-user
+   testing/testing-dev
+
+
+Developer
+---------
+
+.. toctree::
+   :maxdepth: 1
+
+   how-to-use-docs/index
+   featureprojects
+
+
+Infrastructure
+--------------
+
+.. toctree::
+   :maxdepth: 1
diff --git a/docs/pre-hook.sh b/docs/pre-hook.sh
new file mode 100755
index 0000000..6574cdc
--- /dev/null
+++ b/docs/pre-hook.sh
@@ -0,0 +1,113 @@
+#!/bin/bash
+# SPDX-license-identifier: Apache-2.0
+##############################################################################
+# Copyright (c) 2016 NEC and others.
+# All rights reserved. This program and the accompanying materials
+# are made available under the terms of the Apache License, Version 2.0
+# which accompanies this distribution, and is available at
+# http://www.apache.org/licenses/LICENSE-2.0
+##############################################################################
+
+GIT_CLONE_BASE=${GIT_CLONE_BASE:-ssh://gerrit.opnfv.org:29418}
+GERRIT_BRANCH=${GERRIT_BRANCH:-master}
+WORKSPACE=${WORKSPACE:-.}
+
+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 "apex"
+    echo "bottlenecks"
+    echo "compass4nfv"
+    echo "copper"
+    echo "daisy"
+    echo "doctor"
+    echo "fastpathmetrics"
+    echo "fuel"
+    echo "functest"
+    echo "ipv6"
+    echo "joid"
+    echo "ovsnfv"
+    echo "pharos"
+    echo "prediction"
+    echo "promise"
+    echo "sdnvpn"
+    echo "vswitchperf"
+    echo "yardstick"
+}
+
+git_clone() {
+    _repo="$1"
+
+    [[ -d "$WORKSPACE/$_repo" ]] && return 0
+    pushd $WORKSPACE
+    git clone -b $GERRIT_BRANCH --depth 1 --quiet $GIT_CLONE_BASE/$_repo
+    popd
+}
+
+repos=$(get_repo_names)
+
+[[ -e docs/projects ]] && rm -rf docs/projects
+mkdir -p docs/projects
+
+echo
+echo "Cloning repos of participating OPNFV Projects and copying docs"
+echo
+for repo in $repos; do
+    echo "    $repo ($GERRIT_BRANCH)"
+    git_clone $repo
+    [[ -e $WORKSPACE/$repo/docs ]] || continue
+    [[ -e docs/projects/$repo ]] && rm -rf docs/projects/$repo
+    cp -r $WORKSPACE/$repo/docs docs/projects/$repo
+done
+
+# NOTE: Removing index.rst in project repos to reduce number of docs.
+find docs/projects -type f -name 'index.rst' -print | xargs -I i rm -f i
+
+# fix relative file paths
+pattern='.. \(include\|figure\):: *[^ \/]'
+base_path="/$(pwd)/docs_build/_src"
+find docs/projects -type f -name '*.rst' -print | while read f
+do
+    sed -i -e "/$pattern/s|:: *|:: $base_path/$(dirname ${f#docs/})/|" $f
+done
+
+# for debug
+grep -e '.. include::' -e '.. figure::' -r docs/projects
+
+# NOTE: automated link generation is not ready...
+echo
+echo "Creating document links"
+echo
+targets="
+configurationguide/configuration.options.render.rst
+configurationguide/scenario.description.rst
+userguide/feature.userguide.render.rst
+testframework/framework.installation.procedure.render.rst
+testframework/framework.userguide.render.rst
+"
+# configurationguide/post-install.rst
+for guide in $targets
+do
+    mainfile="$WORKSPACE/docs/$guide"
+    basefilename=$(basename ${guide/-/})
+    for repo in $repos
+    do
+        targetfile="$WORKSPACE/docs/projects/$repo/${guide/-/}"
+        targetlink="../projects/$repo/${guide/-/}"
+        projectfilename="${basefilename/.rst/-$repo.rst}"
+        projectfile="$(dirname $mainfile)/$projectfilename"
+        [[ -e "$targetfile" ]] || continue
+        echo "Adding $repo to $guide ..."
+        echo "" >> $mainfile
+        echo ".. toctree::" >> $mainfile
+        echo "" >> $mainfile
+        echo "    $projectfilename" >> $mainfile
+        echo ".. include:: $targetlink" > $projectfile
+    done
+    echo
+    echo "Generated $guide:"
+    cat $mainfile
+    echo
+done
diff --git a/docs/release/installation.introduction.rst b/docs/release/installation.introduction.rst
new file mode 100644
index 0000000..cc43aa1
--- /dev/null
+++ b/docs/release/installation.introduction.rst
@@ -0,0 +1,100 @@
+.. _opnfv-installation:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) Sofia Wallin Ericsson AB
+
+=============
+Installation
+=============
+
+Abstract
+========
+
+This document provides an overview of the installation of the Danube release of OPNFV.
+
+The Danube release can be installed making use of any of the installer projects in OPNFV:
+Apex, Compass4Nfv, Fuel or JOID.  Each installer provides the ability to install a common OPNFV
+platform as well as integrating additional features delivered through a variety of scenarios by
+the OPNFV community.
+
+
+Introduction
+============
+
+The OPNFV platform is comprised of a variety of upstream components that may be deployed on your
+infrastructure.  A composition of components, tools and configurations is identified in OPNFV as a
+deployment scenario.
+
+The various OPNFV scenarios provide unique features and capabilities that you may want to leverage, and
+it is important to understand your required target platform capabilities before installing and
+configuring your scenarios.
+
+An OPNFV installation requires either a physical infrastructure environment as defined
+in the `Pharos specification <https://wiki.opnfv.org/display/pharos/Pharos+Specification>`_, or a virtual one.
+When configuring a physical infrastructure it is strongly advised to follow the Pharos configuration guidelines.
+
+
+Scenarios
+=========
+
+OPNFV scenarios are designed to host virtualised network functions (VNF’s) in a variety of deployment
+architectures and locations. Each scenario provides specific capabilities and/or components aimed at
+solving specific problems for the deployment of VNF’s.
+
+A scenario may, for instance, include components such as OpenStack, OpenDaylight, OVS, KVM etc.,
+where each scenario will include different source components or configurations.
+
+To learn more about the scenarios supported in the Danube release refer to the scenario
+description documents provided:
+
+- :ref:`os-nosdn-kvm-ha <kvmfornfv-os-nosdn-kvm-ha>`
+- :ref:`os-nosdn-kvm_ovs_dpdk-noha <kvmfornfv-os-nosdn-kvm_nfv_ovs_dpdk-noha>`
+- :ref:`os-nosdn-kvm_ovs_dpdk_bar-noha <kvmfornfv-os-nosdn-kvm_nfv_ovs_dpdk_bar-noha>`
+- :ref:`os-odl_l3-fdio-noha <os-odl_l3-fdio-noha>`
+- :ref:`os-odl_l2-fdio-ha <os-odl_l2-fdio-ha>`
+- :ref:`os-odl_l2-fdio-noha <os-odl_l2-fdio-noha>`
+- :ref:`os-nosdn-fdio-noha <os-nosdn-fdio-noha>`
+- :ref:`os-odl_l2-bgpvpn-noha <sdnvpn-os-odl_l2-bgpvpn-noha>`
+- :ref:`os-odl_l2-bgpvpn-ha <sdnvpn-os-odl_l2-bgpvpn-ha>`
+- :ref:`os-odl-gluon-noha <gluon-scenario>`
+- :ref:`os-nosdn-openo-ha <opera-os-nosdn-openo-ha>`
+- `os-odl_l2-sfc-ha <http://docs.opnfv.org/en/stable-danube/submodules/sfc/docs/release/scenarios/os-odl_l2-sfc-ha/index.html>`_
+- `os-odl_l2-sfc-noha <http://docs.opnfv.org/en/stable-danube/submodules/sfc/docs/release/scenarios/os-odl_l2-sfc-noha/index.html>`_
+- :ref:`os-nosdn-lxd-ha <os-nosdn-lxd-ha>`
+- :ref:`os-nosdn-lxd-noha <os-nosdn-lxd-noha>`
+- :ref:`k8-nosdn-nofeature-noha <k8-nosdn-nofeature-noha>`
+- :ref:`k8-nosdn-lb-noha <k8-nosdn-lb-noha>`
+- `os-nosdn-ovs-ha <http://docs.opnfv.org/en/stable-danube/submodules/ovsnfv/docs/release/scenarios/os-nosdn-ovs-ha/index.html>`_
+- :ref:`os-nosdn-ovs-noha <os-nosdn-ovs-noha>`
+- :ref:`os-nosdn-ovs <os-nosdn-ovs>`
+- `os-odl_l3-ovs-ha <http://docs.opnfv.org/en/stable-danube/submodules/ovsnfv/docs/release/scenarios/os-odl_l3-ovs-ha/index.html>`_
+- :ref:`os-odl_l3-ovs-noha <os-odl_l3-ovs-noha>`
+- :ref:`os-odl_l3-fdio-ha <os-odl_l3-fdio-ha>`
+
+
+Installation Procedure
+======================
+
+Detailed step by step instructions for working with an installation toolchain and installing
+the required scenario are provided by the installation projects.  The four projects providing installation
+support for the OPNFV Danube release are: Apex, Compass4nfv, Fuel and JOID.
+
+The instructions for each toolchain can be found in these links:
+
+- :ref:`Apex installation instruction <apex-installation>`
+- :ref:`Compass4nfv installation instruction <compass4nfv-installation>`
+- :ref:`Daisy installation instruction <daisy-installation>`
+- :ref:`Fuel installation instruction <fuel-installation>`
+- :ref:`JOID installation instruction <joid-installation>`
+
+OPNFV Test Frameworks
+=====================
+
+If you have elected to install the OPNFV platform using the deployment toolchain provided by OPNFV
+your system will have been validated once the installation is completed.
+The basic deployment validation only addresses a small part of capabilities provided in
+the platform and you may want to execute more exhaustive tests.  Some investigation will be required to
+select the right test suites to run on your platform.
+
+Many of the OPNFV test project provide user-guide documentation and installation instructions in :ref:`this document <testing-userguide>`
diff --git a/docs/release/overview.rst b/docs/release/overview.rst
new file mode 100644
index 0000000..7e1d136
--- /dev/null
+++ b/docs/release/overview.rst
@@ -0,0 +1,296 @@
+.. _opnfv-overview:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) Open Platform for NFV Project, Inc. and its contributors
+
+================
+Platform overview
+================
+
+Introduction
+============
+
+Network Functions Virtualization (NFV) is transforming the networking industry via
+software-defined infrastructures and open source is the proven method for quickly developing
+software for commercial products and services that can move markets.
+Open Platform for NFV (OPNFV) facilitates the development and evolution of NFV
+components across various open source ecosystems. Through system level integration,
+deployment and testing, OPNFV constructs a reference NFV platform to accelerate the
+transformation of enterprise and service provider networks.
+As an open source project, OPNFV is uniquely positioned to bring together the work
+of standards bodies, open source communities, service providers and commercial suppliers to deliver
+a de facto NFV platform for the industry.
+
+By integrating components from upstream projects, the community is able to conduct performance
+and use case-based testing on a variety of solutions to ensure the platform’s suitability for
+NFV use cases. OPNFV also works upstream with other open source communities to bring contributions
+and learnings from its work directly to those communities in the form of blueprints, patches, bugs,
+and new code.
+
+OPNFV initially focused on building NFV Infrastructure (NFVI) and Virtualised Infrastructure
+Management (VIM) by integrating components from upstream projects such as OpenDaylight,
+OpenStack, Ceph Storage, KVM, Open vSwitch, and Linux.
+More recently, OPNFV has extended its portfolio of forwarding solutions to include fd.io and ODP,
+is able to run on both Intel and ARM commercial and white-box hardware, support VM, Container and
+BareMetal workloads, and includes Management and Network Orchestration MANO components primarily
+for application composition and management in the Danube release.
+
+These capabilities, along with application programmable interfaces (APIs) to other NFV
+elements, form the basic infrastructure required for Virtualized Network Functions (VNF)
+and MANO components.
+
+Concentrating on these components while also considering proposed projects on additional
+topics (such as the MANO components and applications themselves), OPNFV aims to enhance
+NFV services by increasing performance and power efficiency improving reliability,
+availability and serviceability, and delivering comprehensive platform instrumentation.
+
+
+OPNFV Platform Architecture
+===========================
+
+The OPNFV project addresses a number of aspects in the development of a consistent virtualisation
+platform including common hardware requirements, software architecture, MANO and applications.
+
+
+OPNFV Platform Overview Diagram
+
+.. image:: ../images/opnfvplatformgraphic.png
+   :alt: Overview infographic of the opnfv platform and projects.
+
+
+To address these areas effectively, the OPNFV platform architecture can be decomposed
+into the following basic building blocks:
+
+* Hardware: with the Infra working group, Pharos project and associated activities
+* Software Platform: through the platform integration and deployment projects
+* MANO: through the MANO working group and associated projects
+* Applications: which affect all other areas and drive requirements for OPNFV
+
+OPNFV Lab Infrastructure
+========================
+
+The infrastructure working group oversees such topics as lab management, workflow,
+definitions, metrics and tools for OPNFV infrastructure.
+
+Fundamental to the WG is the
+`Pharos Specification <https://wiki.opnfv.org/display/pharos/Pharos+Specification>`_
+which provides a set of defined lab infrastructures over a geographically and technically
+diverse federated global OPNFV lab.
+
+Labs may instantiate bare-metal and virtual environments that are accessed remotely by the
+community and used for OPNFV platform and feature development, build, deploy and testing.
+No two labs are the same and the heterogeneity of the Pharos environment provides the ideal
+platform for establishing hardware and software abstractions providing well understood
+performance characteristics.
+
+Community labs are hosted by OPNFV member companies on a voluntary basis.
+The Linux Foundation also hosts an OPNFV lab that provides centralized CI
+and other production resources which are linked to community labs.
+Future lab capabilities will include the ability easily automate deploy and test of any
+OPNFV install scenario in any lab environment as well as on a nested "lab as a service"
+virtual infrastructure.
+
+OPNFV Software Platform Architecture
+====================================
+
+The OPNFV software platform is comprised exclusively of open source implementations of
+platform component pieces.  OPNFV is able to draw from the rich ecosystem of NFV related
+technologies available in open-source then integrate, test, measure and improve these
+components in conjunction with our source communities.
+
+While the composition of the OPNFV software platform is highly complex and constituted of many
+projects and components, a subset of these projects gain the most attention from the OPNFV community
+to drive the development of new technologies and capabilities.
+
+---------------------------------
+Virtual Infrastructure Management
+---------------------------------
+
+OPNFV derives it's virtual infrastructure management from one of our largest upstream ecosystems
+OpenStack.  OpenStack provides a complete reference cloud management system and associated technologies.
+While the OpenStack community sustains a broad set of projects, not all technologies are relevant in
+an NFV domain, the OPNFV community consumes a sub-set of OpenStack projects where the usage and
+composition may vary depending on the installer and scenario.
+
+For details on the scenarios available in OPNFV and the specific composition of components
+refer to the :ref:`OPNFV User Guide & Configuration Guide <opnfv-user-config>`
+
+-----------------
+Operating Systems
+-----------------
+
+OPNFV currently uses Linux on all target machines, this can include Ubuntu, Centos or SUSE linux. The
+specific version of Linux used for any deployment is documented in the installation guide.
+
+-----------------------
+Networking Technologies
+-----------------------
+
+SDN Controllers
+---------------
+
+OPNFV, as an NFV focused project, has a significant investment on networking technologies
+and provides a broad variety of integrated open source reference solutions.  The diversity
+of controllers able to be used in OPNFV is supported by a similarly diverse set of
+forwarding technologies.
+
+There are many SDN controllers available today relevant to virtual environments
+where the OPNFV community supports and contributes to a number of these.  The controllers
+being worked on by the community during this release of OPNFV include:
+
+* Neutron: an OpenStack project to provide “network connectivity as a service” between
+  interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova).
+* OpenDaylight: addresses multivendor, traditional and greenfield networks, establishing the
+  industry’s de facto SDN platform and providing the foundation for networks of the future.
+* ONOS: a carrier-grade SDN network operating system designed for high availability,
+  performance, scale-out.
+
+.. OpenContrail SDN controller is planned to be supported in the next release.
+
+Data Plane
+----------
+
+OPNFV extends Linux virtual networking capabilities by using virtual switching
+and routing components. The OPNFV community proactively engages with these source
+communities to address performance, scale and resiliency needs apparent in carrier
+networks.
+
+* FD.io (Fast data - Input/Output): a collection of several projects and libraries to
+  amplify the transformation that began with Data Plane Development Kit (DPDK) to support
+  flexible, programmable and composable services on a generic hardware platform.
+* Open vSwitch: a production quality, multilayer virtual switch designed to enable
+  massive network automation through programmatic extension, while still supporting standard
+  management interfaces and protocols.
+
+Deployment Architecture
+=======================
+
+A typical OPNFV deployment starts with three controller nodes running in a high availability
+configuration including control plane components from OpenStack, SDN, etc. and a minimum
+of two compute nodes for deployment of workloads (VNFs).
+A detailed description of the hardware requirements required to support the 5 node configuration
+can be found in pharos specification: `Pharos Project <https://www.opnfv.org/developers/pharos>`_
+
+In addition to the deployment on a highly available physical infrastructure, OPNFV can be
+deployed for development and lab purposes in a virtual environment.  In this case each of the hosts
+is provided by a virtual machine and allows control and workload placement using nested virtualization.
+
+The initial deployment is done using a staging server, referred to as the "jumphost".
+This server-either physical or virtual-is first installed with the installation program
+that then installs OpenStack and other components on the controller nodes and compute nodes.
+See the :ref:`OPNFV User Guide & Configuration Guide <opnfv-user-config>` for more details.
+
+
+The OPNFV Testing Ecosystem
+===========================
+
+The OPNFV community has set out to address the needs of virtualization in the carrier
+network and as such platform validation and measurements are a cornerstone to the
+iterative releases and objectives.
+
+To simplify the complex task of feature, component and platform validation and characterization
+the testing community has established a fully automated method for addressing all key areas of
+platform validation. This required the integration of a variety of testing frameworks in our CI
+systems, real time and automated analysis of results, storage and publication of key facts for
+each run as shown in the following diagram.
+
+.. image:: ../images/OPNFV_testing_working_group.png
+  :alt: Overview infographic of the OPNFV testing Ecosystem
+
+Release Verification
+====================
+
+The OPNFV community relies on its testing community to establish release criteria for each OPNFV
+release. Each release cycle the testing criteria become more stringent and better representative
+of our feature and resiliency requirements.
+
+
+As each OPNFV release establishes a set of deployment scenarios to validate, the testing
+infrastructure and test suites need to accommodate these features and capabilities. It’s not
+only in the validation of the scenarios themselves where complexity increases, there are test
+cases that require multiple datacenters to execute when evaluating features, including multisite
+and distributed datacenter solutions.
+
+The release criteria as established by the testing teams include passing a set of test cases
+derived from the functional testing project ‘functest,’ a set of test cases derived from our
+platform system and performance test project ‘yardstick,’ and a selection of test cases for
+feature capabilities derived from other test projects such as bottlenecks, vsperf, cperf and
+storperf. The scenario needs to be able to be deployed, pass these tests, and be removed from
+the infrastructure iteratively (no less that 4 times) in order to fulfil the release criteria.
+
+--------
+Functest
+--------
+
+Functest provides a functional testing framework incorporating a number of test suites
+and test cases that test and verify OPNFV platform functionality.
+The scope of Functest and relevant test cases can be found in the :ref:`Functest User Guide <functest-userguide>`
+
+Functest provides both feature project and component test suite integration, leveraging
+OpenStack and SDN controllers testing frameworks to verify the key components of the OPNFV
+platform are running successfully.
+
+---------
+Yardstick
+---------
+
+Yardstick is a testing project for verifying the infrastructure compliance when running VNF applications.
+Yardstick benchmarks a number of characteristics and performance vectors on the infrastructure making it
+a valuable pre-deployment NFVI testing tools.
+
+Yardstick provides a flexible testing framework for launching other OPNFV testing projects.
+
+There are two types of test cases in Yardstick:
+
+* Yardstick generic test cases and OPNFV feature test cases;
+  including basic characteristics benchmarking in compute/storage/network area.
+* OPNFV feature test cases include basic telecom feature testing from OPNFV projects;
+  for example nfv-kvm, sfc, ipv6, Parser, Availability and SDN VPN
+
+System Evaluation and compliance testing
+========================================
+
+The OPNFV community is developing a set of test suites intended to evaluate a set of reference
+behaviors and capabilities for NFV systems developed externally from the OPNFV ecosystem to
+evaluate and measure their ability to provide the features and capabilities developed in the
+OPNFV ecosystem.
+
+The Dovetail project will provide a test framework and methodology able to be used on any NFV platform,
+including an agreed set of test cases establishing an evaluation criteria for exercising
+an OPNFV compatible system. The Dovetail project has begun establishing the test framework
+and will provide a preliminary methodology for the Danube release. Work will continue to
+develop these test cases to establish a stand alone compliance evaluation solution
+in future releases.
+
+Additional Testing
+==================
+
+Besides the test suites and cases for release verification, additional testing is performed to validate
+specific features or characteristics of the OPNFV platform.
+These testing framework and test cases may include some specific needs; such as extended measurements,
+additional testing stimuli, or tests simulating environmental disturbances or failures.
+
+These additional testing activities provide a more complete evaluation of the OPNFV platform.
+Some of the projects focused on these testing areas include:
+
+------
+VSPERF
+------
+
+VSPERF provides an automated test-framework and comprehensive test suite for measuring data-plane
+performance of the NFVI including switching technology, physical and virtual network interfaces.
+The provided test cases with network topologies can be customized while also allowing individual
+versions of Operating System, vSwitch and hypervisor to be specified.
+
+-----------
+Bottlenecks
+-----------
+
+Bottlenecks provides a framework to find system limitations and bottlenecks, providing
+root cause isolation capabilities to facilitate system evaluation.
+
+
+.. _`OPNFV Configuration Guide`: `OPNFV User Guide & Configuration Guide`
+.. _`OPNFV User Guide`: `OPNFV User Guide & Configuration Guide`
+.. _`Dovetail project`: https://wiki.opnfv.org/display/dovetail
diff --git a/docs/release/release-notes.rst b/docs/release/release-notes.rst
new file mode 100644
index 0000000..2eb74d7
--- /dev/null
+++ b/docs/release/release-notes.rst
@@ -0,0 +1,57 @@
+.. _opnfv-releasenotes:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+==============
+Release Notes
+==============
+
+Release notes as provided by the OPNFV participating documents are captured in this section.
+These include details of software versions used, known limitations and outstanding trouble
+reports.
+
+Project release notes:
+----------------------
+
+:ref:`Apex Release Notes <apex-releasenotes>`
+
+:ref:`Armband Release Notes <armband-release-notes-label>`
+
+:ref:`Bottlenecks Release Notes <bottlenecks-releasenotes>`
+
+:ref:`Compass4nfv Release Notes <compass4nfv-releasenotes>`
+
+:ref:`Copper Release Notes <copper-releasenotes>`
+
+:ref:`Daisy Release Notes <daisy-releasenotes>`
+
+:ref:`Doctor Release Notes <doctor-releasenotes>`
+
+:ref:`FDS Release Notes <fds-releasenotes>`
+
+:ref:`Fuel Release Notes <fuel-releasenotes>`
+
+:ref:`Functest Release Notes <functest-releasenotes>`
+
+:ref:`IPV6 Release Notes <ipv6-releasenotes>`
+
+:ref:`Joid Release Notes <joid-releasenotes>`
+
+:ref:`KVMforNFV Release Notes <kvmfornfv-releasenotes>`
+
+:ref:`Netready Release Notes <netready-releasenotes>`
+
+:ref:`Opera Release Notes <opera-releasenotes>`
+
+:ref:`Parser Release Notes <parser-releasenotes>`
+
+:ref:`QTIP Release Notes <qtip-releasenotes>`
+
+:ref:`SDNVPN Release Notes <sdnvpn-releasenotes>`
+
+:ref:`SFC Release Notes <sfc-releasenotes>`
+
+:ref:`VSPERF Release Notes <vswitchperf-releasenotes>`
+
+:ref:`Yardstick Release Notes <yardstick-releasenotes>`
diff --git a/docs/release/subrelease.rst b/docs/release/subrelease.rst
new file mode 100644
index 0000000..075fcbd
--- /dev/null
+++ b/docs/release/subrelease.rst
@@ -0,0 +1,43 @@
+==================
+Subrelease Guides
+==================
+
+Apex
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/apex/docs/releasenotes/index
+   ../submodules/apex/docs/installationprocedure/index
+
+Compass
+--------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/compass4nfv/docs/releasenotes/index
+   ../submodules/compass4nfv/docs/installationprocedure/index
+
+Daisy
+-------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/daisy/docs/release/release-notes/index
+   ../submodules/daisy/docs/release/installation/index
+
+Fuel
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/fuel/docs/releasenotes/index
+   ../submodules/fuel/docs/installationprocedure/index
+
+Joid
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/joid/docs/releasenotes/index
+   ../submodules/joid/docs/installationprocedure/index
diff --git a/docs/release/userguide.introduction.rst b/docs/release/userguide.introduction.rst
new file mode 100644
index 0000000..8883927
--- /dev/null
+++ b/docs/release/userguide.introduction.rst
@@ -0,0 +1,87 @@
+.. _opnfv-user-config:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) Sofia Wallin (sofia.wallin@ericssion.com)
+
+=================================
+User Guide & Configuration Guide
+=================================
+
+Abstract
+========
+
+OPNFV is a collaborative project aimed at providing a variety of virtualisation
+deployments intended to host applications serving the networking and carrier
+industries. This document provides guidance and instructions for using platform
+features designed to support these applications, made available in the OPNFV
+Danube release.
+
+This document is not intended to replace or replicate documentation from other
+upstream open source projects such as KVM, OpenDaylight, or OpenStack, but to highlight the
+features and capabilities delivered through the OPNFV project.
+
+
+Introduction
+============
+
+OPNFV provides a suite of scenarios, infrastructure deployment options, which
+are able to be installed to host virtualised network functions (VNFs).
+This Guide intends to help users of the platform leverage the features and
+capabilities delivered by the OPNFV project.
+
+OPNFVs' Continuous Integration builds, deploys and tests combinations of virtual
+infrastructure components in what are defined as scenarios. A scenario may
+include components such as KVM, OpenDaylight, OpenStack, OVS, etc., where each
+scenario will include different source components or configurations. Scenarios
+are designed to enable specific features and capabilities in the platform that
+can be leveraged by the OPNFV User community.
+
+
+Feature Overview
+================
+
+The following links outline the feature deliverables from participating OPNFV
+projects in the Danube release. Each of the participating projects provides
+detailed descriptions about the delivered features including use cases,
+implementation and configuration specifics.
+
+The following Configuration Guides and User Guides assume that the reader already has some
+information about a given project's specifics and deliverables. These Guides
+are intended to be used following the installation with an OPNFV installer
+to allow users to deploy and implement feature delivered by OPNFV.
+
+If you are unsure about the specifics of a given project, please refer to the
+OPNFV wiki page at http://wiki.opnfv.org, for more details.
+
+
+Feature Configuration Guides
+============================
+
+- :ref:`Copper Configuration Guide <copper-configguide>`
+- :ref:`Doctor Configuration Guide <doctor-configguide>`
+- :ref:`IPv6 Configuration Guide <ipv6-configguide>`
+- :ref:`KVMforNFV Configuration Guide <kvmfornfv-configguide>`
+- :ref:`Netready Configuration Guide <netready-configguide>`
+- :ref:`ONOSFW Configuration Guide <onosfw-configguide>`
+- :ref:`Parser Configuration Guide <parser-configguide>`
+- :ref:`Promise Configuration Guide <promise-configguide>`
+- :ref:`SDNVPN Configuration Guide <sdnvpn-configguide>`
+- :ref:`SFC Configuration Guide <sfc-configguide>`
+
+
+Feature User Guides
+===================
+
+- :ref:`Copper User Guide <copper-userguide>`
+- :ref:`Doctor User Guide <doctor-userguide>`
+- :ref:`Domino User Guide <domino-userguide>`
+- :ref:`IPv6 User Guide <ipv6-userguide>`
+- :ref:`KVMforNFV User Guide <kvmfornfv-userguide>`
+- :ref:`Netready User Guide <netready-userguide>`
+- :ref:`ONOSFW User Guide <onosfw-userguide>`
+- :ref:`Parser User Guide <parser-userguide>`
+- :ref:`Promise User Guide <promise-userguide>`
+- :ref:`SDNVPN User Guide <sdnvpn-userguide>`
+- :ref:`SFC User Guide <sfc-userguide>`
+
diff --git a/docs/templates/development/design/index.rst b/docs/templates/development/design/index.rst
new file mode 100644
index 0000000..392b39f
--- /dev/null
+++ b/docs/templates/development/design/index.rst
@@ -0,0 +1 @@
+.. To be decided
diff --git a/docs/templates/development/overview/index.rst b/docs/templates/development/overview/index.rst
new file mode 100644
index 0000000..caf4dfc
--- /dev/null
+++ b/docs/templates/development/overview/index.rst
@@ -0,0 +1,15 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, Ericsson AB and others.
+
+=============================================
+OPNFV <Project Name> <Release Name> Overview
+=============================================
+
+For example, the title might be "Qtip Danube Overview"
+
+.. toctree::
+   :maxdepth: 1
+
+   overview
diff --git a/docs/templates/development/overview/overview.rst b/docs/templates/development/overview/overview.rst
new file mode 100644
index 0000000..498dc06
--- /dev/null
+++ b/docs/templates/development/overview/overview.rst
@@ -0,0 +1,16 @@
+==============================================
+OPNFV <Release Name> <Project Name> Overview
+==============================================
+
+.. contents::
+   :depth: 3
+   :local:
+
+Introduction
+----------------
+Describing the components and behaviours in a manner that helps people understand the platform and how to work with it
+
+Upgrades from <Previous Release>
+-----------------------------------
+<optional, required if there's a previous release for the project>
+Describe the new features
diff --git a/docs/templates/development/requirements/index.rst b/docs/templates/development/requirements/index.rst
new file mode 100644
index 0000000..392b39f
--- /dev/null
+++ b/docs/templates/development/requirements/index.rst
@@ -0,0 +1 @@
+.. To be decided
diff --git a/docs/templates/release/configguide/feature.configuration.rst b/docs/templates/release/configguide/feature.configuration.rst
new file mode 100644
index 0000000..e2fcbbb
--- /dev/null
+++ b/docs/templates/release/configguide/feature.configuration.rst
@@ -0,0 +1,256 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Ferenc Cserepkei, Brady Allen Johnson, Manuel Buil and others
+
+Abstract
+========
+This document provides information on how to install the OpenDayLigh SFC
+features in OPNFV with the use of os_odl-l2_sfc-(no)ha scenario.
+
+SFC feature desciription
+========================
+For details of the scenarios and their provided capabilities refer to
+the scenario description documents:
+
+- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html
+
+- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html
+
+
+The SFC feature enables creation of Service Fuction Chains - an ordered list
+of chained network funcions (e.g. firewalls, NAT, QoS)
+
+The SFC feature in OPNFV is implemented by 3 major components:
+
+- OpenDayLight SDN controller
+
+- Tacker: Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO)
+
+- OpenvSwitch: The Service Function Forwarder(s)
+
+Hardware requirements
+=====================
+
+The SFC scenarios can be deployed on a bare-metal OPNFV cluster or on a
+virtual environment on a single host.
+
+Bare metal deployment on (OPNFV) Pharos lab
+-------------------------------------------
+Hardware requirements for bare-metal deployments of the OPNFV infrastructure
+are given by the Pharos project. The Pharos project provides an OPNFV
+hardware specification for configuring your hardware:
+http://artifacts.opnfv.org/pharos/docs/pharos-spec.html
+
+
+Virtual deployment
+------------------
+To perform a virtual deployment of an OPNFV SFC scenario on a single host,
+that host has to meet the following hardware requirements:
+
+- SandyBridge compatible CPU with virtualization support
+
+- capable to host 5 virtual cores (5 physical ones at least)
+
+- 8-12 GBytes RAM for virtual hosts (controller, compute), 48GByte at least
+
+- 128 GiBiBytes room on disk for each virtual host (controller, compute) +
+  64GiBiBytes for fuel master, 576 GiBiBytes at least
+
+- Ubuntu Trusty Tahr - 14.04(.5) server operating system with at least ssh
+  service selected at installation.
+
+- Internet Connection (preferably http proxyless)
+
+
+Pre-configuration activites - Preparing the host to install Fuel by script
+==========================================================================
+.. Not all of these options are relevant for all scenario's.  I advise following the
+.. instructions applicable to the deploy tool used in the scenario.
+
+Before starting the installation of the SFC scenarios some preparation of the
+machine that will host the Colorado Fuel cluster must be done.
+
+Installation of required packages
+---------------------------------
+To be able to run the installation of the basic OPNFV fuel installation the
+Jumphost (or the host which serves the VMs for the virtual deployment) needs to
+install the following packages:
+::
+
+ sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \
+                         qemu-system tightvncserver virt-manager sshpass \
+                         fuseiso genisoimage blackbox xterm python-pip \
+                         python-git python-dev python-oslo.config \
+                         python-pip python-dev libffi-dev libxml2-dev \
+                         libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
+                         expect curl python-netaddr p7zip-full
+
+ sudo pip install GitPython pyyaml netaddr paramiko lxml scp \
+                  scp pycrypto ecdsa debtcollector netifaces enum
+
+During libvirt install the user is added to the libvirtd group, so you have to
+logout then login back again
+
+
+Download the installer source code and artifact
+-----------------------------------------------
+To be able to install the scenario os_odl-l2_sfc-(no)ha one can follow the way
+CI is deploying the scenario.
+First of all the opnfv-fuel repository needs to be cloned:
+::
+
+ git clone -b 'stable/colorado' ssh://<user>@gerrit.opnfv.org:29418/fuel
+
+This command copies the whole colorado branch of repository fuel.
+
+Now download the appropriate OPNFV Fuel ISO into an appropriate folder:
+::
+
+ wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso
+
+The exact name of the ISO image may change.
+Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO.
+
+Simplified scenario deployment procedure using Fuel
+===================================================
+
+This section describes the installation of the os-odl-l2_sfc or
+os-odl-l2_sfc-noha OPNFV reference platform stack across a server cluster
+or a single host as a virtual deployment.
+
+Scenario Preparation
+--------------------
+dea.yaml and dha.yaml need to be copied and changed according to the
+lab-name/host where you deploy.
+Copy the full lab config from:
+::
+
+ cp -r <path-to-opnfv-fuel-repo>/deploy/config/labs/devel-pipeline/elx \
+    <path-to-opnfv-fuel-repo>/deploy/config/labs/devel-pipeline/<your-lab-name>
+
+Add at the bottom of dha.yaml
+::
+
+ disks:
+   fuel: 64G
+   controller: 128G
+   compute: 128G
+
+ define_vms:
+   controller:
+     vcpu:
+       value: 2
+     memory:
+       attribute_equlas:
+         unit: KiB
+       value: 12521472
+     currentMemory:
+       attribute_equlas:
+         unit: KiB
+       value: 12521472
+   compute:
+     vcpu:
+       value: 2
+     memory:
+       attribute_equlas:
+         unit: KiB
+       value: 8388608
+     currentMemory:
+       attribute_equlas:
+         unit: KiB
+       value: 8388608
+   fuel:
+     vcpu:
+       value: 2
+     memory:
+       attribute_equlas:
+         unit: KiB
+       value: 2097152
+     currentMemory:
+       attribute_equlas:
+         unit: KiB
+       value: 2097152
+
+Check if the default settings in dea.yaml are in line with your intentions
+and make changes as required.
+
+Installation procedures
+-----------------------
+
+We state here several alternatives.
+First, we describe methods that are based on the use of the deploy.sh script,
+what is used by the OPNFV CI system and can be found in the Fuel repository.
+
+In addition, the SFC feature can also be configured manually in the Fuel GUI
+what we will show in the last subsection.
+
+Before starting any of the following procedures, go to
+::
+
+ cd <opnfv-fuel-repo>/ci
+
+Full automatic virtual deployment, High Availablity mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This example will deploy the high-availability flavor of SFC scenario
+os_odl-l2_sfc-ha in a fully automatic way, i.e. all installation steps
+(Fuel server installation, configuration, node discovery and platform
+deployment) will take place without any further prompt for user input.
+::
+
+ sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name>
+ -s os_odl-l2_sfc-ha -i file://<path-to-fuel-iso>
+
+Full automatic virtual deployment, non HIGH Availablity mode
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following command will deploy the SFC scenario with non-high-availability
+flavor (note the  different scenario name for the -s switch). Otherwise it
+does the same as described above.
+::
+
+ sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name>
+ -s os_odl-l2_sfc-noha -i file://<path-to-fuel-iso>
+
+Automatic Fuel installation and manual scenario deployment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A useful alternative to the full automatic procedure is to only deploy the Fuel host and to run host selection, role assignment and SFC scenario configuration manually.
+::
+
+ sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name> -s os_odl-l2_sfc-ha -i file://<path-to-fuel-iso> -e
+
+With -e option the installer will skip environment deployment, so an user
+can do some modification before the scenario is really deployed. Another
+useful option is the -f option which deploys the scenario using an existing
+Fuel host.
+
+The result of this installation is a well configured Fuel sever. The use of
+the deploy button on Fuel dashboard can initiate the deployment. A user may
+perform manual post-configuration as well.
+
+Feature configuration on existing Fuel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If a Fuel server is already provisioned but the fuel plugins for Opendaylight,
+Openvswitch are not provided install them by:
+::
+
+ cd /opt/opnfv/
+ fuel plugins --install fuel-plugin-ovs-*.noarch.rpm
+ fuel plugins --install opendaylight-*.noarch.rpm
+
+If plugins are installed and you want to update them use --force flag.
+
+Note that One may inject other - Colorado compatible - plugins to the Fuel
+Master host using the command scp:
+
+scp <plugin>.rpm root@10.20.0.2:<plugin>.rpm
+
+Now the feature can be configured. Create a new environment with
+Networking Setup:"OpenDayLight with tunneling segmentation". Then go to
+settings/other and check "OpenDaylight plugin, SFC enabled",
+"Install Openvswitch with NSH/DPDK, with NSH enabled". During node provision
+remember assign the OpenDayLight role to the (primary)controller
+
+Now the deploy button on fuel dashboard can be used to deploy the environment.
diff --git a/docs/templates/release/configguide/featureconfig.rst b/docs/templates/release/configguide/featureconfig.rst
new file mode 100644
index 0000000..287715d
--- /dev/null
+++ b/docs/templates/release/configguide/featureconfig.rst
@@ -0,0 +1,34 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+========
+Abstract
+========
+Add a brief introduction to configure OPNFV with this specific feature including
+dependancies on platform components, this description should be at a level that
+will apply to any installer providing the pre-requisite components.
+
+.. contents::
+   :depth: 3
+   :local:
+
+Pre-configuration activities
+============================
+Describe specific pre-configuration activities. This should include ensuring the
+right components are installed by the installation tools as required for your
+feature to function.  Refer to the previous installer configuration chapters,
+installations guide and release notes
+
+
+Hardware configuration
+======================
+Describe the hardware configuration needed for this specific feature
+
+
+Feature configuration
+=====================
+Describe the procedures to configure your feature on the platform in order
+that it is ready to use according to the feature instructions in the platform
+user guide.  Where applicable you should add content in the postinstall.rst
+to validate the feature is configured for use.
+(checking components are installed correctly etc...)
diff --git a/docs/templates/release/configguide/index.rst b/docs/templates/release/configguide/index.rst
new file mode 100644
index 0000000..1789179
--- /dev/null
+++ b/docs/templates/release/configguide/index.rst
@@ -0,0 +1,12 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+**********************************
+<Project Name> Configuration Guide
+**********************************
+
+.. toctree::
+   :maxdepth: 1
+
+   featureconfig
+   postinstall
diff --git a/docs/templates/release/configguide/postinstall.rst b/docs/templates/release/configguide/postinstall.rst
new file mode 100644
index 0000000..59a20c6
--- /dev/null
+++ b/docs/templates/release/configguide/postinstall.rst
@@ -0,0 +1,38 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+*************************************
+<Project> Post Installation Procedure
+*************************************
+
+Add a brief introduction to the methods of validating the installation
+according to this specific installer or feature.
+
+.. contents::
+   :depth: 3
+   :local:
+
+
+Automated post installation activities
+======================================
+Describe specific post installation activities performed by the OPNFV
+deployment pipeline including testing activities and reports. Refer to
+the relevant testing guides, results, and release notes.
+
+note: this section should be singular and derived from the test projects
+once we have one test suite to run for all deploy tools.  This is not the
+case yet so each deploy tool will need to provide (hopefully very simillar)
+documentation of this.
+
+
+<Project> post configuration procedures
+=======================================
+Describe any deploy tool or feature specific scripts, tests or procedures
+that should be carried out on the deployment post install and configuration
+in this section.
+
+
+Platform components validation
+==============================
+Describe any component specific validation procedures necessary for your
+deployment tool in this section.
diff --git a/docs/templates/release/installation/index.rst b/docs/templates/release/installation/index.rst
new file mode 100644
index 0000000..3dbb7c5
--- /dev/null
+++ b/docs/templates/release/installation/index.rst
@@ -0,0 +1,11 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+***************************************
+<Project Name> Installation Instruction
+***************************************
+
+.. toctree::
+   :maxdepth: 1
+
+   installation.instruction
diff --git a/docs/templates/release/installation/installation.instruction.rst b/docs/templates/release/installation/installation.instruction.rst
new file mode 100644
index 0000000..449f25f
--- /dev/null
+++ b/docs/templates/release/installation/installation.instruction.rst
@@ -0,0 +1,210 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+========
+Abstract
+========
+
+This document describes how to install <Component>, it's dependencies and required system resources.
+
+.. contents::
+   :depth: 3
+   :local:
+
+Version history
+---------------------
+
++--------------------+--------------------+--------------------+--------------------+
+| **Date**           | **Ver.**           | **Author**         | **Comment**        |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+| 2015-04-14         | 0.1.0              | Jonas Bjurel       | First draft        |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+|                    | 0.1.1              |                    |                    |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+|                    | 1.0                |                    |                    |
+|                    |                    |                    |                    |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+
+
+Introduction
+============
+<INTRODUCTION TO THE SCOPE AND INTENTION OF THIS DOCUMENT AS WELL AS TO THE SYSTEM TO BE INSTALLED>
+
+<EXAMPLE>:
+
+This document describes the supported software and hardware configurations for the
+Fuel OPNFV reference platform as well as providing guidelines on how to install and
+configure such reference system.
+
+Although the available installation options gives a high degree of freedom in how the system is set-up,
+with what architecture, services and features, etc., not nearly all of those permutations provides
+a OPNFV compliant reference architecture. Following the guidelines in this document ensures
+a result that is OPNFV compliant.
+
+The audience of this document is assumed to have good knowledge in network and Unix/Linux administration.
+
+
+Preface
+=======
+<DESCRIBE NEEDED PREREQUISITES, PLANNING, ETC.>
+
+<EXAMPLE>:
+
+Before starting the installation of Fuel@OPNFV, some planning must preceed.
+
+First of all, the Fuel@OPNFV .iso image needs to be retrieved,
+the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def>
+
+Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository:
+<git clone https://<linux foundation uid>@gerrit.opnf.org/gerrit/genesis>
+Check-out the Arno release:
+<cd genesis; git checkout arno>
+Goto the fuel directory and build the .iso
+<cd fuel/build; make all>
+
+Familiarize yourself with the Fuel 6.0.1 version by reading the following documents:
+- abc <http://wiki.openstack.org/abc>
+- def <http://wiki.openstack.org/def>
+- ghi <http://wiki.openstack.org/ghi>
+
+Secondly, a number of deployment specific parameters must be collected, those are:
+
+1.     Provider sub-net and gateway information
+
+2.     Provider VLAN information
+
+3.     Provider DNS addresses
+
+4.     Provider NTP addresses
+
+This information will be needed for the configuration procedures provided in this document.
+
+
+Hardware requirements
+=====================
+<PROVIDE A LIST OF MINIMUM HARDWARE REQUIREMENTS NEEDED FOR THE INSTALL>
+
+<EXAMPLE>:
+
+Following minimum hardware requirements must be met for installation of Fuel@OPNFV:
+
++--------------------+----------------------------------------------------+
+| **HW Aspect**      | **Requirement**                                    |
+|                    |                                                    |
++--------------------+----------------------------------------------------+
+| **# of servers**   | Minimum 5 (3 for non redundant deployment)         |
+|                    | 1 Fuel deployment master (may be virtualized)      |
+|                    | 3(1) Controllers                                   |
+|                    | 1 Compute                                          |
++--------------------+----------------------------------------------------+
+| **CPU**            | Minimum 1 socket x86_AMD64 Ivy bridge 1.6 GHz      |
+|                    |                                                    |
++--------------------+----------------------------------------------------+
+| **RAM**            | Minimum 16GB/server (Depending on VNF work load)   |
+|                    |                                                    |
++--------------------+----------------------------------------------------+
+| **Disk**           | Minimum 256GB 10kRPM spinning disks                |
+|                    |                                                    |
++--------------------+----------------------------------------------------+
+| **NICs**           | 2(1)x10GE Niantec for Private/Public (Redundant)   |
+|                    |                                                    |
+|                    | 2(1)x10GE Niantec for SAN (Redundant)              |
+|                    |                                                    |
+|                    | 2(1)x1GE for admin (PXE) and control (RabitMQ,etc) |
+|                    |                                                    |
++--------------------+----------------------------------------------------+
+
+
+Top of the rack (TOR) Configuration requirements
+================================================
+<DESCRIBE NEEDED NETWORK TOPOLOGY SETUP IN THE TORs>
+
+<EXAMPLE>:
+
+The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as
+for the tenant networks (East/West) and provider connectivity (North/South bound connectivity).
+The switching connectivity can (but does not need to) be fully redundant,
+in case it and comprises a redundant 10GE switch pair for "Traffic/Payload/SAN" purposes as well as
+a 1GE switch pair for "infrastructure control-, management and administration"
+
+The switches are **not** automatically configured from the OPNFV reference platform.
+All the networks involved in the OPNFV infra-structure as well as the provider networks
+and the private tenant VLANs needs to be manually configured.
+
+This following sections guides through required black-box switch configurations.
+
+VLAN considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+IP Address plan considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+OPNFV Software installation and deployment
+==========================================
+<DESCRIBE THE FULL PROCEDURES FOR THE INSTALLATION OF THE OPNFV COMPONENT INSTALLATION AND DEPLOYMENT>
+
+<EXAMPLE>:
+
+This section describes the installation of the Fuel@OPNFV installation server (Fuel master)
+as well as the deployment of the full OPNFV reference platform stack across a server cluster.
+Etc.
+
+Install Fuel master
+^^^^^^^^^^^^^^^^^^^^^
+
+Create an OPNV (Fuel Environment)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Configure the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Deploy the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+Installation health-check
+=========================
+<DESCRIBE ANY MEANS TO DO VERIFY THE INTEGRITY AND HEALTHYNESS OF THE INSTALL>
+
+<EXAMPLE>:
+
+Now that the OPNFV environment has been created, and before the post installation configurations is started,
+perform a system health check from the Fuel GUI:
+
+- Select the "Health check" TAB.
+- Select all test-cases
+- And click "Run tests"
+
+All test cases except the following should pass:
+
+Post installation and deployment actions
+------------------------------------------
+<DESCRIBE ANY POST INSTALLATION ACTIONS/CONFIGURATIONS NEEDED>
+
+<EXAMPLE>:
+After the OPNFV deployment is completed, the following manual changes needs to be performed in order
+for the system to work according OPNFV standards.
+
+**Change host OS password:**
+Change the Host OS password by......
+
+
+References
+==========
+<PROVIDE NEEDED/USEFUL REFERENCES>
+
+<EXAMPLES>:
+
+OPNFV
+^^^^^^^^^^
+
+OpenStack
+^^^^^^^^^^^
+
+OpenDaylight
+^^^^^^^^^^^^^^^
diff --git a/docs/templates/release/release-notes/index.rst b/docs/templates/release/release-notes/index.rst
new file mode 100644
index 0000000..e703944
--- /dev/null
+++ b/docs/templates/release/release-notes/index.rst
@@ -0,0 +1,11 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+****************************
+<Project Name> Release Notes
+****************************
+
+.. toctree::
+   :maxdepth: 1
+
+   release-notes
diff --git a/docs/templates/release/release-notes/release-notes.rst b/docs/templates/release/release-notes/release-notes.rst
new file mode 100644
index 0000000..ead095c
--- /dev/null
+++ b/docs/templates/release/release-notes/release-notes.rst
@@ -0,0 +1,233 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+
+This document provides the release notes for <RELEASE> of <COMPONENT>.
+
+.. contents::
+   :depth: 3
+   :local:
+
+
+Version history
+---------------
+
++--------------------+--------------------+--------------------+--------------------+
+| **Date**           | **Ver.**           | **Author**         | **Comment**        |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+| 2015-04-14         | 0.1.0              | Jonas Bjurel       | First draft        |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+|                    | 0.1.1              |                    |                    |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+|                    | 1.0                |                    |                    |
+|                    |                    |                    |                    |
++--------------------+--------------------+--------------------+--------------------+
+
+Important notes
+===============
+
+<STATE IMPORTANT NOTES/DEVIATIONS SINCE PREVIOUS ITERATIVE RELEASE AND OTHER IMPORTANT NOTES FOR THIS RELEASE>
+
+<EXAMPLE>:
+
+**Attention:** Please be aware that since LSV3 a pre-deploy script must be ran on the Fuel master -
+see the OPNFV@Fuel SW installation instructions
+
+
+Summary
+=======
+
+<SUMMARIZE THE RELEASE - THE CONTENT - AND OTHER IMPORTANT HIGH LEVEL PROPERTIES>
+
+<EXAMPLE>:
+
+Arno Fuel@OPNFV is based the OpenStack Fuel upstream project version 6.0.1,
+but adds OPNFV unique components such as OpenDaylight version: Helium as well as other OPNFV unique configurations......
+
+
+Release Data
+============
+<STATE RELEVANT RELEASE DATA/RECORDS>
+
+<EXAMPLE>:
+
++--------------------------------------+--------------------------------------+
+| **Project**                          | E.g. Arno/genesis/fuel@opnfv         |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| **Repo/commit-ID**                   | E.g. genesis/adf634a0d4.....         |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| **Release designation**              | E.g. Arno RC2                        |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| **Release date**                     | E.g. 2015-04-16                      |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| **Purpose of the delivery**          | E.g. OPNFV Internal quality assurance|
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+
+Version change
+^^^^^^^^^^^^^^^^
+
+Module version changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<STATE WHAT UPSTREAM, - AS WELL AS OPNFV MODULE VERSIONS HAVE CHANGED>
+
+<EXAMPLE>:
+
+- Fuel have changed from 5.1 to 6.0.1
+
+- OpenDaylight has changed from Helium-SR1 to Helium-SR2
+
+Document version changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<STATE WHAT RELATED DOCUMENTS THAT CHANGES WITH THIS RELEASE>
+
+<EXAMPLE>:
+
+- The Fuel@OPNFV installation guide version has changed from version 0.1 to to 0.2
+
+Reason for version
+^^^^^^^^^^^^^^^^^^^^
+Feature additions
+~~~~~~~~~~~~~~~~~~~~~~~
+<STATE ADDED FEATURES BY REFERENCE TO JIRA>
+
+<EXAMPLE>:
+
+**JIRA BACK-LOG:**
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE**                   | **SLOGAN**                           |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-123                              | ADD OpenDaylight ml2 integration     |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-456                              | Add auto-deployment of Fuel@OPNFV    |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+
+Bug corrections
+~~~~~~~~~~~~~~~~~~~~~
+
+**JIRA TICKETS:**
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE**                   | **SLOGAN**                           |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-888                              | Fuel doesn't deploy                  |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-999                              | Floating IP doesn't work             |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+
+Deliverables
+----------------
+
+Software deliverables
+^^^^^^^^^^^^^^^^^^^^^^^
+
+<STATE WHAT SOFTWARE DELIVERABLES THAT ARE RELATED TO THIS VERSION, AND WHERE THOSE CAN BE RETRIEVED>
+
+<EXAMPLE>:
+
+Documentation deliverables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+<STATE WHAT DOCUMENTATION DELIVERABLES THAT ARE RELATED TO THIS VERSION, AND WHERE THOSE CAN BE RETRIEVED>
+
+<EXAMPLE>:
+
+
+Known Limitations, Issues and Workarounds
+=========================================
+
+System Limitations
+^^^^^^^^^^^^^^^^^^^^
+<STATE ALL RELEVANT SYSTEM LIMITATIONS>
+
+<EXAMPLE>:
+
+**Max number of blades:**   1 Fuel master, 3 Controllers, 20 Compute blades
+
+**Min number of blades:**   1 Fuel master, 1 Controller, 1 Compute blade
+
+**Storage:**    Ceph is the only supported storage configuration.
+
+**Max number of networks:**   3800 (Needs special switch config.)
+
+**L3Agent:**   L3 agent and floating IPs is not supported.
+
+Known issues
+^^^^^^^^^^^^^^^
+<STATE ALL KNOWN ISSUES WITH JIRA REFERENCE>
+
+<EXAMPLE>:
+
+**JIRA TICKETS:**
+
++--------------------------------------+--------------------------------------+
+| **JIRA REFERENCE**                   | **SLOGAN**                           |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-987                              | Nova-compute process does            |
+|                                      | not re-spawn when killed             |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| BGS-654                              | MOS 5.1 : neutron net-list returns   |
+|                                      | "400 Bad request"                    |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+
+Workarounds
+^^^^^^^^^^^^^^^^^
+
+<STATE ALL KNOWN WORKAROUNDS TO THE ISSUES STATED ABOVE>
+
+<EXAMPLE>:
+
+- In case the contact with a compute is lost - restart the compute host
+- In case the disk is full on a controller - delete all files in /tmp
+
+Test Result
+===========
+<STATE THE QA COVERAGE AND RESULTS>
+
+<EXAMPLE>:
+
+Fuel@OPNFV Arno RC2 has undergone QA test runs with the following results:
+
++--------------------------------------+--------------------------------------+
+| **TEST-SUITE**                       | **Results:**                         |
+|                                      |                                      |
++--------------------------------------+--------------------------------------+
+| Tempest test suite 123               | Following tests failed:              |
+|                                      |                                      |
+|                                      | 1. Image resizing....                |
+|                                      |                                      |
+|                                      | 2. Heat deploy....                   |
++--------------------------------------+--------------------------------------+
+| Robot test suite 456                 | Following tests failed:              |
+|                                      |                                      |
+|                                      | 1.......                             |
+|                                      |                                      |
+|                                      | 2.......                             |
++--------------------------------------+--------------------------------------+
+
+References
+==========
+<STATE RELEVANT REFERENCES FOR THIS RELEASE/VERSION>
+
+<EXAMPLE>:
+
+For more information on the OPNFV Danube release, please see:
+
+http://opnfv.org/danube
diff --git a/docs/templates/release/scenarios/scenario.name/index.rst b/docs/templates/release/scenarios/scenario.name/index.rst
new file mode 100644
index 0000000..37aab84
--- /dev/null
+++ b/docs/templates/release/scenarios/scenario.name/index.rst
@@ -0,0 +1,16 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+****************************************
+<scenario name> overview and description
+****************************************
+.. This document will be used to provide a description of the scenario for an end user.
+.. You should explain the purpose of the scenario, the types of capabilities provided and
+..  the unique components that make up the scenario including how they are used.
+
+.. toctree::
+   :maxdepth: 1
+
+   scenario.description
+
diff --git a/docs/templates/release/scenarios/scenario.name/scenario.description.rst b/docs/templates/release/scenarios/scenario.name/scenario.description.rst
new file mode 100644
index 0000000..8c2cbab
--- /dev/null
+++ b/docs/templates/release/scenarios/scenario.name/scenario.description.rst
@@ -0,0 +1,39 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+This document provides scenario level details for <RELEASE> of <COMPONENT>.
+
+.. contents::
+   :depth: 3
+   :local:
+
+============
+Introduction
+============
+.. In this section explain the purpose of the scenario and the types of capabilities provided
+
+Scenario components and composition
+===================================
+.. In this section describe the unique components that make up the scenario,
+.. what each component provides and why it has been included in order
+.. to communicate to the user the capabilities available in this scenario.
+
+Scenario usage overview
+=======================
+.. Provide a brief overview on how to use the scenario and the features available to the
+.. user.  This should be an "introduction" to the userguide document, and explicitly link to it,
+.. where the specifics of the features are covered including examples and API's
+
+Limitations, Issues and Workarounds
+===================================
+.. Explain scenario limitations here, this should be at a design level rather than discussing
+.. faults or bugs.  If the system design only provide some expected functionality then provide
+.. some insight at this point.
+
+References
+==========
+
+For more information on the OPNFV Danube release, please visit
+http://www.opnfv.org/danube
+
diff --git a/docs/templates/release/userguide/feature.userguide.rst b/docs/templates/release/userguide/feature.userguide.rst
new file mode 100644
index 0000000..1d54d0e
--- /dev/null
+++ b/docs/templates/release/userguide/feature.userguide.rst
@@ -0,0 +1,23 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+.. contents::
+   :depth: 3
+   :local:
+
+<Feature> description
+=====================
+.. Describe the specific features and how it is realised in the scenario in a brief manner
+.. to ensure the user understand the context for the user guide instructions to follow.
+
+<Feature> capabilities and usage
+================================
+.. Describe the specific capabilities and usage for <XYZ> feature.
+.. Provide enough information that a user will be able to operate the feature on a deployed scenario.
+
+<Feature and API usage guidelines and example>
+==============================================
+.. Describe with examples how to use specific features, provide API examples and details required to
+.. operate the feature on the platform.
+
diff --git a/docs/templates/release/userguide/index.rst b/docs/templates/release/userguide/index.rst
new file mode 100644
index 0000000..5fec000
--- /dev/null
+++ b/docs/templates/release/userguide/index.rst
@@ -0,0 +1,23 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) <optionally add copywriters name>
+
+=====================
+<Feature> User Guide
+=====================
+
+.. The feature user guide should provide an OPNFV user with enough information to
+.. use the features provided by the feature project in the supported scenarios.
+.. This guide should walk a user through the usage of the features once a scenario
+.. has been deployed and is active according to the installation guide provided
+.. by the installer project.
+
+.. toctree::
+   :maxdepth: 1
+
+   feature.userguide
+.. The feature.userguide.rst file should contain the text for this document
+.. additional documents can be added to this directory and added in the right order
+.. to this file as a list below.
+
+
diff --git a/docs/templates/testing/developer/devguide/index.rst b/docs/templates/testing/developer/devguide/index.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/templates/testing/developer/devguide/index.rst
diff --git a/docs/templates/testing/developer/internship/index.rst b/docs/templates/testing/developer/internship/index.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/templates/testing/developer/internship/index.rst
diff --git a/docs/templates/testing/index.rst b/docs/templates/testing/index.rst
new file mode 100644
index 0000000..392b39f
--- /dev/null
+++ b/docs/templates/testing/index.rst
@@ -0,0 +1 @@
+.. To be decided
diff --git a/docs/templates/testing/user/configguide/configguide.rst b/docs/templates/testing/user/configguide/configguide.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/templates/testing/user/configguide/configguide.rst
diff --git a/docs/templates/testing/user/configguide/index.rst b/docs/templates/testing/user/configguide/index.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/templates/testing/user/configguide/index.rst
diff --git a/docs/templates/testing/user/userguide/index.rst b/docs/templates/testing/user/userguide/index.rst
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/docs/templates/testing/user/userguide/index.rst
diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst
new file mode 100644
index 0000000..8668859
--- /dev/null
+++ b/docs/testing/developer/devguide/index.rst
@@ -0,0 +1,353 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+
+***********************
+Testing developer guide
+***********************
+
+.. toctree::
+   :numbered:
+   :maxdepth: 2
+
+
+============
+Introduction
+============
+
+The OPNFV testing ecosystem is wide.
+
+The goal of this guide consists in providing some guidelines for new developers
+involved in test areas.
+
+For the description of the ecosystem, see `[1]`_.
+
+
+=================
+Developer journey
+=================
+
+Be involved in the testing group
+================================
+
+Best practices
+==============
+
+Unit tests
+----------
+
+Dockerization
+-------------
+
+API
+---
+
+CLI
+---
+
+Traffic generators
+------------------
+
+Towards a pseudo micro services approach
+----------------------------------------
+
+======================================
+Testing group configuration parameters
+======================================
+
+
+Testing categories
+==================
+
+The testing group defined several categories also known as tiers. These
+categories can be used to group test suites.
+
++----------------+-------------------------------------------------------------+
+| Healthcheck    | Simple and quick healthcheck tests case                     |
++----------------+-------------------------------------------------------------+
+| Smoke          | Set of smoke test cases/suites to validate the release      |
++----------------+-------------------------------------------------------------+
+| Features       | Test cases that validate a specific feature on top of OPNFV.|
+|                | Those come from Feature projects and need a bit of support  |
+|                | for integration                                             |
++----------------+-------------------------------------------------------------+
+| Components     | Tests on a specific component (e.g. OpenStack, OVS, DPDK,..)|
+|                | It may extend smoke tests                                   |
++----------------+-------------------------------------------------------------+
+| Performance    | Performance qualification                                   |
++----------------+-------------------------------------------------------------+
+| VNF            | Test cases related to deploy an open source VNF including   |
+|                | an orchestrator                                             |
++----------------+-------------------------------------------------------------+
+| Stress         | Stress and robustness tests                                 |
++----------------+-------------------------------------------------------------+
+| In Service     | In service testing                                          |
++----------------+-------------------------------------------------------------+
+
+Testing domains
+===============
+
+The domains deal with the technical scope of the tests. It shall correspond to
+domains defined for the certification program:
+
+ * compute
+ * network
+ * storage
+ * hypervisor
+ * container
+ * vim
+ * mano
+ * vnf
+ * ...
+
+Testing coverage
+=================
+One of the goals of the testing working group is to identify the poorly covered
+areas and avoid testing overlap.
+Ideally based on the declaration of the test cases, through the tags, domains
+and tier fields, it shall be possible to create heuristic maps.
+
+
+==============================
+Testing group generic enablers
+==============================
+
+
+TestAPI framework
+=================
+
+The OPNFV testing group created a test collection database to collect
+the test results from CI:
+
+
+ http://testresults.opnfv.org/test/swagger/spec.html
+
+Any test project running on any lab integrated in CI can push the
+results to this database.
+This database can be used to see the evolution of the tests and compare
+the results versus the installers, the scenarios or the labs.
+It is used to produce a dashboard with the current test status of the project.
+
+
+Overall Architecture
+--------------------
+The Test result management can be summarized as follows::
+
+  +-------------+    +-------------+    +-------------+
+  |             |    |             |    |             |
+  |   Test      |    |   Test      |    |   Test      |
+  | Project #1  |    | Project #2  |    | Project #N  |
+  |             |    |             |    |             |
+  +-------------+    +-------------+    +-------------+
+           |               |               |
+           V               V               V
+       +-----------------------------------------+
+       |                                         |
+       |         Test Rest API front end         |
+       |                                         |
+       +-----------------------------------------+
+           A                |
+           |                V
+           |     +-------------------------+
+           |     |                         |
+           |     |    Test Results DB      |
+           |     |         Mongo DB        |
+           |     |                         |
+           |     +-------------------------+
+           |
+           |
+     +----------------------+
+     |                      |
+     |    test Dashboard    |
+     |                      |
+     +----------------------+
+
+TestAPI description
+-------------------
+The TestAPI is used to declare pods, projects, test cases and test
+results. Pods are the sets of bare metal or virtual servers and networking
+equipments used to run the tests.
+
+The results pushed in the database are related to pods, projects and test cases.
+If you try to push results of test done on non referenced pod, the API will
+return an error message.
+
+An additional method dashboard has been added to post-process
+the raw results in release Brahmaputra (deprecated in Colorado).
+
+The data model is very basic, 5 objects are created:
+
+  * Pods
+  * Projects
+  * Testcases
+  * Results
+  * Scenarios
+
+The code of the API is hosted in the releng repository `[6]`_.
+The static documentation of the API can be found at `[7]`_.
+The TestAPI has been dockerized and may be installed locally in your
+lab. See `[15]`_ for details.
+
+The deployment of the TestAPI has been automated.
+A jenkins job manages:
+
+  * the unit tests of the TestAPI
+  * the creation of a new docker file
+  * the deployment of the new TestAPI
+  * the archive of the old TestAPI
+  * the backup of the Mongo DB
+
+TestAPI Authorization
+~~~~~~~~~~~~~~~~~~~~~
+
+PUT/DELETE/POST operations of the TestAPI now require token based authorization. The token needs
+to be added in the request using a header 'X-Auth-Token' for access to the database.
+
+e.g::
+    headers['X-Auth-Token']
+
+The value of the header i.e the token can be accessed in the jenkins environment variable
+*TestApiToken*. The token value is added as a masked password.
+
+.. code-block:: python
+
+    headers['X-Auth-Token'] = os.environ.get('TestApiToken')
+
+The above example is in Python. Token based authentication has been added so that only ci pods
+jenkins job can have access to the database.
+
+Please note that currently token authorization is implemented but is not yet enabled.
+
+Reporting
+=========
+
+An automatic reporting page has been created in order to provide a
+consistent view of the scenarios.
+
+In this page, each scenario is evaluated according to test criteria.
+The code for the automatic reporting is available at `[8]`_.
+
+The results are collected from the centralized database every day and,
+per scenario. A score is calculated based on the results from the last
+10 days.
+
+Dashboard
+=========
+
+Dashboard is used to provide a consistent view of the results collected in CI.
+The results showed on the dashboard are post processed from the Database,
+which only contains raw results.
+
+It can be used in addition of the reporting page (high level view) to allow
+the creation of specific graphs according to what the test owner wants to show.
+
+In Brahmaputra, a basic home made dashboard was created in Functest.
+In Colorado, Yardstick adopted Grafana (time based graphs) and ELK (complex
+graphs).
+Since Danube, the testing community decided to adopt ELK framework and to rely
+on bitergia. It was not implemented for Danube but it is planned for Euphrates.
+
+Bitergia already provides a dashboard for code and infrastructure.
+A new Test tab will be added. The dataset will be built by consuming
+the TestAPI.
+
+See `[3]`_ for details.
+
+
+=======
+How TOs
+=======
+
+Where can I find information on the different test projects?
+===========================================================
+
+
+How can I contribute to a test project?
+=======================================
+
+
+Where can I find hardware resources?
+====================================
+
+
+How do I integrate my tests in CI?
+==================================
+
+
+How to declare my tests in the test Database?
+=============================================
+
+
+How to push your results into the Test Database?
+================================================
+
+The test database is used to collect test results. By default it is
+enabled only for CI tests from Production CI pods.
+
+Please note that it is possible to create your own local database.
+
+A dedicated database is for instance created for each plugfest.
+
+The architecture and associated API is described in previous chapter.
+If you want to push your results from CI, you just have to call the API
+at the end of your script.
+
+You can also reuse a python function defined in functest_utils.py `[5]`_
+
+
+Where can I find the documentation on the test API?
+===================================================
+
+http://artifacts.opnfv.org/releng/docs/testapi.html
+
+
+
+I have tests, to which category should I declare them?
+======================================================
+
+
+
+The main ambiguity could be between features and VNF.
+In fact sometimes you have to spawn VMs to demonstrate the capabilities of the
+feature you introduced.
+We recommend to declare your test in the feature category.
+
+VNF category is really dedicated to test including:
+
+ * creation of resources
+ * deployement of an orchestrator/VNFM
+ * deployment of the VNF
+ * test of the VNFM
+ * free resources
+
+The goal is not to study a particular feature on the infrastructure but to have
+a whole end to end test of a VNF automatically deployed in CI.
+Moreover VNF are run in weekly jobs (one a week), feature tests are in daily
+jobs and use to get a scenario score.
+
+Where are the logs of CI runs?
+==============================
+
+Logs and configuration files can be pushed to artifact server from the CI under
+http://artifacts.opnfv.org/<project name>
+
+
+==========
+References
+==========
+
+_`[1]`: http://docs.opnfv.org/en/stable-danube/testing/ecosystem/overview.html
+
+_`[2]`: http://www.opnfv.org
+
+_`[3]`: https://wiki.opnfv.org/display/testing/Result+alignment+for+ELK+post-processing
+
+_`[4]`: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming
+
+_`[5]`: https://git.opnfv.org/functest/tree/functest/utils/functest_utils.py#176
+
+_`[6]`: https://git.opnfv.org/functest/tree/releng
+
+_`[7]`: http://artifacts.opnfv.org/releng/docs/testapi.html
+
+
+IRC support chan: #opnfv-testperf
diff --git a/docs/testing/ecosystem/index.rst b/docs/testing/ecosystem/index.rst
new file mode 100644
index 0000000..f51fa19
--- /dev/null
+++ b/docs/testing/ecosystem/index.rst
@@ -0,0 +1,14 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Christopher Price (Ericsson AB)
+
+========================
+Test Framework Overview
+========================
+
+.. toctree::
+   :maxdepth: 2
+
+   ./abstract
+   ./overview
+
diff --git a/docs/testing/ecosystem/overview.rst b/docs/testing/ecosystem/overview.rst
new file mode 100644
index 0000000..ed1657c
--- /dev/null
+++ b/docs/testing/ecosystem/overview.rst
@@ -0,0 +1,274 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+
+=============
+OPNFV testing
+=============
+
+Introduction
+============
+
+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.
+
+Test projects are dedicated to provide frameworks, tooling and test-cases categorized 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.
+
+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 common test components used
+by individual OPNFV projects and provides links to project specific documentation.
+
+
+OPNFV testing ecosystem
+=======================
+
+The testing projects
+--------------------
+
+The OPNFV testing projects may be summarized as follows:
+
+.. figure:: ../../images/OPNFV_testing_working_group.png
+   :align: center
+   :alt: Overview of OPNFV Testing projects
+
+The major testing projects are described in the table below:
+
++----------------+---------------------------------------------------------+
+|  Project       |   Description                                           |
++================+=========================================================+
+|  Bottlenecks   | This project aims to find system bottlenecks by testing |
+|                | and verifying OPNFV infrastructure in a staging         |
+|                | environment before committing it to a production        |
+|                | environment. Instead of debugging a deployment in       |
+|                | production environment, an automatic method for         |
+|                | executing benchmarks which plans to validate the        |
+|                | deployment during staging is adopted. This project      |
+|                | 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. Collaboration of  |
+|                | upstream controller testing experts, external test tool |
+|                | developers and the standards community. Primarily       |
+|                | contribute to upstream/external tooling, then add jobs  |
+|                | to run those tools on OPNFV's infrastructure.           |
++----------------+---------------------------------------------------------+
+| Dovetail       | This project intends to define and provide a set of     |
+|                | OPNFV related validation criteria that will provide     |
+|                | input for the evaluation of the use of OPNFV trademarks.|
+|                | The dovetail project is executed with the guidance and  |
+|                | oversight of the Compliance and Certification committee |
+|                | and work to secure the goals of the C&C committee for   |
+|                | each release. The project intends to incrementally      |
+|                | define qualification criteria that establish the        |
+|                | foundations of how we are able to measure the ability to|
+|                | utilize the OPNFV platform, how the platform itself     |
+|                | should behave, and how applications may be deployed on  |
+|                | the platform.                                           |
++----------------+---------------------------------------------------------+
+| Functest       | This project deals with the functional testing of the   |
+|                | VIM and NFVI. It leverages several upstream test suites |
+|                | (OpenStack, ODL, ONOS, etc.) and can be used by feature |
+|                | project to launch feature test suites in CI/CD.         |
+|                | The project is used for scenario validation.            |
++----------------+---------------------------------------------------------+
+| Qtip           | QTIP as the project for "Platform Performance           |
+|                | Benchmarking" in OPNFV aims to provide user a simple    |
+|                | indicator for performance, supported by comprehensive   |
+|                | testing data and transparent calculation formula.       |
+|                | It provides a platform with common services for         |
+|                | performance benchmarking which helps users to build     |
+|                | indicators by themselves with ease.                     |
++----------------+---------------------------------------------------------+
+| Storperf       | The purpose of this project is to provide a tool to     |
+|                | measure block and object storage performance in an NFVI.|
+|                | When complemented with a characterization of typical VF |
+|                | storage performance requirements, it can provide        |
+|                | pass/fail thresholds for test, staging, and production  |
+|                | NFVI environments.                                      |
++----------------+---------------------------------------------------------+
+| 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 |
+|                | described in ETSI GS NFV 001 show a large variety of    |
+|                | applications, each defining specific requirements and   |
+|                | complex configuration on the underlying infrastructure  |
+|                | and test tools.The Yardstick concept decomposes typical |
+|                | VNF work-load performance metrics into a number of      |
+|                | characteristics/performance vectors, which each of them |
+|                | can be represented by distinct test-cases.              |
++----------------+---------------------------------------------------------+
+
+
+===================================
+The testing working group resources
+===================================
+
+The assets
+==========
+
+Overall Architecture
+--------------------
+The Test result management can be summarized as follows::
+
+  +-------------+    +-------------+    +-------------+
+  |             |    |             |    |             |
+  |   Test      |    |   Test      |    |   Test      |
+  | Project #1  |    | Project #2  |    | Project #N  |
+  |             |    |             |    |             |
+  +-------------+    +-------------+    +-------------+
+           |               |               |
+           V               V               V
+       +---------------------------------------------+
+       |                                             |
+       |           Test Rest API front end           |
+       |    http://testresults.opnfv.org/test        |
+       |                                             |
+       +---------------------------------------------+
+           ^                |                     ^
+           |                V                     |
+           |     +-------------------------+      |
+           |     |                         |      |
+           |     |    Test Results DB      |      |
+           |     |         Mongo DB        |      |
+           |     |                         |      |
+           |     +-------------------------+      |
+           |                                      |
+           |                                      |
+     +----------------------+        +----------------------+
+     |                      |        |                      |
+     | Testing Dashboards   |        |      Landing page    |
+     |                      |        |                      |
+     +----------------------+        +----------------------+
+
+
+The testing databases
+---------------------
+A Mongo DB Database has been introduced for the Brahmaputra release.
+The following collections are declared in this database:
+ * pods: the list of pods used for production CI
+ * projects: the list of projects providing test cases
+ * testcases: the test cases related to a given project
+ * results: the results of the test cases
+ * scenarios: the OPNFV scenarios tested in CI
+
+This database can be used by any project through the testapi.
+Please note that projects may also use additional databases. This database is
+mainly use to colelct CI results and scenario trust indicators.
+
+This database is also cloned for OPNFV Plugfest.
+
+
+The test API
+------------
+The Test API is used to declare pods, projects, test cases and test results.
+Pods correspond to the cluster of machines (3 controller and 2 compute nodes in
+HA mode) used to run the tests and defined in Pharos project.
+The results pushed in the database are related to pods, projects and cases.
+If you try to push results of test done on non referenced pod, the API will
+return an error message.
+
+An additional method dashboard has been added to post-process the raw results in
+the Brahmaputra release (deprecated in Colorado release).
+
+The data model is very basic, 5 objects are available:
+  * Pods
+  * Projects
+  * Testcases
+  * Results
+  * Scenarios
+
+For detailed information, please go to http://artifacts.opnfv.org/releng/docs/testapi.html
+
+
+The reporting
+-------------
+The reporting page for the test projects is http://testresults.opnfv.org/reporting/
+
+.. figure:: ../../images/reporting_page.png
+   :align: center
+   :alt: Testing group reporting page
+
+This page provides a reporting per OPNFV release and per testing project.
+
+.. figure:: ../../images/reporting_danube_page.png
+   :align: center
+   :alt: Testing group Danube reporting page
+
+An evolution of this page is planned.
+It was decided to unify the reporting by creating a landing page that should give
+the scenario status in one glance (it was previously consolidated manually
+on a wiki page).
+
+The landing page (planned for Danube 2.0) will be displayed per scenario:
+ * the status of the deployment
+ * the score of the test projectS
+ * a trust indicator
+
+Additional filters (version, installer, test collection time window,... ) are
+included.
+
+The test case catalog
+---------------------
+Until the Colorado release, each testing project was managing the list of its
+test cases. It was very hard to have a global view of the available test cases
+among the different test projects. A common view was possible through the API
+but it was not very user friendly.
+In fact you may know all the cases per project calling:
+
+ http://testresults.opnfv.org/test/api/v1/projects/<project_name>/cases
+
+with project_name: bottlenecks, functest, qtip, storperf, vsperf, yardstick
+
+It was decided to build a web site providing a consistent view of the test cases
+per project and allow any scenario owner to build his/her custom list of tests
+(Danube 2.0).
+
+Other resources
+===============
+
+wiki: https://wiki.opnfv.org/testing
+
+mailing list: test-wg@lists.opnfv.org
+
+IRC chan: #opnfv-testperf
+
+weekly meeting (https://wiki.opnfv.org/display/meetings/TestPerf):
+ * Usual time: Every Thursday 15:00-16:00 UTC / 7:00-8:00 PST
+ * APAC time: 2nd Wednesday of the month 8:00-9:00 UTC
+
+=======================
+Reference documentation
+=======================
+
++----------------+---------------------------------------------------------+
+|  Project       |   Documentation links                                   |
++================+=========================================================+
+|  Bottlenecks   | https://wiki.opnfv.org/display/bottlenecks/Bottlenecks  |
++----------------+---------------------------------------------------------+
+| CPerf          | https://wiki.opnfv.org/display/cperf                    |
++----------------+---------------------------------------------------------+
+| Dovetail       | https://wiki.opnfv.org/display/dovetail                 |
++----------------+---------------------------------------------------------+
+| Functest       | https://wiki.opnfv.org/display/functest/                |
++----------------+---------------------------------------------------------+
+| Qtip           | https://wiki.opnfv.org/display/qtip                     |
++----------------+---------------------------------------------------------+
+| Storperf       | https://wiki.opnfv.org/display/storperf/Storperf        |
++----------------+---------------------------------------------------------+
+| VSperf         | https://wiki.opnfv.org/display/vsperf                   |
++----------------+---------------------------------------------------------+
+| Yardstick      | https://wiki.opnfv.org/display/yardstick/Yardstick      |
++----------------+---------------------------------------------------------+
diff --git a/docs/testing/testing-dev.rst b/docs/testing/testing-dev.rst
new file mode 100644
index 0000000..e7b6800
--- /dev/null
+++ b/docs/testing/testing-dev.rst
@@ -0,0 +1,51 @@
+.. _testing-dev:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+========================
+Testing Developer Guides
+========================
+
+Testing group
+-------------
+.. include:: ./developer/devguide/index.rst
+
+Bottlenecks
+------------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/bottlenecks/docs/testing/developer/devguide/index
+
+
+Functest
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/functest/docs/testing/developer/devguide/index
+
+
+QTIP
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/qtip/docs/testing/developer/devguide/index
+
+
+VSPERF
+-------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/vswitchperf/docs/testing/developer/devguide/index
+
+
+Yardstick
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/yardstick/docs/testing/developer/devguide/index
diff --git a/docs/testing/testing-user.rst b/docs/testing/testing-user.rst
new file mode 100644
index 0000000..198b090
--- /dev/null
+++ b/docs/testing/testing-user.rst
@@ -0,0 +1,65 @@
+.. _testing-userguide:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+===================
+Testing User Guides
+===================
+
+Bottlenecks
+------------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/bottlenecks/docs/testing/user/configguide/index
+   ../submodules/bottlenecks/docs/testing/user/userguide/index
+
+
+Functest
+---------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/functest/docs/testing/user/configguide/index
+   ../submodules/functest/docs/testing/user/userguide/index
+
+
+QTIP
+-----
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/qtip/docs/testing/user/configguide/index
+   ../submodules/qtip/docs/testing/user/userguide/index
+
+
+Storperf
+--------
+
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/storperf/docs/testing/user/index
+
+
+VSPERF
+------
+
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/vswitchperf/docs/testing/user/configguide/index
+   ../submodules/vswitchperf/docs/testing/user/userguide/index
+
+
+Yardstick
+----------
+.. toctree::
+   :maxdepth: 1
+
+   ../submodules/yardstick/docs/testing/user/configguide/index
+   ../submodules/yardstick/docs/testing/user/userguide/index
+
+
+