From fd876b7dbc7d517a706b22e52bf6f0e8f79a0b4b Mon Sep 17 00:00:00 2001 From: Stuart Mackie Date: Thu, 14 Sep 2017 23:26:31 -0700 Subject: Docs Change-Id: Iea3001f8414267f1535353f28d30d45daf9a3e66 Signed-off-by: Stuart Mackie --- docs/_static/favicon.ico | Bin 15086 -> 0 bytes docs/_static/images/OPNFV_testing_group.png | Bin 87295 -> 0 bytes docs/_static/images/opnfvplatformgraphic.png | Bin 136767 -> 0 bytes docs/_static/my-styles.css | 28 -- docs/_static/opnfv-logo.png | Bin 2829 -> 0 bytes docs/_templates/layout.html | 5 - docs/_templates/my_custom_sidebar.html | 3 - docs/_templates/relations.html | 15 - docs/conf.py | 282 ---------------- .../scenarios/scenario.name/index.rst | 16 - .../scenario.name/scenario.description.rst | 32 -- .../userguide/feature.userguide.rst | 19 -- .../feature.templates/userguide/index.rst | 23 -- docs/development/opnfvsecguide/_static/temp | 0 docs/development/opnfvsecguide/_templates/temp | 0 docs/development/opnfvsecguide/audit.rst | 9 - .../development/opnfvsecguide/audit/audit_reqs.rst | 110 ------- docs/development/opnfvsecguide/compute.rst | 8 - .../opnfvsecguide/compute/dacmaccontrols.rst | 3 - docs/development/opnfvsecguide/compute/trust.rst | 124 -------- docs/development/opnfvsecguide/contribution.rst | 45 --- docs/development/opnfvsecguide/getting_started.rst | 41 --- docs/development/opnfvsecguide/index.rst | 21 -- docs/development/opnfvsecguide/introduction.rst | 15 - .../introduction/acknowledgements.rst | 3 - .../opnfvsecguide/introduction/background.rst | 38 --- docs/development/opnfvsecguide/network.rst | 8 - docs/development/opnfvsecguide/network/neutron.rst | 2 - docs/development/scenario/featurematrix.rst | 39 --- docs/development/scenario/scenariointro.rst | 13 - docs/development/scenario/scenariomatrix.rst | 100 ------ docs/development/scenario/scenariovalidation.rst | 0 docs/featureprojects.rst | 265 ---------------- docs/glossary/index.rst | 117 ------- docs/how-to-use-docs/Submodules.jpg | Bin 85389 -> 0 bytes docs/how-to-use-docs/addendum.rst | 80 ----- docs/how-to-use-docs/documentation-guide.rst | 135 -------- docs/how-to-use-docs/include-documentation.rst | 254 --------------- docs/how-to-use-docs/index.rst | 12 - docs/images/OPNFV_testing_working_group.png | Bin 113333 -> 0 bytes docs/images/opnfvplatformgraphic.png | Bin 256545 -> 0 bytes docs/images/reporting_danube_page.png | Bin 56377 -> 0 bytes docs/images/reporting_page.png | Bin 416872 -> 0 bytes docs/index.rst | 33 +- docs/pre-hook.sh | 113 ------- docs/release/installation.introduction.rst | 100 ------ docs/release/overview.rst | 296 ----------------- docs/release/release-notes.rst | 57 ---- docs/release/subrelease.rst | 43 --- docs/release/userguide.introduction.rst | 87 ----- docs/release/userguide.rst | 112 +++++++ docs/templates/development/design/index.rst | 1 - docs/templates/development/overview/index.rst | 15 - docs/templates/development/overview/overview.rst | 16 - docs/templates/development/requirements/index.rst | 1 - .../release/configguide/feature.configuration.rst | 256 --------------- .../release/configguide/featureconfig.rst | 34 -- docs/templates/release/configguide/index.rst | 12 - docs/templates/release/configguide/postinstall.rst | 38 --- docs/templates/release/installation/index.rst | 11 - .../installation/installation.instruction.rst | 210 ------------ docs/templates/release/release-notes/index.rst | 11 - .../release/release-notes/release-notes.rst | 233 -------------- .../release/scenarios/scenario.name/index.rst | 16 - .../scenario.name/scenario.description.rst | 39 --- .../release/userguide/feature.userguide.rst | 23 -- docs/templates/release/userguide/index.rst | 23 -- .../templates/testing/developer/devguide/index.rst | 0 .../testing/developer/internship/index.rst | 0 docs/templates/testing/index.rst | 1 - .../testing/user/configguide/configguide.rst | 0 docs/templates/testing/user/configguide/index.rst | 0 docs/templates/testing/user/userguide/index.rst | 0 docs/testing/developer/devguide/index.rst | 353 --------------------- docs/testing/ecosystem/index.rst | 14 - docs/testing/ecosystem/overview.rst | 274 ---------------- docs/testing/testing-dev.rst | 51 --- docs/testing/testing-user.rst | 65 ---- 78 files changed, 113 insertions(+), 4290 deletions(-) delete mode 100755 docs/_static/favicon.ico delete mode 100644 docs/_static/images/OPNFV_testing_group.png delete mode 100644 docs/_static/images/opnfvplatformgraphic.png delete mode 100644 docs/_static/my-styles.css delete mode 100644 docs/_static/opnfv-logo.png delete mode 100644 docs/_templates/layout.html delete mode 100644 docs/_templates/my_custom_sidebar.html delete mode 100644 docs/_templates/relations.html delete mode 100644 docs/conf.py delete mode 100644 docs/development/feature.templates/scenarios/scenario.name/index.rst delete mode 100644 docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst delete mode 100644 docs/development/feature.templates/userguide/feature.userguide.rst delete mode 100644 docs/development/feature.templates/userguide/index.rst delete mode 100644 docs/development/opnfvsecguide/_static/temp delete mode 100644 docs/development/opnfvsecguide/_templates/temp delete mode 100644 docs/development/opnfvsecguide/audit.rst delete mode 100644 docs/development/opnfvsecguide/audit/audit_reqs.rst delete mode 100644 docs/development/opnfvsecguide/compute.rst delete mode 100644 docs/development/opnfvsecguide/compute/dacmaccontrols.rst delete mode 100644 docs/development/opnfvsecguide/compute/trust.rst delete mode 100644 docs/development/opnfvsecguide/contribution.rst delete mode 100644 docs/development/opnfvsecguide/getting_started.rst delete mode 100644 docs/development/opnfvsecguide/index.rst delete mode 100644 docs/development/opnfvsecguide/introduction.rst delete mode 100644 docs/development/opnfvsecguide/introduction/acknowledgements.rst delete mode 100644 docs/development/opnfvsecguide/introduction/background.rst delete mode 100644 docs/development/opnfvsecguide/network.rst delete mode 100644 docs/development/opnfvsecguide/network/neutron.rst delete mode 100644 docs/development/scenario/featurematrix.rst delete mode 100644 docs/development/scenario/scenariointro.rst delete mode 100644 docs/development/scenario/scenariomatrix.rst delete mode 100644 docs/development/scenario/scenariovalidation.rst delete mode 100644 docs/featureprojects.rst delete mode 100644 docs/glossary/index.rst delete mode 100644 docs/how-to-use-docs/Submodules.jpg delete mode 100644 docs/how-to-use-docs/addendum.rst delete mode 100644 docs/how-to-use-docs/documentation-guide.rst delete mode 100644 docs/how-to-use-docs/include-documentation.rst delete mode 100644 docs/how-to-use-docs/index.rst delete mode 100644 docs/images/OPNFV_testing_working_group.png delete mode 100644 docs/images/opnfvplatformgraphic.png delete mode 100644 docs/images/reporting_danube_page.png delete mode 100644 docs/images/reporting_page.png delete mode 100755 docs/pre-hook.sh delete mode 100644 docs/release/installation.introduction.rst delete mode 100644 docs/release/overview.rst delete mode 100644 docs/release/release-notes.rst delete mode 100644 docs/release/subrelease.rst delete mode 100644 docs/release/userguide.introduction.rst create mode 100644 docs/release/userguide.rst delete mode 100644 docs/templates/development/design/index.rst delete mode 100644 docs/templates/development/overview/index.rst delete mode 100644 docs/templates/development/overview/overview.rst delete mode 100644 docs/templates/development/requirements/index.rst delete mode 100644 docs/templates/release/configguide/feature.configuration.rst delete mode 100644 docs/templates/release/configguide/featureconfig.rst delete mode 100644 docs/templates/release/configguide/index.rst delete mode 100644 docs/templates/release/configguide/postinstall.rst delete mode 100644 docs/templates/release/installation/index.rst delete mode 100644 docs/templates/release/installation/installation.instruction.rst delete mode 100644 docs/templates/release/release-notes/index.rst delete mode 100644 docs/templates/release/release-notes/release-notes.rst delete mode 100644 docs/templates/release/scenarios/scenario.name/index.rst delete mode 100644 docs/templates/release/scenarios/scenario.name/scenario.description.rst delete mode 100644 docs/templates/release/userguide/feature.userguide.rst delete mode 100644 docs/templates/release/userguide/index.rst delete mode 100644 docs/templates/testing/developer/devguide/index.rst delete mode 100644 docs/templates/testing/developer/internship/index.rst delete mode 100644 docs/templates/testing/index.rst delete mode 100644 docs/templates/testing/user/configguide/configguide.rst delete mode 100644 docs/templates/testing/user/configguide/index.rst delete mode 100644 docs/templates/testing/user/userguide/index.rst delete mode 100644 docs/testing/developer/devguide/index.rst delete mode 100644 docs/testing/ecosystem/index.rst delete mode 100644 docs/testing/ecosystem/overview.rst delete mode 100644 docs/testing/testing-dev.rst delete mode 100644 docs/testing/testing-user.rst diff --git a/docs/_static/favicon.ico b/docs/_static/favicon.ico deleted file mode 100755 index bbe55ab..0000000 Binary files a/docs/_static/favicon.ico and /dev/null 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 Binary files a/docs/_static/images/OPNFV_testing_group.png and /dev/null differ diff --git a/docs/_static/images/opnfvplatformgraphic.png b/docs/_static/images/opnfvplatformgraphic.png deleted file mode 100644 index 9d6074f..0000000 Binary files a/docs/_static/images/opnfvplatformgraphic.png and /dev/null 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 Binary files a/docs/_static/opnfv-logo.png and /dev/null 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 @@ - \ 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 @@ -
-
- {% if prev %} - Prev Page - {% else %} - - {% endif %} - - {% if next %} - Next Page - {% else %} - - {% endif %} -
-
\ 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. -# " v 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 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) - -=================================== - 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) - -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) - - 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. - - capabilities and usage -================================ -.. Describe the specific capabilities and usage for feature. -.. Provide enough information that a user will be able to operate the feature on a deployed scenario. - - ------------------------------------------------ -.. 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) - -==================== - 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 diff --git a/docs/development/opnfvsecguide/_templates/temp b/docs/development/opnfvsecguide/_templates/temp deleted file mode 100644 index e69de29..0000000 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 `_ and -`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. `_ - -`NIST SP800-147 `_ -, 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. `_ - 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:////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:////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 `_ -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. -`_ - diff --git a/docs/development/scenario/scenariovalidation.rst b/docs/development/scenario/scenariovalidation.rst deleted file mode 100644 index e69de29..0000000 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 Binary files a/docs/how-to-use-docs/Submodules.jpg and /dev/null 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 ` 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 `_ 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) - - 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:`/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 repository and extract content from other repositories. -To provide content into these documents place your .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:`/docs/release/installation` - -- Folder for documents describing how to deploy each installer and scenario descriptions -- Release notes will be included here -- Security related documents will be included here -- Note that this document will be compiled into 'OPNFV Installation Instruction' - -**User Guide**: :code:`/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:`/docs/release/configguide` - -- Brief introduction to configure OPNFV with its dependencies. - -**Release Notes**: :code:`/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 /docs/release/release-notes - -**User documentation**: :code:`/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:`/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:`/docs/development/requirements/` - -- Folder for your requirement documentation -- For details on requirements projects' structures see the `Requirements Projects `_ page. - -**Design Documentation**: :code:`/docs/development/design` - -- Folder for your upstream design documents (blueprints, development proposals, etc..) - -**Project overview**: :code:`/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 /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://@gerrit.opnfv.org:29418/opnfvdocs.git - cp -p opnfvdocs/docs/userguide/* /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 - - -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 -`_. - -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 ` - -.. 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 `_ 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 - - -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 / - -Move the static files to your project folder: - -.. code-block:: bash - - mv opnfvdocs/_static/ / - -Build the documentation from within your project folder: - -.. code-block:: bash - - sphinx-build -b html - -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 `/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 Binary files a/docs/images/OPNFV_testing_working_group.png and /dev/null differ diff --git a/docs/images/opnfvplatformgraphic.png b/docs/images/opnfvplatformgraphic.png deleted file mode 100644 index 8039bcd..0000000 Binary files a/docs/images/opnfvplatformgraphic.png and /dev/null differ diff --git a/docs/images/reporting_danube_page.png b/docs/images/reporting_danube_page.png deleted file mode 100644 index 50bbf60..0000000 Binary files a/docs/images/reporting_danube_page.png and /dev/null differ diff --git a/docs/images/reporting_page.png b/docs/images/reporting_page.png deleted file mode 100644 index d8f46a4..0000000 Binary files a/docs/images/reporting_page.png and /dev/null 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 `_, 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 ` -- :ref:`os-nosdn-kvm_ovs_dpdk-noha ` -- :ref:`os-nosdn-kvm_ovs_dpdk_bar-noha ` -- :ref:`os-odl_l3-fdio-noha ` -- :ref:`os-odl_l2-fdio-ha ` -- :ref:`os-odl_l2-fdio-noha ` -- :ref:`os-nosdn-fdio-noha ` -- :ref:`os-odl_l2-bgpvpn-noha ` -- :ref:`os-odl_l2-bgpvpn-ha ` -- :ref:`os-odl-gluon-noha ` -- :ref:`os-nosdn-openo-ha ` -- `os-odl_l2-sfc-ha `_ -- `os-odl_l2-sfc-noha `_ -- :ref:`os-nosdn-lxd-ha ` -- :ref:`os-nosdn-lxd-noha ` -- :ref:`k8-nosdn-nofeature-noha ` -- :ref:`k8-nosdn-lb-noha ` -- `os-nosdn-ovs-ha `_ -- :ref:`os-nosdn-ovs-noha ` -- :ref:`os-nosdn-ovs ` -- `os-odl_l3-ovs-ha `_ -- :ref:`os-odl_l3-ovs-noha ` -- :ref:`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 ` -- :ref:`Compass4nfv installation instruction ` -- :ref:`Daisy installation instruction ` -- :ref:`Fuel installation instruction ` -- :ref:`JOID installation instruction ` - -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 ` 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 `_ -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 ` - ------------------ -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 `_ - -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 ` 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 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 ` - -:ref:`Armband Release Notes ` - -:ref:`Bottlenecks Release Notes ` - -:ref:`Compass4nfv Release Notes ` - -:ref:`Copper Release Notes ` - -:ref:`Daisy Release Notes ` - -:ref:`Doctor Release Notes ` - -:ref:`FDS Release Notes ` - -:ref:`Fuel Release Notes ` - -:ref:`Functest Release Notes ` - -:ref:`IPV6 Release Notes ` - -:ref:`Joid Release Notes ` - -:ref:`KVMforNFV Release Notes ` - -:ref:`Netready Release Notes ` - -:ref:`Opera Release Notes ` - -:ref:`Parser Release Notes ` - -:ref:`QTIP Release Notes ` - -:ref:`SDNVPN Release Notes ` - -:ref:`SFC Release Notes ` - -:ref:`VSPERF Release Notes ` - -:ref:`Yardstick Release Notes ` 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 ` -- :ref:`Doctor Configuration Guide ` -- :ref:`IPv6 Configuration Guide ` -- :ref:`KVMforNFV Configuration Guide ` -- :ref:`Netready Configuration Guide ` -- :ref:`ONOSFW Configuration Guide ` -- :ref:`Parser Configuration Guide ` -- :ref:`Promise Configuration Guide ` -- :ref:`SDNVPN Configuration Guide ` -- :ref:`SFC Configuration Guide ` - - -Feature User Guides -=================== - -- :ref:`Copper User Guide ` -- :ref:`Doctor User Guide ` -- :ref:`Domino User Guide ` -- :ref:`IPv6 User Guide ` -- :ref:`KVMforNFV User Guide ` -- :ref:`Netready User Guide ` -- :ref:`ONOSFW User Guide ` -- :ref:`Parser User Guide ` -- :ref:`Promise User Guide ` -- :ref:`SDNVPN User Guide ` -- :ref:`SFC User Guide ` - 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 /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 :8080 where "public_ip" is the IP address +that is used to access OpenStack services. + +The OpenContrail REST API is found at :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 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 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 ------------------------------------ - -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://@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 /deploy/config/labs/devel-pipeline/elx \ - /deploy/config/labs/devel-pipeline/ - -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 /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:///config/ -l devel-pipeline -p - -s os_odl-l2_sfc-ha -i file:// - -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:///config/ -l devel-pipeline -p - -s os_odl-l2_sfc-noha -i file:// - -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:///config/ -l devel-pipeline -p -s os_odl-l2_sfc-ha -i file:// -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 .rpm root@10.20.0.2:.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 - -********************************** - 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 - -************************************* - 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. - - - 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 - -*************************************** - 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 , 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 -============ - - -: - -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 -======= - - -: - -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: - -Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository: -@gerrit.opnf.org/gerrit/genesis> -Check-out the Arno release: - -Goto the fuel directory and build the .iso - - -Familiarize yourself with the Fuel 6.0.1 version by reading the following documents: -- abc -- def -- 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 -===================== - - -: - -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 -================================================ - - -: - -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 -========================================== - - -: - -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 -========================= - - -: - -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 ------------------------------------------- - - -: -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 -========== - - -: - -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 - -**************************** - 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 of . - -.. 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 -=============== - - - -: - -**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 -======= - - - -: - -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 -============ - - -: - -+--------------------------------------+--------------------------------------+ -| **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 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - -: - -- Fuel have changed from 5.1 to 6.0.1 - -- OpenDaylight has changed from Helium-SR1 to Helium-SR2 - -Document version changes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - -: - -- The Fuel@OPNFV installation guide version has changed from version 0.1 to to 0.2 - -Reason for version -^^^^^^^^^^^^^^^^^^^^ -Feature additions -~~~~~~~~~~~~~~~~~~~~~~~ - - -: - -**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 -^^^^^^^^^^^^^^^^^^^^^^^ - - - -: - -Documentation deliverables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - - -: - - -Known Limitations, Issues and Workarounds -========================================= - -System Limitations -^^^^^^^^^^^^^^^^^^^^ - - -: - -**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 -^^^^^^^^^^^^^^^ - - -: - -**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 -^^^^^^^^^^^^^^^^^ - - - -: - -- 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 -=========== - - -: - -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 -========== - - -: - -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) - -**************************************** - 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) - -This document provides scenario level details for of . - -.. 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) - -.. contents:: - :depth: 3 - :local: - - 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. - - capabilities and usage -================================ -.. Describe the specific capabilities and usage for feature. -.. Provide enough information that a user will be able to operate the feature on a deployed scenario. - - -============================================== -.. 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) - -===================== - 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 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 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 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 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 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/ - - -========== -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//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 - - - -- cgit 1.2.3-korg