aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorStuart Mackie <wsmackie@juniper.net>2017-09-14 23:26:31 -0700
committerStuart Mackie <wsmackie@juniper.net>2017-09-14 23:26:31 -0700
commitfd876b7dbc7d517a706b22e52bf6f0e8f79a0b4b (patch)
tree996858dd4abe0221f8f9d54a2aeeb4ffb9971b8e
parentfce102283bab73ed08c292fce03e39c52f4a1fe2 (diff)
Docs
Change-Id: Iea3001f8414267f1535353f28d30d45daf9a3e66 Signed-off-by: Stuart Mackie <wsmackie@juniper.net>
-rwxr-xr-xdocs/_static/favicon.icobin15086 -> 0 bytes
-rw-r--r--docs/_static/images/OPNFV_testing_group.pngbin87295 -> 0 bytes
-rw-r--r--docs/_static/images/opnfvplatformgraphic.pngbin136767 -> 0 bytes
-rw-r--r--docs/_static/my-styles.css28
-rw-r--r--docs/_static/opnfv-logo.pngbin2829 -> 0 bytes
-rw-r--r--docs/_templates/layout.html5
-rw-r--r--docs/_templates/my_custom_sidebar.html3
-rw-r--r--docs/_templates/relations.html15
-rw-r--r--docs/conf.py282
-rw-r--r--docs/development/feature.templates/scenarios/scenario.name/index.rst16
-rw-r--r--docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst32
-rw-r--r--docs/development/feature.templates/userguide/feature.userguide.rst19
-rw-r--r--docs/development/feature.templates/userguide/index.rst23
-rw-r--r--docs/development/opnfvsecguide/_static/temp0
-rw-r--r--docs/development/opnfvsecguide/_templates/temp0
-rw-r--r--docs/development/opnfvsecguide/audit.rst9
-rw-r--r--docs/development/opnfvsecguide/audit/audit_reqs.rst110
-rw-r--r--docs/development/opnfvsecguide/compute.rst8
-rw-r--r--docs/development/opnfvsecguide/compute/dacmaccontrols.rst3
-rw-r--r--docs/development/opnfvsecguide/compute/trust.rst124
-rw-r--r--docs/development/opnfvsecguide/contribution.rst45
-rw-r--r--docs/development/opnfvsecguide/getting_started.rst41
-rw-r--r--docs/development/opnfvsecguide/index.rst21
-rw-r--r--docs/development/opnfvsecguide/introduction.rst15
-rw-r--r--docs/development/opnfvsecguide/introduction/acknowledgements.rst3
-rw-r--r--docs/development/opnfvsecguide/introduction/background.rst38
-rw-r--r--docs/development/opnfvsecguide/network.rst8
-rw-r--r--docs/development/opnfvsecguide/network/neutron.rst2
-rw-r--r--docs/development/scenario/featurematrix.rst39
-rw-r--r--docs/development/scenario/scenariointro.rst13
-rw-r--r--docs/development/scenario/scenariomatrix.rst100
-rw-r--r--docs/development/scenario/scenariovalidation.rst0
-rw-r--r--docs/featureprojects.rst265
-rw-r--r--docs/glossary/index.rst117
-rw-r--r--docs/how-to-use-docs/Submodules.jpgbin85389 -> 0 bytes
-rw-r--r--docs/how-to-use-docs/addendum.rst80
-rw-r--r--docs/how-to-use-docs/documentation-guide.rst135
-rw-r--r--docs/how-to-use-docs/include-documentation.rst254
-rw-r--r--docs/how-to-use-docs/index.rst12
-rw-r--r--docs/images/OPNFV_testing_working_group.pngbin113333 -> 0 bytes
-rw-r--r--docs/images/opnfvplatformgraphic.pngbin256545 -> 0 bytes
-rw-r--r--docs/images/reporting_danube_page.pngbin56377 -> 0 bytes
-rw-r--r--docs/images/reporting_page.pngbin416872 -> 0 bytes
-rw-r--r--docs/index.rst33
-rwxr-xr-xdocs/pre-hook.sh113
-rw-r--r--docs/release/installation.introduction.rst100
-rw-r--r--docs/release/overview.rst296
-rw-r--r--docs/release/release-notes.rst57
-rw-r--r--docs/release/subrelease.rst43
-rw-r--r--docs/release/userguide.introduction.rst87
-rw-r--r--docs/release/userguide.rst112
-rw-r--r--docs/templates/development/design/index.rst1
-rw-r--r--docs/templates/development/overview/index.rst15
-rw-r--r--docs/templates/development/overview/overview.rst16
-rw-r--r--docs/templates/development/requirements/index.rst1
-rw-r--r--docs/templates/release/configguide/feature.configuration.rst256
-rw-r--r--docs/templates/release/configguide/featureconfig.rst34
-rw-r--r--docs/templates/release/configguide/index.rst12
-rw-r--r--docs/templates/release/configguide/postinstall.rst38
-rw-r--r--docs/templates/release/installation/index.rst11
-rw-r--r--docs/templates/release/installation/installation.instruction.rst210
-rw-r--r--docs/templates/release/release-notes/index.rst11
-rw-r--r--docs/templates/release/release-notes/release-notes.rst233
-rw-r--r--docs/templates/release/scenarios/scenario.name/index.rst16
-rw-r--r--docs/templates/release/scenarios/scenario.name/scenario.description.rst39
-rw-r--r--docs/templates/release/userguide/feature.userguide.rst23
-rw-r--r--docs/templates/release/userguide/index.rst23
-rw-r--r--docs/templates/testing/developer/devguide/index.rst0
-rw-r--r--docs/templates/testing/developer/internship/index.rst0
-rw-r--r--docs/templates/testing/index.rst1
-rw-r--r--docs/templates/testing/user/configguide/configguide.rst0
-rw-r--r--docs/templates/testing/user/configguide/index.rst0
-rw-r--r--docs/templates/testing/user/userguide/index.rst0
-rw-r--r--docs/testing/developer/devguide/index.rst353
-rw-r--r--docs/testing/ecosystem/index.rst14
-rw-r--r--docs/testing/ecosystem/overview.rst274
-rw-r--r--docs/testing/testing-dev.rst51
-rw-r--r--docs/testing/testing-user.rst65
78 files changed, 113 insertions, 4290 deletions
diff --git a/docs/_static/favicon.ico b/docs/_static/favicon.ico
deleted file mode 100755
index bbe55ab..0000000
--- a/docs/_static/favicon.ico
+++ /dev/null
Binary files differ
diff --git a/docs/_static/images/OPNFV_testing_group.png b/docs/_static/images/OPNFV_testing_group.png
deleted file mode 100644
index 4b8c2c0..0000000
--- a/docs/_static/images/OPNFV_testing_group.png
+++ /dev/null
Binary files differ
diff --git a/docs/_static/images/opnfvplatformgraphic.png b/docs/_static/images/opnfvplatformgraphic.png
deleted file mode 100644
index 9d6074f..0000000
--- a/docs/_static/images/opnfvplatformgraphic.png
+++ /dev/null
Binary files differ
diff --git a/docs/_static/my-styles.css b/docs/_static/my-styles.css
deleted file mode 100644
index 94e72cd..0000000
--- a/docs/_static/my-styles.css
+++ /dev/null
@@ -1,28 +0,0 @@
-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
deleted file mode 100644
index 1519503..0000000
--- a/docs/_static/opnfv-logo.png
+++ /dev/null
Binary files differ
diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html
deleted file mode 100644
index 08baa3e..0000000
--- a/docs/_templates/layout.html
+++ /dev/null
@@ -1,5 +0,0 @@
-{# 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
deleted file mode 100644
index 6b259bc..0000000
--- a/docs/_templates/my_custom_sidebar.html
+++ /dev/null
@@ -1,3 +0,0 @@
-<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
deleted file mode 100644
index 5bad0b5..0000000
--- a/docs/_templates/relations.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<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
deleted file mode 100644
index 38a8c81..0000000
--- a/docs/conf.py
+++ /dev/null
@@ -1,282 +0,0 @@
-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
deleted file mode 100644
index 59ada34..0000000
--- a/docs/development/feature.templates/scenarios/scenario.name/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. 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
deleted file mode 100644
index afd5879..0000000
--- a/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst
+++ /dev/null
@@ -1,32 +0,0 @@
-.. 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
deleted file mode 100644
index b8adfa5..0000000
--- a/docs/development/feature.templates/userguide/feature.userguide.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-.. 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
deleted file mode 100644
index cc84670..0000000
--- a/docs/development/feature.templates/userguide/index.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. 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
deleted file mode 100644
index e69de29..0000000
--- a/docs/development/opnfvsecguide/_static/temp
+++ /dev/null
diff --git a/docs/development/opnfvsecguide/_templates/temp b/docs/development/opnfvsecguide/_templates/temp
deleted file mode 100644
index e69de29..0000000
--- a/docs/development/opnfvsecguide/_templates/temp
+++ /dev/null
diff --git a/docs/development/opnfvsecguide/audit.rst b/docs/development/opnfvsecguide/audit.rst
deleted file mode 100644
index cdeecba..0000000
--- a/docs/development/opnfvsecguide/audit.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-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
deleted file mode 100644
index ce76d01..0000000
--- a/docs/development/opnfvsecguide/audit/audit_reqs.rst
+++ /dev/null
@@ -1,110 +0,0 @@
-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
deleted file mode 100644
index d6c1a01..0000000
--- a/docs/development/opnfvsecguide/compute.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-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
deleted file mode 100644
index 08cd7ee..0000000
--- a/docs/development/opnfvsecguide/compute/dacmaccontrols.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-DAC & MAC Controls
-------------------
-
diff --git a/docs/development/opnfvsecguide/compute/trust.rst b/docs/development/opnfvsecguide/compute/trust.rst
deleted file mode 100644
index 3022e59..0000000
--- a/docs/development/opnfvsecguide/compute/trust.rst
+++ /dev/null
@@ -1,124 +0,0 @@
-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
deleted file mode 100644
index 683aa2d..0000000
--- a/docs/development/opnfvsecguide/contribution.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-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
deleted file mode 100644
index e09507d..0000000
--- a/docs/development/opnfvsecguide/getting_started.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-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
deleted file mode 100644
index ecefd61..0000000
--- a/docs/development/opnfvsecguide/index.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. 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
deleted file mode 100644
index ad80831..0000000
--- a/docs/development/opnfvsecguide/introduction.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-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
deleted file mode 100644
index 60c687d..0000000
--- a/docs/development/opnfvsecguide/introduction/acknowledgements.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-Acknowledgements
-----------------
-
diff --git a/docs/development/opnfvsecguide/introduction/background.rst b/docs/development/opnfvsecguide/introduction/background.rst
deleted file mode 100644
index bd7e44d..0000000
--- a/docs/development/opnfvsecguide/introduction/background.rst
+++ /dev/null
@@ -1,38 +0,0 @@
-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
deleted file mode 100644
index b174479..0000000
--- a/docs/development/opnfvsecguide/network.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-Network Security
-----------------
-
-
-.. toctree::
- :maxdepth: 2
-
- network/neutron
diff --git a/docs/development/opnfvsecguide/network/neutron.rst b/docs/development/opnfvsecguide/network/neutron.rst
deleted file mode 100644
index e7ca060..0000000
--- a/docs/development/opnfvsecguide/network/neutron.rst
+++ /dev/null
@@ -1,2 +0,0 @@
-Neutron Security
-----------------
diff --git a/docs/development/scenario/featurematrix.rst b/docs/development/scenario/featurematrix.rst
deleted file mode 100644
index 2d00a40..0000000
--- a/docs/development/scenario/featurematrix.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-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
deleted file mode 100644
index dd80843..0000000
--- a/docs/development/scenario/scenariointro.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-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
deleted file mode 100644
index 64e1150..0000000
--- a/docs/development/scenario/scenariomatrix.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-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
deleted file mode 100644
index e69de29..0000000
--- a/docs/development/scenario/scenariovalidation.rst
+++ /dev/null
diff --git a/docs/featureprojects.rst b/docs/featureprojects.rst
deleted file mode 100644
index ad60461..0000000
--- a/docs/featureprojects.rst
+++ /dev/null
@@ -1,265 +0,0 @@
-.. _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
deleted file mode 100644
index be5b6d7..0000000
--- a/docs/glossary/index.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-.. 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
deleted file mode 100644
index aeb7956..0000000
--- a/docs/how-to-use-docs/Submodules.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/how-to-use-docs/addendum.rst b/docs/how-to-use-docs/addendum.rst
deleted file mode 100644
index 90ab1c7..0000000
--- a/docs/how-to-use-docs/addendum.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-========
-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
deleted file mode 100644
index fed42a4..0000000
--- a/docs/how-to-use-docs/documentation-guide.rst
+++ /dev/null
@@ -1,135 +0,0 @@
-===================
-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
deleted file mode 100644
index d1a5a62..0000000
--- a/docs/how-to-use-docs/include-documentation.rst
+++ /dev/null
@@ -1,254 +0,0 @@
-.. _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
deleted file mode 100644
index 424f471..0000000
--- a/docs/how-to-use-docs/index.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-.. _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
deleted file mode 100644
index f1688cf..0000000
--- a/docs/images/OPNFV_testing_working_group.png
+++ /dev/null
Binary files differ
diff --git a/docs/images/opnfvplatformgraphic.png b/docs/images/opnfvplatformgraphic.png
deleted file mode 100644
index 8039bcd..0000000
--- a/docs/images/opnfvplatformgraphic.png
+++ /dev/null
Binary files differ
diff --git a/docs/images/reporting_danube_page.png b/docs/images/reporting_danube_page.png
deleted file mode 100644
index 50bbf60..0000000
--- a/docs/images/reporting_danube_page.png
+++ /dev/null
Binary files differ
diff --git a/docs/images/reporting_page.png b/docs/images/reporting_page.png
deleted file mode 100644
index d8f46a4..0000000
--- a/docs/images/reporting_page.png
+++ /dev/null
Binary files differ
diff --git a/docs/index.rst b/docs/index.rst
index c5ca836..3a405eb 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -18,35 +18,4 @@ 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
+ release/userguide
diff --git a/docs/pre-hook.sh b/docs/pre-hook.sh
deleted file mode 100755
index 6574cdc..0000000
--- a/docs/pre-hook.sh
+++ /dev/null
@@ -1,113 +0,0 @@
-#!/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
deleted file mode 100644
index cc43aa1..0000000
--- a/docs/release/installation.introduction.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-.. _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
deleted file mode 100644
index 7e1d136..0000000
--- a/docs/release/overview.rst
+++ /dev/null
@@ -1,296 +0,0 @@
-.. _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
deleted file mode 100644
index 2eb74d7..0000000
--- a/docs/release/release-notes.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-.. _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
deleted file mode 100644
index 075fcbd..0000000
--- a/docs/release/subrelease.rst
+++ /dev/null
@@ -1,43 +0,0 @@
-==================
-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
deleted file mode 100644
index 8883927..0000000
--- a/docs/release/userguide.introduction.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. _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/release/userguide.rst b/docs/release/userguide.rst
new file mode 100644
index 0000000..706eb8a
--- /dev/null
+++ b/docs/release/userguide.rst
@@ -0,0 +1,112 @@
+.. _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)
+
+=================================
+OpenContrail in OPNFV
+=================================
+
+Introduction
+============
+
+OpenContrail provides virtual networking in OpenStack by providing a complete
+implementation of the Neutron networking API in a combination of a controller
+and a forwarding element (vRouter) that is installed in place of Linux bridge
+Open vSwitch. OpenContrail uses XMPP for the management and control plane between
+the controller and the vRouters, and uses BGP for the control plane to physical devices.
+ OpenContrail uses overlay networking between vRouters
+to deliver highly scalable, multi-tenant connectivity with fine-grained network
+policy and many L2 and L3 networking features not available in the standard
+Neutron API, such as, ARP-proxy, ACLs, ECMP load-balancing, service chaining,
+port mirroring. In addition, OpenContrail provides analytics based on collection of metrics
+from the virtual and physical infrastructure.
+
+More details on the OpenContrail architecture and its operation can be found at
+http://www.opencontrail.org/opencontrail-architecture-documentation/.
+
+Installation
+============
+
+In the Euphrates release of OPNFV, OpenContrail installation is supported using the
+JOID installer. Installation instructions are provided in that project's
+documentation. In summary, following download and deployment of JOID, OpenContrail
+can be deployed using the following command in the <OPNFV_DIR>/joid/ci directory.
+
+./deploy.sh -o ocata -t nonha|ha -s ocl -d xenial -l custom -m openstack
+
+where "nonha" or "ha" indicate if a single instance, or highly available multi-instance
+OpenStack/OpenContrail environment should be deployed.
+
+Using OpenContrail
+==================
+
+The OpenContrail GUI is accessed at <public_ip>:8080 where "public_ip" is the IP address
+that is used to access OpenStack services.
+
+The OpenContrail REST API is found at <public_ip>:8082. Documentation for the API can be found at:
+
+https://www.juniper.net/documentation/en_US/release-independent/contrail/information-products/pathway-pages/api-server/index.html
+
+Python libraries are available for OpenContrail and their use is described at:
+
+https://www.juniper.net/documentation/en_US/release-independent/contrail/information-products/pathway-pages/api-server/tutorial_with_library.html
+
+The OpenContrail controller is deployed in docker containers that run on the corresponding
+ juju services (contrail-controller, contrail-analytics, contrail-analyticsdb). This means
+that OpenContrail command line utilities need to be accessed using using "docker exec". E.g.
+in order to check the status of an OpenContrail cluster, issue the following command from the
+Juju jumphost
+
+$ juju ssh contrail-controller/0 "sudo docker exec contrail-controller contrail-status"
+== Contrail Control ==
+contrail-control: active
+contrail-named: active
+contrail-dns: active
+contrail-control-nodemgr: active
+== Contrail Config ==
+contrail-api: active
+contrail-schema: active
+contrail-svc-monitor: active
+contrail-device-manager: active
+contrail-config-nodemgr: active
+== Contrail Web UI ==
+contrail-webui: active
+contrail-webui-middleware: active
+== Contrail Support Services ==
+rabbitmq-server: active (disabled on boot)
+zookeeper: active
+Connection to 172.16.50.153 closed.
+
+Note that due to the distributed containerized deployment that is used in Juju, the contrail-status
+command only shows the status of services running on that node. So the same command issued to a
+contrail-analytics node yields:
+
+$ juju ssh contrail-analytics/0 "sudo docker exec contrail-analytics contrail-status"
+== Contrail Analytics ==
+contrail-collector: active
+contrail-analytics-api: active
+contrail-query-engine: active
+contrail-alarm-gen: active
+contrail-snmp-collector: active
+contrail-topology: active
+contrail-analytics-nodemgr: active
+Connection to 172.16.50.153 closed.
+
+A set of command line python utilities are provided that implement most OpenContrail features. These
+are located at /opt/contail/utils. Since the nova compute nodes have the contrail utilities installed in the base operating system, it
+can be more convenient to run commands on these types of nodes after logging in using "juju ssh nova/compute/0".
+
+================================
+OpenContrail Community Resources
+================================
+
+The OpenContrail main web site is at www.opencontrail.org.
+
+There are various mailing lists that are used by community members to get answers about deployment and operation
+of OpenContrail. The mailing lists can be joined at http://www.opencontrail.org/newsletter-and-mailing-lists/
+
+
+http://www.opencontrail.org/newsletter-and-mailing-lists/
+
diff --git a/docs/templates/development/design/index.rst b/docs/templates/development/design/index.rst
deleted file mode 100644
index 392b39f..0000000
--- a/docs/templates/development/design/index.rst
+++ /dev/null
@@ -1 +0,0 @@
-.. To be decided
diff --git a/docs/templates/development/overview/index.rst b/docs/templates/development/overview/index.rst
deleted file mode 100644
index caf4dfc..0000000
--- a/docs/templates/development/overview/index.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. 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
deleted file mode 100644
index 498dc06..0000000
--- a/docs/templates/development/overview/overview.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-==============================================
-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
deleted file mode 100644
index 392b39f..0000000
--- a/docs/templates/development/requirements/index.rst
+++ /dev/null
@@ -1 +0,0 @@
-.. To be decided
diff --git a/docs/templates/release/configguide/feature.configuration.rst b/docs/templates/release/configguide/feature.configuration.rst
deleted file mode 100644
index e2fcbbb..0000000
--- a/docs/templates/release/configguide/feature.configuration.rst
+++ /dev/null
@@ -1,256 +0,0 @@
-.. 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
deleted file mode 100644
index 287715d..0000000
--- a/docs/templates/release/configguide/featureconfig.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-.. 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
deleted file mode 100644
index 1789179..0000000
--- a/docs/templates/release/configguide/index.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-.. 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
deleted file mode 100644
index 59a20c6..0000000
--- a/docs/templates/release/configguide/postinstall.rst
+++ /dev/null
@@ -1,38 +0,0 @@
-.. 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
deleted file mode 100644
index 3dbb7c5..0000000
--- a/docs/templates/release/installation/index.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. 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
deleted file mode 100644
index 449f25f..0000000
--- a/docs/templates/release/installation/installation.instruction.rst
+++ /dev/null
@@ -1,210 +0,0 @@
-.. 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
deleted file mode 100644
index e703944..0000000
--- a/docs/templates/release/release-notes/index.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. 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
deleted file mode 100644
index ead095c..0000000
--- a/docs/templates/release/release-notes/release-notes.rst
+++ /dev/null
@@ -1,233 +0,0 @@
-.. 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
deleted file mode 100644
index 37aab84..0000000
--- a/docs/templates/release/scenarios/scenario.name/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. 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
deleted file mode 100644
index 8c2cbab..0000000
--- a/docs/templates/release/scenarios/scenario.name/scenario.description.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-.. 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
deleted file mode 100644
index 1d54d0e..0000000
--- a/docs/templates/release/userguide/feature.userguide.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. 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
deleted file mode 100644
index 5fec000..0000000
--- a/docs/templates/release/userguide/index.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. 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
deleted file mode 100644
index e69de29..0000000
--- a/docs/templates/testing/developer/devguide/index.rst
+++ /dev/null
diff --git a/docs/templates/testing/developer/internship/index.rst b/docs/templates/testing/developer/internship/index.rst
deleted file mode 100644
index e69de29..0000000
--- a/docs/templates/testing/developer/internship/index.rst
+++ /dev/null
diff --git a/docs/templates/testing/index.rst b/docs/templates/testing/index.rst
deleted file mode 100644
index 392b39f..0000000
--- a/docs/templates/testing/index.rst
+++ /dev/null
@@ -1 +0,0 @@
-.. To be decided
diff --git a/docs/templates/testing/user/configguide/configguide.rst b/docs/templates/testing/user/configguide/configguide.rst
deleted file mode 100644
index e69de29..0000000
--- a/docs/templates/testing/user/configguide/configguide.rst
+++ /dev/null
diff --git a/docs/templates/testing/user/configguide/index.rst b/docs/templates/testing/user/configguide/index.rst
deleted file mode 100644
index e69de29..0000000
--- a/docs/templates/testing/user/configguide/index.rst
+++ /dev/null
diff --git a/docs/templates/testing/user/userguide/index.rst b/docs/templates/testing/user/userguide/index.rst
deleted file mode 100644
index e69de29..0000000
--- a/docs/templates/testing/user/userguide/index.rst
+++ /dev/null
diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst
deleted file mode 100644
index 8668859..0000000
--- a/docs/testing/developer/devguide/index.rst
+++ /dev/null
@@ -1,353 +0,0 @@
-.. 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
deleted file mode 100644
index f51fa19..0000000
--- a/docs/testing/ecosystem/index.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-.. 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
deleted file mode 100644
index ed1657c..0000000
--- a/docs/testing/ecosystem/overview.rst
+++ /dev/null
@@ -1,274 +0,0 @@
-.. 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
deleted file mode 100644
index e7b6800..0000000
--- a/docs/testing/testing-dev.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-.. _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
deleted file mode 100644
index 198b090..0000000
--- a/docs/testing/testing-user.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. _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
-
-
-