From fce102283bab73ed08c292fce03e39c52f4a1fe2 Mon Sep 17 00:00:00 2001 From: Stuart Mackie Date: Tue, 29 Aug 2017 05:21:36 -0700 Subject: Added doc directories Change-Id: I671d7c3ad4f4e5e476c98f53780d867dc94b3089 Signed-off-by: Stuart Mackie --- docs/_static/favicon.ico | Bin 0 -> 15086 bytes docs/_static/images/OPNFV_testing_group.png | Bin 0 -> 87295 bytes docs/_static/images/opnfvplatformgraphic.png | Bin 0 -> 136767 bytes docs/_static/my-styles.css | 28 ++ docs/_static/opnfv-logo.png | Bin 0 -> 2829 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 0 -> 85389 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 0 -> 113333 bytes docs/images/opnfvplatformgraphic.png | Bin 0 -> 256545 bytes docs/images/reporting_danube_page.png | Bin 0 -> 56377 bytes docs/images/reporting_page.png | Bin 0 -> 416872 bytes docs/index.rst | 52 +++ 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/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 ++++ 77 files changed, 4310 insertions(+) create mode 100755 docs/_static/favicon.ico create mode 100644 docs/_static/images/OPNFV_testing_group.png create mode 100644 docs/_static/images/opnfvplatformgraphic.png create mode 100644 docs/_static/my-styles.css create mode 100644 docs/_static/opnfv-logo.png create mode 100644 docs/_templates/layout.html create mode 100644 docs/_templates/my_custom_sidebar.html create mode 100644 docs/_templates/relations.html create mode 100644 docs/conf.py create mode 100644 docs/development/feature.templates/scenarios/scenario.name/index.rst create mode 100644 docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst create mode 100644 docs/development/feature.templates/userguide/feature.userguide.rst create mode 100644 docs/development/feature.templates/userguide/index.rst create mode 100644 docs/development/opnfvsecguide/_static/temp create mode 100644 docs/development/opnfvsecguide/_templates/temp create mode 100644 docs/development/opnfvsecguide/audit.rst create mode 100644 docs/development/opnfvsecguide/audit/audit_reqs.rst create mode 100644 docs/development/opnfvsecguide/compute.rst create mode 100644 docs/development/opnfvsecguide/compute/dacmaccontrols.rst create mode 100644 docs/development/opnfvsecguide/compute/trust.rst create mode 100644 docs/development/opnfvsecguide/contribution.rst create mode 100644 docs/development/opnfvsecguide/getting_started.rst create mode 100644 docs/development/opnfvsecguide/index.rst create mode 100644 docs/development/opnfvsecguide/introduction.rst create mode 100644 docs/development/opnfvsecguide/introduction/acknowledgements.rst create mode 100644 docs/development/opnfvsecguide/introduction/background.rst create mode 100644 docs/development/opnfvsecguide/network.rst create mode 100644 docs/development/opnfvsecguide/network/neutron.rst create mode 100644 docs/development/scenario/featurematrix.rst create mode 100644 docs/development/scenario/scenariointro.rst create mode 100644 docs/development/scenario/scenariomatrix.rst create mode 100644 docs/development/scenario/scenariovalidation.rst create mode 100644 docs/featureprojects.rst create mode 100644 docs/glossary/index.rst create mode 100644 docs/how-to-use-docs/Submodules.jpg create mode 100644 docs/how-to-use-docs/addendum.rst create mode 100644 docs/how-to-use-docs/documentation-guide.rst create mode 100644 docs/how-to-use-docs/include-documentation.rst create mode 100644 docs/how-to-use-docs/index.rst create mode 100644 docs/images/OPNFV_testing_working_group.png create mode 100644 docs/images/opnfvplatformgraphic.png create mode 100644 docs/images/reporting_danube_page.png create mode 100644 docs/images/reporting_page.png create mode 100644 docs/index.rst create mode 100755 docs/pre-hook.sh create mode 100644 docs/release/installation.introduction.rst create mode 100644 docs/release/overview.rst create mode 100644 docs/release/release-notes.rst create mode 100644 docs/release/subrelease.rst create mode 100644 docs/release/userguide.introduction.rst create mode 100644 docs/templates/development/design/index.rst create mode 100644 docs/templates/development/overview/index.rst create mode 100644 docs/templates/development/overview/overview.rst create mode 100644 docs/templates/development/requirements/index.rst create mode 100644 docs/templates/release/configguide/feature.configuration.rst create mode 100644 docs/templates/release/configguide/featureconfig.rst create mode 100644 docs/templates/release/configguide/index.rst create mode 100644 docs/templates/release/configguide/postinstall.rst create mode 100644 docs/templates/release/installation/index.rst create mode 100644 docs/templates/release/installation/installation.instruction.rst create mode 100644 docs/templates/release/release-notes/index.rst create mode 100644 docs/templates/release/release-notes/release-notes.rst create mode 100644 docs/templates/release/scenarios/scenario.name/index.rst create mode 100644 docs/templates/release/scenarios/scenario.name/scenario.description.rst create mode 100644 docs/templates/release/userguide/feature.userguide.rst create mode 100644 docs/templates/release/userguide/index.rst create mode 100644 docs/templates/testing/developer/devguide/index.rst create mode 100644 docs/templates/testing/developer/internship/index.rst create mode 100644 docs/templates/testing/index.rst create mode 100644 docs/templates/testing/user/configguide/configguide.rst create mode 100644 docs/templates/testing/user/configguide/index.rst create mode 100644 docs/templates/testing/user/userguide/index.rst create mode 100644 docs/testing/developer/devguide/index.rst create mode 100644 docs/testing/ecosystem/index.rst create mode 100644 docs/testing/ecosystem/overview.rst create mode 100644 docs/testing/testing-dev.rst create mode 100644 docs/testing/testing-user.rst diff --git a/docs/_static/favicon.ico b/docs/_static/favicon.ico new file mode 100755 index 0000000..bbe55ab Binary files /dev/null and b/docs/_static/favicon.ico differ diff --git a/docs/_static/images/OPNFV_testing_group.png b/docs/_static/images/OPNFV_testing_group.png new file mode 100644 index 0000000..4b8c2c0 Binary files /dev/null and b/docs/_static/images/OPNFV_testing_group.png differ diff --git a/docs/_static/images/opnfvplatformgraphic.png b/docs/_static/images/opnfvplatformgraphic.png new file mode 100644 index 0000000..9d6074f Binary files /dev/null and b/docs/_static/images/opnfvplatformgraphic.png differ diff --git a/docs/_static/my-styles.css b/docs/_static/my-styles.css new file mode 100644 index 0000000..94e72cd --- /dev/null +++ b/docs/_static/my-styles.css @@ -0,0 +1,28 @@ +body{ + font-family:"Arial", Helvetica, sans-serif; +} + +.navbar-brand img { + height: 200%; + margin-top: -5%; +} + +.navbar, h1, h2, h3, h4, h5, h6 { + font-family: "Arial",sans-serif; +} + +.navbar-fixed-top { + top: 10px +} + +.navbar-text{ + color: #676767; +} + +.navbar-form.navbar-right{ + padding: 0; +} + +.navbar-form .form-control{ + width: 150px; +} \ No newline at end of file diff --git a/docs/_static/opnfv-logo.png b/docs/_static/opnfv-logo.png new file mode 100644 index 0000000..1519503 Binary files /dev/null and b/docs/_static/opnfv-logo.png differ diff --git a/docs/_templates/layout.html b/docs/_templates/layout.html new file mode 100644 index 0000000..08baa3e --- /dev/null +++ b/docs/_templates/layout.html @@ -0,0 +1,5 @@ +{# Import the theme's layout. #} +{% extends "!layout.html" %} + +{# Custom CSS overrides #} +{% set bootswatch_css_custom = ['_static/my-styles.css'] %} \ No newline at end of file diff --git a/docs/_templates/my_custom_sidebar.html b/docs/_templates/my_custom_sidebar.html new file mode 100644 index 0000000..6b259bc --- /dev/null +++ b/docs/_templates/my_custom_sidebar.html @@ -0,0 +1,3 @@ + \ No newline at end of file diff --git a/docs/_templates/relations.html b/docs/_templates/relations.html new file mode 100644 index 0000000..5bad0b5 --- /dev/null +++ b/docs/_templates/relations.html @@ -0,0 +1,15 @@ +
+
+ {% 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 new file mode 100644 index 0000000..38a8c81 --- /dev/null +++ b/docs/conf.py @@ -0,0 +1,282 @@ +import sphinx_bootstrap_theme +import os + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +# -- General configuration ------------------------------------------------ + +# If your documentation needs a minimal Sphinx version, state it here. +# needs_sphinx = '1.0' +needs_sphinx = '1.3' +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = ['sphinxcontrib.httpdomain', 'sphinx.ext.autodoc', + 'sphinx.ext.viewcode', 'sphinx.ext.napoleon'] +# Disable javasphinx generation until we have a solution to long build +# times. readthedocs timesout after 902 seconds. + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix(es) of source filenames. +# You can specify multiple suffix as a list of string: +# source_suffix = ['.rst', '.md'] +source_suffix = '.rst' + +# The encoding of source files. +# source_encoding = 'utf-8-sig' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = '' +copyright = '2017, OPNFV. Licensed under CC BY 4.0' +author = 'Open Platform for NFV' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = 'Danube' +# The full version, including alpha/beta/rc tags. +release = 'Danube' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +# +# This is also used if you do content translation via gettext catalogs. +# Usually you set "language" from the command line for these cases. +language = None + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +# today = '' +# Else, today_fmt is used as the format for a strftime call. +# today_fmt = '%B %d, %Y' + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +# This patterns also effect to html_static_path and html_extra_path +exclude_patterns = [] + +# The reST default role (used for this markup: `text`) to use for all +# documents. +# default_role = None + +# If true, '()' will be appended to :func: etc. cross-reference text. +# add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +# add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +# show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# A list of ignored prefixes for module index sorting. +# modindex_common_prefix = [] + +# If true, keep warnings as "system message" paragraphs in the built documents. +# keep_warnings = False + +# If true, `todo` and `todoList` produce output, else they produce nothing. +todo_include_todos = False + + +# -- Options for HTML output ---------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +html_theme = 'bootstrap' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +# html_theme_options = {} +html_theme_options = { + 'bootswatch_theme': "journal", + 'navbar_sidebarrel': False, +} + +# Add any paths that contain custom themes here, relative to this directory. +# html_theme_path = [] +html_theme_path = sphinx_bootstrap_theme.get_html_theme_path() + +# The name for this set of Sphinx documents. +# " 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 new file mode 100644 index 0000000..59ada34 --- /dev/null +++ b/docs/development/feature.templates/scenarios/scenario.name/index.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +=================================== + overview and description +=================================== +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 3 + + ./scenario.description.rst + diff --git a/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst b/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst new file mode 100644 index 0000000..afd5879 --- /dev/null +++ b/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst @@ -0,0 +1,32 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +Introduction +============ +.. In this section explain the purpose of the scenario and the types of capabilities provided + +Scenario components and composition +=================================== +.. In this section describe the unique components that make up the scenario, +.. what each component provides and why it has been included in order +.. to communicate to the user the capabilities available in this scenario. + +Scenario usage overview +======================= +.. Provide a brief overview on how to use the scenario and the features available to the +.. user. This should be an "introduction" to the userguide document, and explicitly link to it, +.. where the specifics of the features are covered including examples and API's + +Limitations, Issues and Workarounds +=================================== +.. Explain scenario limitations here, this should be at a design level rather than discussing +.. faults or bugs. If the system design only provide some expected functionality then provide +.. some insight at this point. + +References +========== + +For more information on the OPNFV Colorado release, please visit +http://www.opnfv.org/colorado + diff --git a/docs/development/feature.templates/userguide/feature.userguide.rst b/docs/development/feature.templates/userguide/feature.userguide.rst new file mode 100644 index 0000000..b8adfa5 --- /dev/null +++ b/docs/development/feature.templates/userguide/feature.userguide.rst @@ -0,0 +1,19 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + + 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 new file mode 100644 index 0000000..cc84670 --- /dev/null +++ b/docs/development/feature.templates/userguide/index.rst @@ -0,0 +1,23 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +==================== + user guide +==================== + +.. The feature user guide should provide an OPNFV user with enough information to +.. use the features provided by the feature project in the supported scenarios. +.. This guide should walk a user through the usage of the features once a scenario +.. has been deployed and is active according to the installation guide provided +.. by the installer project. + +.. toctree:: + :maxdepth: 3 + +.. The feature.userguide.rst file should contain the text for this document +.. additional documents can be added to this directory and added in the right order +.. to this file as a list below. + + ./feature.userguide.rst + diff --git a/docs/development/opnfvsecguide/_static/temp b/docs/development/opnfvsecguide/_static/temp new file mode 100644 index 0000000..e69de29 diff --git a/docs/development/opnfvsecguide/_templates/temp b/docs/development/opnfvsecguide/_templates/temp new file mode 100644 index 0000000..e69de29 diff --git a/docs/development/opnfvsecguide/audit.rst b/docs/development/opnfvsecguide/audit.rst new file mode 100644 index 0000000..cdeecba --- /dev/null +++ b/docs/development/opnfvsecguide/audit.rst @@ -0,0 +1,9 @@ +Audit +---------------- + +.. toctree:: + :maxdepth: 2 + + audit/audit_reqs + audit/configuring + diff --git a/docs/development/opnfvsecguide/audit/audit_reqs.rst b/docs/development/opnfvsecguide/audit/audit_reqs.rst new file mode 100644 index 0000000..ce76d01 --- /dev/null +++ b/docs/development/opnfvsecguide/audit/audit_reqs.rst @@ -0,0 +1,110 @@ +Requirements references related to OPNFV Audit + +------------------ +Source information +------------------ + +http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/003/01.01.01_60/gs_NFV-INF003v010101p.pdf +http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/004/01.01.01_60/gs_NFV-INF004v010101p.pdf + +* ETSI GS NFV-SEC 003 V1.1.1 (2014-12) + + - Network Functions Virtualisation NFV); + - NFV Security; Security and Trust Guidance + - NFV-SEC-003_. + + +.. _NFV-SEC-003: http://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/003/01.01.01_60/gs_NFV-SEC003v010101p.pdf +* ETSI GS NFV 004 V1.1.1 (2013-10) + + - Network Functions Virtualisation (NFV); + - Virtualisation Requirements + - NFV-SEC-004_. + +.. _NFV-SEC-004: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf + +Requirements on Auditing framework +---------------------------------- + +Audit records shall be maintained within protected binary logs so that the record of +malicious actions cannot be deleted from the logs. + +Necessary auditable events +-------------------------- + +* access control management + + - Adding a user account + - Modifying user account + - Deleting a user account + - login event + - logout event + - IP whitelisting update + - IP blacklisting update + +* VNFC Creation + + - The instantiation of a newly-defined VNFC + - The instantiation of a VNFC with pre-configured state + - The cloning of an existing VNFC + +* VNFC Deletion + + - The deletion of VNFC and of all of its instances (e.g. snapshots, backups, archives, cloned images) + +* Software management + + - patching e.g. opreating system, drivers, VM components + - dynamic updates to the configuration e.g. DNS, DHCP + - application software updates + - software component updates + +* Data management + + - Root level access to NFVI file system + - User level access to NFVI file system + - Secured wipe, disk and memory + - Verified destruction + - Certificate revocation + +* VNFC Migration + + - VNFC original host identity + - VNFC target host identity + - high availability + - recovery + - data-in-motion changes + +* Other VNFC Operational State Changes + + - Hibernation, sleep, resumption, abort, restore, suspension + - Power-on and power-off (either physical or virtual) + - Integrity verification failure, crash and OS compromise + +* VNFC Topology Changes + + - Network IP address and VLAN updates + - Service chaining + - Failover and disaster recovery + +* traffic inspection + + - enabling virtual port mirroring + - enabling hypervisor introspection + - enabling in-line traffic inspection + - application insertion + +* initial provisioning of a public/private key pair + + - Self-generation of key pairs for later validation by an external party: + + - Certificate Authority + - VNFM + + - Provision by trusted party + + - network + - storage + + - Injection by hypervisor + diff --git a/docs/development/opnfvsecguide/compute.rst b/docs/development/opnfvsecguide/compute.rst new file mode 100644 index 0000000..d6c1a01 --- /dev/null +++ b/docs/development/opnfvsecguide/compute.rst @@ -0,0 +1,8 @@ +Compute Security +---------------- + +.. toctree:: + :maxdepth: 2 + + compute/dacmaccontrols.rst + compute/trust.rst diff --git a/docs/development/opnfvsecguide/compute/dacmaccontrols.rst b/docs/development/opnfvsecguide/compute/dacmaccontrols.rst new file mode 100644 index 0000000..08cd7ee --- /dev/null +++ b/docs/development/opnfvsecguide/compute/dacmaccontrols.rst @@ -0,0 +1,3 @@ +DAC & MAC Controls +------------------ + diff --git a/docs/development/opnfvsecguide/compute/trust.rst b/docs/development/opnfvsecguide/compute/trust.rst new file mode 100644 index 0000000..3022e59 --- /dev/null +++ b/docs/development/opnfvsecguide/compute/trust.rst @@ -0,0 +1,124 @@ +Trusted Compute +--------------- + +Trusted compute is centered on insuring the complete lifecycle of a VM, and +the VM's underlying infrastructure is of a 'trustful' state. + +**Trusted computing in a cloud environment** + +To ensure overall security in an OPNFV deployment, both the launch and the +operation of virtualized resources need to be secure. To build a trusted +computing in a cloud environment the following core features are essential: + +* boot integrity - the hardware platform can guarantee a trustworthy RoT for the overall cloud environment +* secure management of VMs – to secure the launch and migration of VMs in the cloud environment + +In this section we will cover some aspects of what is considered compute +security, such as secure/trusted boot, although of course these can be +extended to other actors such as neutron networking nodes. + +Secure Boot +########### + +Secure boot, a UEFI-based feature that has become controversial lately, +ensures that nodes in an OPNFV deployment boot only software that is trusted +by the admin or end user. + +In order to understand the secure boot procedure, we need to explain the related technology +and specification. + +**Unified Extensible Firmware Interface (UEFI)** + +UEFI is a specification intended to be the replacement and improvement on the +old BIOS (Basic Input/Output System). + +One UEFI-based feature that has become controversial lately is the secure boot feature. + +The UEFI specification is a standard that’s handled by a non-profit organization +with representatives of Intel, AMD, Microsoft, Apple, Dell, HP, IBM and others, +called the Unified EFI Forum. + +UEFI supports 32 and 64 bit processors and can be used with Itanium, x86, +x64 and ARM processors. + +**Trusted Execution Environment (TEE) vs Trusted Platform Mobile (TPM)** + +Two main components of platform security: + +* Trusted Execution Environment +* Trusted Platform Module + +These are not designed as a replacement of the other. TEE is the bulletproof +safe, while TPM is the 128-digit combination lock for the safe. Both are +needed to ensure the safe is protected. + +TPM is a dependency of TEE but not the other way around. + +The TPM is where TEE will store the measurements - hash of components - of the platform. + +If TEE is not supported by a platform but a TPM is still present you still have +all these features: + +* Integrity measurement – securely measure the platform's components (hashes stored within the TPM) + +* Authenticated boot – a process by which a platform's state (the sum of its + components) is reliably measured and stored + +* SRTM - Static Root of Trust for Measurements + +* Sealed Storage - encrypt data based on the current state of the platform + or in other words, what has been measured (the PCR hash values stored in the + TPM) - seal operation + +* Attestation - securely report to other parties the state of the platform + + +Trusted Compute Pools +##################### + +**Trusted Boot** + +Trusted boot (tboot) is an open source, pre- kernel/VMM module that uses +Intel(R) Trusted Execution Technology (Intel(R) TXT) to perform a measured +and verified launch of an OS kernel/VMM. The root of trust is in the hardware +and a TPM is required. Compute nodes in an OPNFV deployment boot with Intel +TXT technology enabled. + +Read more about `Trusted Boot `_ 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 new file mode 100644 index 0000000..683aa2d --- /dev/null +++ b/docs/development/opnfvsecguide/contribution.rst @@ -0,0 +1,45 @@ +How to Contribute +----------------- + +Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation. +To do so, you will however need to first get an enviroment set up. + +Development Environment +####################### + +All project data such as formatting guidelines, and upstream mapping is documented via sphinx +which uses reStructuredText + +It is recommended that you use a python virtualenv to keep things clean and contained. + +VirtualEnv +********** + +Use of a virtual environment is recommended, as not only is it a quick easy form of +getting the needed modules in place, it isolates the module versions to a project. + +From within your inspector directory, set up a new virtualenv:: + + virtualenv venv + +Activate the new virtual environment:: + + source venv/bin/activate + +Install requirements:: + + pip install -r requirements.txt + +Sphinx Basics +************* + +To get started with sphinx, visit the main tutorial which will provide a primer `http://sphinx-doc.org/tutorial.html` + +Hack your changes into opnfv-security-guide/source + +To compile changes: + + make html + +From here you can run a basic python web server or just navigate to the +file:////opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/development/opnfvsecguide/getting_started.rst b/docs/development/opnfvsecguide/getting_started.rst new file mode 100644 index 0000000..e09507d --- /dev/null +++ b/docs/development/opnfvsecguide/getting_started.rst @@ -0,0 +1,41 @@ +Getting Started +--------------- + +Development Environment +####################### + +All project data such as formatting guidelines, and upstream mapping is documented via sphinx +which uses reStructuredText + +VirtualEnv +********** + +Use of a virtual environment is recommended, as not only is it a quick easy form of +getting the needed modules in place, it isolates the module versions to a project. + +From within your inspector directory, set up a new virtualenv:: + + virtualenv venv + +Activate the new virtual environment:: + + source venv/bin/activate + +Install requirements:: + + pip install -r requirements.txt + +Sphinx Basics +************* + +To get started with sphinx, visit the main tutorial which will provide a primer +`http://sphinx-doc.org/tutorial.html` + +Hack your changes into opnfv-security-guide/source + +To compile changes: + + make html + +From here you can run a basic python web server or just navigate to the +file:////opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/development/opnfvsecguide/index.rst b/docs/development/opnfvsecguide/index.rst new file mode 100644 index 0000000..ecefd61 --- /dev/null +++ b/docs/development/opnfvsecguide/index.rst @@ -0,0 +1,21 @@ +.. OPNFV Security Guide documentation master file, created by + sphinx-quickstart on Tue Oct 27 19:30:29 2015. + You can adapt this file completely to your liking, but it should at least + contain the root `toctree` directive. + +Welcome to OPNFV Security Guide +================================================ + +This guide seeks to inform operators who to secure and maintain the security of the OPNFV Platform and its components. + +Contents: + +.. toctree:: + :maxdepth: 2 + + introduction + compute + network + contribution + audit + diff --git a/docs/development/opnfvsecguide/introduction.rst b/docs/development/opnfvsecguide/introduction.rst new file mode 100644 index 0000000..ad80831 --- /dev/null +++ b/docs/development/opnfvsecguide/introduction.rst @@ -0,0 +1,15 @@ +Introduction +--------------- + +The OPNFV Security Guide is the collaborative work of many individuals, +involved in both the OPNFV Security Group and the wider OPNFV community. + +The purpose of this guide is to provide the best practice security guidelines for +deploying the OPNFV platfornm. It is a living document that is updated as +new changes are merged into it's repository. + +.. toctree:: + :maxdepth: 2 + + introduction/background + introduction/acknowledgements diff --git a/docs/development/opnfvsecguide/introduction/acknowledgements.rst b/docs/development/opnfvsecguide/introduction/acknowledgements.rst new file mode 100644 index 0000000..60c687d --- /dev/null +++ b/docs/development/opnfvsecguide/introduction/acknowledgements.rst @@ -0,0 +1,3 @@ +Acknowledgements +---------------- + diff --git a/docs/development/opnfvsecguide/introduction/background.rst b/docs/development/opnfvsecguide/introduction/background.rst new file mode 100644 index 0000000..bd7e44d --- /dev/null +++ b/docs/development/opnfvsecguide/introduction/background.rst @@ -0,0 +1,38 @@ +Background +---------- + +Pre-virtualization security protection was largely centered on the network. +Malicious attacks from hostile machines, would seek to exploit network based +operating systems and applications, with the goal of compromising their +target node. + +Physical security had always been a much simpler business, with most focus on +the secure access of the data center hardware. +In-turn security was built up in layers (defense in depth) where machines +would be +daisy chained with network cables via security appliances to provide +controlled segmentation and isolation. +This form of security was built upon the principle of an 'air gap' +being present, +whereby machines were separate physical units, joined largely by the +network stack. + +With the advent of virtualization (namely the hypervisor), new attack +vectors have +surfaced as the 'air-gap' is no longer key design aspect for security. +Further to this elements orchestation nodes and network controllers +lead to an even wider attack surface: + +* Guests breaking isolation of the hypervisor. + +* Unauthorized access and control of supporting orchestration nodes. + +* Unauthorized access and control of supporting overlay network control systems. + +The hypervisor and the overlay network have now become the 'Achilles heel' +whereby all tenant data isolation is enforced within the hypervisor and its +abstraction +of hardware and the virtualized overlay network. + +This guide has been formulated, in order to assist users of the OPNFV platform +in securing an Telco NFV / SDN environment. diff --git a/docs/development/opnfvsecguide/network.rst b/docs/development/opnfvsecguide/network.rst new file mode 100644 index 0000000..b174479 --- /dev/null +++ b/docs/development/opnfvsecguide/network.rst @@ -0,0 +1,8 @@ +Network Security +---------------- + + +.. toctree:: + :maxdepth: 2 + + network/neutron diff --git a/docs/development/opnfvsecguide/network/neutron.rst b/docs/development/opnfvsecguide/network/neutron.rst new file mode 100644 index 0000000..e7ca060 --- /dev/null +++ b/docs/development/opnfvsecguide/network/neutron.rst @@ -0,0 +1,2 @@ +Neutron Security +---------------- diff --git a/docs/development/scenario/featurematrix.rst b/docs/development/scenario/featurematrix.rst new file mode 100644 index 0000000..2d00a40 --- /dev/null +++ b/docs/development/scenario/featurematrix.rst @@ -0,0 +1,39 @@ +Each scenario provides a set of platform capabilities and features that it supports. It is +possible to identify which features are provided by reviewing the scenario name, however +not all features and capabilities are discernible from the name itself. + +Brahmaputra feature support matrix +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following table provides an overview of the available scenarios and supported features +in the Brahmaputra release of OPNFV. + +.. image:: ../images/brahmaputrafeaturematrix.jpg + :alt: OPNFV Brahmaputra Feature Matrix + +The table above provides an overview of which scenarios will support certain feature capabilities. +The table does not indicate if the feature or scenario has limitations. Refer to the +`Configuration Guide `_ +for details on the state of each scenario and further information. + +Feature development in the Brahmaputra release often consisted of the development of specific +requirements and the further integration and validation of those requirements. This results in some +features only being supported on the platform when a specific scenario, providing the +capabilities necessary to run the feature, is deployed. + +Scenario Naming +^^^^^^^^^^^^^^^ + +In OPNFV, scenarios are identified by short scenario names. These names follow a scheme that +identifies the key components and behaviours of the scenario, the rules for scenario naming are as follows: + + os-[controller]-[feature]-[mode]-[option] + +For example: *os-nosdn-kvm-noha* provides an OpenStack based deployment using neutron including +the OPNFV enhanced KVM hypervisor. + +The [feature] tag in the scenario name describes the main feature provided by the scenario. +This scenario may also provide support for features, such as advanced fault management, which are +not apparent in the scenario name. +The following section describes the features available in each scenario. + diff --git a/docs/development/scenario/scenariointro.rst b/docs/development/scenario/scenariointro.rst new file mode 100644 index 0000000..dd80843 --- /dev/null +++ b/docs/development/scenario/scenariointro.rst @@ -0,0 +1,13 @@ +OPNFV Scenarios +--------------- + +The OPNFV project provides an integration and deployment environment for a variety of components +that can make up a virtualisation platform. OPNFV identifies these variations on the composition of +the platform as scenarios. + +A scenario in OPNFV can be defined as "a deployment of a specific set of platform components". The +composition of a scenario may include specific SDN controller technologies, specific accelerate +switching technologies, or even specific configurations of components to achieve targeted platform +capabilities. Each scenario behaves differetly and it is important to understand the behaviour you +want in order to target the specific scenario you wish to deploy prior to working with the +OPNFV platform. diff --git a/docs/development/scenario/scenariomatrix.rst b/docs/development/scenario/scenariomatrix.rst new file mode 100644 index 0000000..64e1150 --- /dev/null +++ b/docs/development/scenario/scenariomatrix.rst @@ -0,0 +1,100 @@ +Scenarios are implemented as deployable compositions through integration with an installation tool. +OPNFV supports multiple installation tools and for any given release not all tools will support all +scenarios. While our target is to establish parity across the installation tools to ensure they +can provide all scenarios, the practical challenge of achieving that goal for any given feature and +release results in some disparity. + +Brahmaputra scenario overeview +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following table provides an overview of the installation tools and available scenario's +in the Brahmaputra release of OPNFV. + +.. image:: ../images/brahmaputrascenariomatrix.jpg + :alt: OPNFV Brahmaputra Scenario Matrix + +Scenario status is indicated by a weather pattern icon. All scenarios listed with +a weather pattern are possible to deploy and run in your environment or a Pharos lab, +however they may have known limitations or issues as indicated by the icon. + +Weather pattern icon legend: + ++---------------------------------------------+----------------------------------------------------------+ +| Weather Icon | Scenario Status | ++=============================================+==========================================================+ +| .. image:: ../images/weather-clear.jpg | Stable, no known issues | ++---------------------------------------------+----------------------------------------------------------+ +| .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations | ++---------------------------------------------+----------------------------------------------------------+ +| .. image:: ../images/weather-overcast.jpg | Deployable, stability or feature limitations | ++---------------------------------------------+----------------------------------------------------------+ +| .. image:: ../images/weather-dash.jpg | Not deployed with this installer | ++---------------------------------------------+----------------------------------------------------------+ + +Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised +and updates will be made on the stable/brahmaputra branch. While we intend that all Brahmaputra +scenarios should be stable it is worth checking regularly to see the current status. Due to +our dependency on upstream communities and code some issues may not be resolved prior to the C release. + +Scenario Naming +^^^^^^^^^^^^^^^ + +In OPNFV scenarios are identified by short scenario names, these names follow a scheme that +identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows: + + os-[controller]-[feature]-[mode]-[option] + +Details of the fields are + * os: mandatory + + * Refers to the platform type used + * possible value: os (OpenStack) + +* [controller]: mandatory + + * Refers to the SDN controller integrated in the platform + * example values: nosdn, ocl, odl, onos + + * [feature]: mandatory + + * Refers to the feature projects supported by the scenario + * example values: nofeature, kvm, ovs, sfc + + * [mode]: mandatory + + * Refers to the deployment type, which may include for instance high availability + * possible values: ha, noha + + * [option]: optional + + * Used for the scenarios those do not fit into naming scheme. + * The optional field in the short scenario name should not be included if there is no optional scenario. + +Some examples of supported scenario names are: + + * os-nosdn-kvm-noha + + * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor + + * os-onos-nofeature-ha + + * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller + + * os-odl_l2-sfc + + * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features + +Installing your scenario +^^^^^^^^^^^^^^^^^^^^^^^^ + +There are two main methods of deploying your target scenario, one method is to follow this guide which will +walk you through the process of deploying to your hardware using scripts or ISO images, the other method is +to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master. + +For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed +virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing +virtual deployments can be found in the installer specific installation instructions. + +To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide. +`_ + diff --git a/docs/development/scenario/scenariovalidation.rst b/docs/development/scenario/scenariovalidation.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/featureprojects.rst b/docs/featureprojects.rst new file mode 100644 index 0000000..ad60461 --- /dev/null +++ b/docs/featureprojects.rst @@ -0,0 +1,265 @@ +.. _opnfv-featureprojects: + +OPNFV Projects +================ + +Apex +---- +.. toctree:: + :maxdepth: 1 + + ../submodules/apex/docs/development/overview/index + ../submodules/apex/docs/development/requirements/index + ../submodules/apex/docs/release/installation/index + ../submodules/apex/docs/release/configguide/index + ../submodules/apex/docs/release/userguide/index + ../submodules/apex/docs/development/design/index + ../submodules/apex/docs/development/manuals/index + + +Armband +------- +.. toctree:: + :maxdepth: 1 + + ../submodules/armband/docs/development/overview/index + ../submodules/armband/docs/development/requirements/index + ../submodules/armband/docs/release/installation/index + ../submodules/armband/docs/release/configguide/index + ../submodules/armband/docs/release/userguide/index + ../submodules/armband/docs/development/design/index + ../submodules/armband/docs/development/manuals/index + + +Availability +------------ +.. toctree:: + :maxdepth: 1 + + ../submodules/availability/docs/development/overview/index + ../submodules/availability/docs/development/requirements/index + ../submodules/availability/docs/release/installation/index + ../submodules/availability/docs/release/configguide/index + ../submodules/availability/docs/release/userguide/index + ../submodules/availability/docs/development/design/index + ../submodules/availability/docs/development/manuals/index + + +Barometer +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/barometer/docs/development/overview/index + ../submodules/barometer/docs/development/requirements/index + ../submodules/barometer/docs/release/installation/index + ../submodules/barometer/docs/release/configguide/index + ../submodules/barometer/docs/release/userguide/index + ../submodules/barometer/docs/development/design/index + ../submodules/barometer/docs/development/manuals/index + + +Compass4Nfv +----------- +.. toctree:: + :maxdepth: 1 + + ../submodules/compass4nfv/docs/development/overview/index + ../submodules/compass4nfv/docs/development/requirements/index + ../submodules/compass4nfv/docs/release/installation/index + ../submodules/compass4nfv/docs/release/configguide/index + ../submodules/compass4nfv/docs/release/userguide/index + ../submodules/compass4nfv/docs/development/design/index + ../submodules/compass4nfv/docs/development/manuals/index + + +Copper +------ +.. toctree:: + :maxdepth: 1 + + ../submodules/copper/docs/development/overview/index + ../submodules/copper/docs/development/requirements/index + ../submodules/copper/docs/release/installation/index + ../submodules/copper/docs/release/configguide/index + ../submodules/copper/docs/release/userguide/index + ../submodules/copper/docs/development/design/index + ../submodules/copper/docs/development/manuals/index + + +Daisy4NFV +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/daisy/docs/development/design/index + ../submodules/daisy/docs/release/configguide/index + ../submodules/daisy/docs/release/installation/index + + +Doctor +------ +.. toctree:: + :maxdepth: 1 + + ../submodules/doctor/docs/development/overview/index + ../submodules/doctor/docs/development/requirements/index + ../submodules/doctor/docs/release/installation/index + ../submodules/doctor/docs/release/configguide/index + ../submodules/doctor/docs/release/userguide/index + ../submodules/doctor/docs/development/design/index + ../submodules/doctor/docs/development/manuals/index + + +Domino +------ +.. toctree:: + :maxdepth: 1 + + ../submodules/domino/docs/development/overview/index + ../submodules/domino/docs/development/requirements/index + ../submodules/domino/docs/release/installation/index + ../submodules/domino/docs/release/configguide/index + ../submodules/domino/docs/release/userguide/index + ../submodules/domino/docs/development/design/index + ../submodules/domino/docs/development/manuals/index + + +IPV6 +---- +.. toctree:: + :maxdepth: 1 + + ../submodules/ipv6/docs/development/overview/index + ../submodules/ipv6/docs/development/requirements/index + ../submodules/ipv6/docs/release/installation/index + ../submodules/ipv6/docs/release/configguide/index + ../submodules/ipv6/docs/release/userguide/index + ../submodules/ipv6/docs/development/design/index + ../submodules/ipv6/docs/development/manuals/index + + +Joid +---- +.. toctree:: + :maxdepth: 1 + + ../submodules/joid/docs/development/overview/index + ../submodules/joid/docs/development/requirements/index + ../submodules/joid/docs/release/installation/index + ../submodules/joid/docs/release/configguide/index + ../submodules/joid/docs/release/userguide/index + ../submodules/joid/docs/development/design/index + ../submodules/joid/docs/development/manuals/index + + +Kvmfornfv +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/kvmfornfv/docs/development/overview/index + ../submodules/kvmfornfv/docs/development/requirements/index + ../submodules/kvmfornfv/docs/release/installation/index + ../submodules/kvmfornfv/docs/release/configguide/index + ../submodules/kvmfornfv/docs/release/userguide/index + ../submodules/kvmfornfv/docs/development/design/index + ../submodules/kvmfornfv/docs/development/manuals/index + + +Multisite +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/multisite/docs/development/overview/index + ../submodules/multisite/docs/development/requirements/index + ../submodules/multisite/docs/release/installation/index + ../submodules/multisite/docs/release/configguide/index + ../submodules/multisite/docs/release/userguide/index + ../submodules/multisite/docs/development/design/index + ../submodules/multisite/docs/development/manuals/index + + +Netready +-------- +.. toctree:: + :maxdepth: 1 + + ../submodules/netready/docs/development/overview/index + ../submodules/netready/docs/development/requirements/index + ../submodules/netready/docs/release/installation/index + ../submodules/netready/docs/release/configguide/index + ../submodules/netready/docs/release/userguide/index + ../submodules/netready/docs/development/design/index + ../submodules/netready/docs/development/manuals/index + + +Opera +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/opera/docs/development/overview/index + ../submodules/opera/docs/development/requirements/index + ../submodules/opera/docs/release/installation/index + ../submodules/opera/docs/release/configguide/index + ../submodules/opera/docs/release/userguide/index + ../submodules/opera/docs/development/design/index + ../submodules/opera/docs/development/manuals/index + + +Parser +------ +.. toctree:: + :maxdepth: 1 + + ../submodules/parser/docs/development/overview/index + ../submodules/parser/docs/development/requirements/index + ../submodules/parser/docs/release/installation/index + ../submodules/parser/docs/release/configguide/index + ../submodules/parser/docs/release/userguide/index + ../submodules/parser/docs/development/design/index + ../submodules/parser/docs/development/manuals/index + + +Promise +------- +.. toctree:: + :maxdepth: 1 + + ../submodules/promise/docs/development/overview/index + ../submodules/promise/docs/development/requirements/index + ../submodules/promise/docs/release/installation/index + ../submodules/promise/docs/release/configguide/index + ../submodules/promise/docs/release/userguide/index + ../submodules/promise/docs/development/design/index + ../submodules/promise/docs/development/manuals/index + + +SDNVPN +-------- +.. toctree:: + :maxdepth: 1 + + ../submodules/sdnvpn/docs/development/overview/index + ../submodules/sdnvpn/docs/development/requirements/index + ../submodules/sdnvpn/docs/release/installation/index + ../submodules/sdnvpn/docs/release/configguide/index + ../submodules/sdnvpn/docs/release/userguide/index + ../submodules/sdnvpn/docs/development/design/index + + +SFC +--- +.. toctree:: + :maxdepth: 1 + + ../submodules/sfc/docs/development/overview/index + ../submodules/sfc/docs/development/requirements/index + ../submodules/sfc/docs/release/installation/index + ../submodules/sfc/docs/release/configguide/index + ../submodules/sfc/docs/release/userguide/index + ../submodules/sfc/docs/development/design/index + ../submodules/sfc/docs/development/manuals/index + diff --git a/docs/glossary/index.rst b/docs/glossary/index.rst new file mode 100644 index 0000000..be5b6d7 --- /dev/null +++ b/docs/glossary/index.rst @@ -0,0 +1,117 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Christopher Price (Ericsson AB) + +************** +OPNFV Glossary +************** + +======== +Contents +======== + +This glossary provides a common definition of phrases and words commonly used in OPNFV. + +-------- + +A +- + +Arno + + A river running through Tuscany and the name of the first OPNFV release. + +API + Application Programming Interface + +-------- + +B +- + +Brahmaputra + + A river running through Asia and the name of the Second OPNFV release. + +-------- + +C +- + +Colorado + + A river in Argentina and the name of the Third OPNFV release. + +-------- + +D +- + +DPDK + + Data Plane Development Kit + +DPI + + Deep Packet Inspection + +DSCP + + Differentiated Services Code Point + +-------- + +I +- + +IGMP + + Internet Group Management Protocol + +IOPS + + Input/Output Operations Per Second + +-------- + +N +- + +NFV + + Network Functions Virtualisation, an industry initiative to leverage virtualisation technologies in carrier networks. + +NFVI + + Network Function Virtualization Infrastructure + +NIC + + Network Interface Controller + +-------- + +O +- + +OPNFV + + Open Platform for NFV, an open source project developing an NFV reference platform and features. + +-------- + +V +- + +VLAN + + A virtual local area network, typically an isolated ethernet network. + +VM + + Virtual machine, an emulation in software of a computer system. + +VNF + + Virtual network function, typically a networking application or function running in a virtual environment. + diff --git a/docs/how-to-use-docs/Submodules.jpg b/docs/how-to-use-docs/Submodules.jpg new file mode 100644 index 0000000..aeb7956 Binary files /dev/null and b/docs/how-to-use-docs/Submodules.jpg differ diff --git a/docs/how-to-use-docs/addendum.rst b/docs/how-to-use-docs/addendum.rst new file mode 100644 index 0000000..90ab1c7 --- /dev/null +++ b/docs/how-to-use-docs/addendum.rst @@ -0,0 +1,80 @@ +======== +Addendum +======== + +Index File +========== + +The index file must relatively refence your other rst files in that directory. + +Here is an example index.rst : + +.. code-block:: bash + + ******************* + Documentation Title + ******************* + + .. toctree:: + :numbered: + :maxdepth: 2 + + documentation-example + +Source Files +============ + +Document source files have to be written in reStructuredText format (rst). +Each file would be build as an html page. + +Here is an example source rst file : + +.. code-block:: bash + + ============= + Chapter Title + ============= + + Section Title + ============= + + Subsection Title + ---------------- + + Hello! + +Writing RST Markdown +==================== + +See http://sphinx-doc.org/rest.html . + +**Hint:** +You can add dedicated contents by using 'only' directive with build type +('html' and 'singlehtml') for OPNFV document. But, this is not encouraged to +use since this may make different views. + +.. code-block:: bash + + .. only:: html + This line will be shown only in html version. + +Verify Job +---------- + +The verify job name is **docs-verify-rtd-{branch}**. + +When you send document changes to gerrit, jenkins will create your documents +in HTML formats (normal and single-page) to verify that new document can be +built successfully. Please check the jenkins log and artifact carefully. +You can improve your document even though if the build job succeeded. + +Merge Job +---------- + +The merge job name is **docs-merge-rtd-{branch}**. + +Once the patch is merged, jenkins will automatically trigger building of +the new documentation. This might take about 15 minutes while readthedocs +builds the documentatation. The newly built documentation shall show up +as appropriate placed in docs.opnfv.org/{branch}/path-to-file. + diff --git a/docs/how-to-use-docs/documentation-guide.rst b/docs/how-to-use-docs/documentation-guide.rst new file mode 100644 index 0000000..fed42a4 --- /dev/null +++ b/docs/how-to-use-docs/documentation-guide.rst @@ -0,0 +1,135 @@ +=================== +Documentation Guide +=================== + +This page intends to cover the documentation handling for OPNFV. OPNFV projects are expected to create a variety of document types, +according to the nature of the project. Some of these are common to projects that develop/integrate features into the OPNFV platform, e.g. +Installation Instructions and User/Configurations Guides. Other document types may be project-specific. + +.. contents:: + :depth: 3 + :local: + +Getting Started with Documentation for Your Project +--------------------------------------------------- +OPNFV documentation is automated and integrated into our git & gerrit toolchains. + +We use RST document templates in our repositories and automatically render to HTML and PDF versions of the documents in our artifact +store, our WiKi is also able to integrate these rendered documents directly allowing projects to use the revision controlled documentation +process for project information, content and deliverables. +Read :ref:`this page ` 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 new file mode 100644 index 0000000..d1a5a62 --- /dev/null +++ b/docs/how-to-use-docs/include-documentation.rst @@ -0,0 +1,254 @@ +.. _include-documentation: +============================ +Including your Documentation +============================ + +.. contents:: + :depth: 3 + :local: + +In your project repository +-------------------------- + +Add your documentation to your repository in the folder structure and +according to the templates listed above. The documentation templates you +will require are available in opnfvdocs/docs/templates/ repository, you should +copy the relevant templates to your /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 new file mode 100644 index 0000000..424f471 --- /dev/null +++ b/docs/how-to-use-docs/index.rst @@ -0,0 +1,12 @@ +.. _documentation-guide: + +=================== +Documentation Guide +=================== + +.. toctree:: + :maxdepth: 2 + + documentation-guide + include-documentation + addendum diff --git a/docs/images/OPNFV_testing_working_group.png b/docs/images/OPNFV_testing_working_group.png new file mode 100644 index 0000000..f1688cf Binary files /dev/null and b/docs/images/OPNFV_testing_working_group.png differ diff --git a/docs/images/opnfvplatformgraphic.png b/docs/images/opnfvplatformgraphic.png new file mode 100644 index 0000000..8039bcd Binary files /dev/null and b/docs/images/opnfvplatformgraphic.png differ diff --git a/docs/images/reporting_danube_page.png b/docs/images/reporting_danube_page.png new file mode 100644 index 0000000..50bbf60 Binary files /dev/null and b/docs/images/reporting_danube_page.png differ diff --git a/docs/images/reporting_page.png b/docs/images/reporting_page.png new file mode 100644 index 0000000..d8f46a4 Binary files /dev/null and b/docs/images/reporting_page.png differ diff --git a/docs/index.rst b/docs/index.rst new file mode 100644 index 0000000..c5ca836 --- /dev/null +++ b/docs/index.rst @@ -0,0 +1,52 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 + +OPNFV Documentation +=================== + +Open Platform for NFV (OPNFV) facilitates the development and evolution +of NFV components across various open source ecosystems. Through +system level integration, deployment and testing, OPNFV creates a +reference NFV platform to accelerate the transformation of enterprise +and service provider networks. Participation is open to anyone, +whether you are an employee of a member company or just passionate +about network transformation. + +Release +------- + +.. toctree:: + :maxdepth: 1 + + release/overview + release/installation.introduction + release/userguide.introduction + release/release-notes + + +Test Frameworks +--------------- + +.. toctree:: + :maxdepth: 1 + + testing/ecosystem/index + testing/testing-user + testing/testing-dev + + +Developer +--------- + +.. toctree:: + :maxdepth: 1 + + how-to-use-docs/index + featureprojects + + +Infrastructure +-------------- + +.. toctree:: + :maxdepth: 1 diff --git a/docs/pre-hook.sh b/docs/pre-hook.sh new file mode 100755 index 0000000..6574cdc --- /dev/null +++ b/docs/pre-hook.sh @@ -0,0 +1,113 @@ +#!/bin/bash +# SPDX-license-identifier: Apache-2.0 +############################################################################## +# Copyright (c) 2016 NEC and others. +# All rights reserved. This program and the accompanying materials +# are made available under the terms of the Apache License, Version 2.0 +# which accompanies this distribution, and is available at +# http://www.apache.org/licenses/LICENSE-2.0 +############################################################################## + +GIT_CLONE_BASE=${GIT_CLONE_BASE:-ssh://gerrit.opnfv.org:29418} +GERRIT_BRANCH=${GERRIT_BRANCH:-master} +WORKSPACE=${WORKSPACE:-.} + +get_repo_names() { + # NOTE: Not all repositories are ready for the composite docs, + # so we have the repo name list here to add project docs + # one by one. This will be replaced by the list in project.cfg . + # grep -v '^#' releng/jjb/opnfvdocs/project.cfg | sort + echo "apex" + echo "bottlenecks" + echo "compass4nfv" + echo "copper" + echo "daisy" + echo "doctor" + echo "fastpathmetrics" + echo "fuel" + echo "functest" + echo "ipv6" + echo "joid" + echo "ovsnfv" + echo "pharos" + echo "prediction" + echo "promise" + echo "sdnvpn" + echo "vswitchperf" + echo "yardstick" +} + +git_clone() { + _repo="$1" + + [[ -d "$WORKSPACE/$_repo" ]] && return 0 + pushd $WORKSPACE + git clone -b $GERRIT_BRANCH --depth 1 --quiet $GIT_CLONE_BASE/$_repo + popd +} + +repos=$(get_repo_names) + +[[ -e docs/projects ]] && rm -rf docs/projects +mkdir -p docs/projects + +echo +echo "Cloning repos of participating OPNFV Projects and copying docs" +echo +for repo in $repos; do + echo " $repo ($GERRIT_BRANCH)" + git_clone $repo + [[ -e $WORKSPACE/$repo/docs ]] || continue + [[ -e docs/projects/$repo ]] && rm -rf docs/projects/$repo + cp -r $WORKSPACE/$repo/docs docs/projects/$repo +done + +# NOTE: Removing index.rst in project repos to reduce number of docs. +find docs/projects -type f -name 'index.rst' -print | xargs -I i rm -f i + +# fix relative file paths +pattern='.. \(include\|figure\):: *[^ \/]' +base_path="/$(pwd)/docs_build/_src" +find docs/projects -type f -name '*.rst' -print | while read f +do + sed -i -e "/$pattern/s|:: *|:: $base_path/$(dirname ${f#docs/})/|" $f +done + +# for debug +grep -e '.. include::' -e '.. figure::' -r docs/projects + +# NOTE: automated link generation is not ready... +echo +echo "Creating document links" +echo +targets=" +configurationguide/configuration.options.render.rst +configurationguide/scenario.description.rst +userguide/feature.userguide.render.rst +testframework/framework.installation.procedure.render.rst +testframework/framework.userguide.render.rst +" +# configurationguide/post-install.rst +for guide in $targets +do + mainfile="$WORKSPACE/docs/$guide" + basefilename=$(basename ${guide/-/}) + for repo in $repos + do + targetfile="$WORKSPACE/docs/projects/$repo/${guide/-/}" + targetlink="../projects/$repo/${guide/-/}" + projectfilename="${basefilename/.rst/-$repo.rst}" + projectfile="$(dirname $mainfile)/$projectfilename" + [[ -e "$targetfile" ]] || continue + echo "Adding $repo to $guide ..." + echo "" >> $mainfile + echo ".. toctree::" >> $mainfile + echo "" >> $mainfile + echo " $projectfilename" >> $mainfile + echo ".. include:: $targetlink" > $projectfile + done + echo + echo "Generated $guide:" + cat $mainfile + echo +done diff --git a/docs/release/installation.introduction.rst b/docs/release/installation.introduction.rst new file mode 100644 index 0000000..cc43aa1 --- /dev/null +++ b/docs/release/installation.introduction.rst @@ -0,0 +1,100 @@ +.. _opnfv-installation: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) Sofia Wallin Ericsson AB + +============= +Installation +============= + +Abstract +======== + +This document provides an overview of the installation of the Danube release of OPNFV. + +The Danube release can be installed making use of any of the installer projects in OPNFV: +Apex, Compass4Nfv, Fuel or JOID. Each installer provides the ability to install a common OPNFV +platform as well as integrating additional features delivered through a variety of scenarios by +the OPNFV community. + + +Introduction +============ + +The OPNFV platform is comprised of a variety of upstream components that may be deployed on your +infrastructure. A composition of components, tools and configurations is identified in OPNFV as a +deployment scenario. + +The various OPNFV scenarios provide unique features and capabilities that you may want to leverage, and +it is important to understand your required target platform capabilities before installing and +configuring your scenarios. + +An OPNFV installation requires either a physical infrastructure environment as defined +in the `Pharos specification `_, 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 new file mode 100644 index 0000000..7e1d136 --- /dev/null +++ b/docs/release/overview.rst @@ -0,0 +1,296 @@ +.. _opnfv-overview: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) Open Platform for NFV Project, Inc. and its contributors + +================ +Platform overview +================ + +Introduction +============ + +Network Functions Virtualization (NFV) is transforming the networking industry via +software-defined infrastructures and open source is the proven method for quickly developing +software for commercial products and services that can move markets. +Open Platform for NFV (OPNFV) facilitates the development and evolution of NFV +components across various open source ecosystems. Through system level integration, +deployment and testing, OPNFV constructs a reference NFV platform to accelerate the +transformation of enterprise and service provider networks. +As an open source project, OPNFV is uniquely positioned to bring together the work +of standards bodies, open source communities, service providers and commercial suppliers to deliver +a de facto NFV platform for the industry. + +By integrating components from upstream projects, the community is able to conduct performance +and use case-based testing on a variety of solutions to ensure the platform’s suitability for +NFV use cases. OPNFV also works upstream with other open source communities to bring contributions +and learnings from its work directly to those communities in the form of blueprints, patches, bugs, +and new code. + +OPNFV initially focused on building NFV Infrastructure (NFVI) and Virtualised Infrastructure +Management (VIM) by integrating components from upstream projects such as OpenDaylight, +OpenStack, Ceph Storage, KVM, Open vSwitch, and Linux. +More recently, OPNFV has extended its portfolio of forwarding solutions to include fd.io and ODP, +is able to run on both Intel and ARM commercial and white-box hardware, support VM, Container and +BareMetal workloads, and includes Management and Network Orchestration MANO components primarily +for application composition and management in the Danube release. + +These capabilities, along with application programmable interfaces (APIs) to other NFV +elements, form the basic infrastructure required for Virtualized Network Functions (VNF) +and MANO components. + +Concentrating on these components while also considering proposed projects on additional +topics (such as the MANO components and applications themselves), OPNFV aims to enhance +NFV services by increasing performance and power efficiency improving reliability, +availability and serviceability, and delivering comprehensive platform instrumentation. + + +OPNFV Platform Architecture +=========================== + +The OPNFV project addresses a number of aspects in the development of a consistent virtualisation +platform including common hardware requirements, software architecture, MANO and applications. + + +OPNFV Platform Overview Diagram + +.. image:: ../images/opnfvplatformgraphic.png + :alt: Overview infographic of the opnfv platform and projects. + + +To address these areas effectively, the OPNFV platform architecture can be decomposed +into the following basic building blocks: + +* Hardware: with the Infra working group, Pharos project and associated activities +* Software Platform: through the platform integration and deployment projects +* MANO: through the MANO working group and associated projects +* Applications: which affect all other areas and drive requirements for OPNFV + +OPNFV Lab Infrastructure +======================== + +The infrastructure working group oversees such topics as lab management, workflow, +definitions, metrics and tools for OPNFV infrastructure. + +Fundamental to the WG is the +`Pharos Specification `_ +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 new file mode 100644 index 0000000..2eb74d7 --- /dev/null +++ b/docs/release/release-notes.rst @@ -0,0 +1,57 @@ +.. _opnfv-releasenotes: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +============== +Release Notes +============== + +Release notes as provided by the OPNFV participating documents are captured in this section. +These include details of software versions used, known limitations and outstanding trouble +reports. + +Project release notes: +---------------------- + +:ref:`Apex Release Notes ` + +: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 new file mode 100644 index 0000000..075fcbd --- /dev/null +++ b/docs/release/subrelease.rst @@ -0,0 +1,43 @@ +================== +Subrelease Guides +================== + +Apex +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/apex/docs/releasenotes/index + ../submodules/apex/docs/installationprocedure/index + +Compass +-------- +.. toctree:: + :maxdepth: 1 + + ../submodules/compass4nfv/docs/releasenotes/index + ../submodules/compass4nfv/docs/installationprocedure/index + +Daisy +------- +.. toctree:: + :maxdepth: 1 + + ../submodules/daisy/docs/release/release-notes/index + ../submodules/daisy/docs/release/installation/index + +Fuel +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/fuel/docs/releasenotes/index + ../submodules/fuel/docs/installationprocedure/index + +Joid +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/joid/docs/releasenotes/index + ../submodules/joid/docs/installationprocedure/index diff --git a/docs/release/userguide.introduction.rst b/docs/release/userguide.introduction.rst new file mode 100644 index 0000000..8883927 --- /dev/null +++ b/docs/release/userguide.introduction.rst @@ -0,0 +1,87 @@ +.. _opnfv-user-config: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) Sofia Wallin (sofia.wallin@ericssion.com) + +================================= +User Guide & Configuration Guide +================================= + +Abstract +======== + +OPNFV is a collaborative project aimed at providing a variety of virtualisation +deployments intended to host applications serving the networking and carrier +industries. This document provides guidance and instructions for using platform +features designed to support these applications, made available in the OPNFV +Danube release. + +This document is not intended to replace or replicate documentation from other +upstream open source projects such as KVM, OpenDaylight, or OpenStack, but to highlight the +features and capabilities delivered through the OPNFV project. + + +Introduction +============ + +OPNFV provides a suite of scenarios, infrastructure deployment options, which +are able to be installed to host virtualised network functions (VNFs). +This Guide intends to help users of the platform leverage the features and +capabilities delivered by the OPNFV project. + +OPNFVs' Continuous Integration builds, deploys and tests combinations of virtual +infrastructure components in what are defined as scenarios. A scenario may +include components such as KVM, OpenDaylight, OpenStack, OVS, etc., where each +scenario will include different source components or configurations. Scenarios +are designed to enable specific features and capabilities in the platform that +can be leveraged by the OPNFV User community. + + +Feature Overview +================ + +The following links outline the feature deliverables from participating OPNFV +projects in the Danube release. Each of the participating projects provides +detailed descriptions about the delivered features including use cases, +implementation and configuration specifics. + +The following Configuration Guides and User Guides assume that the reader already has some +information about a given project's specifics and deliverables. These Guides +are intended to be used following the installation with an OPNFV installer +to allow users to deploy and implement feature delivered by OPNFV. + +If you are unsure about the specifics of a given project, please refer to the +OPNFV wiki page at http://wiki.opnfv.org, for more details. + + +Feature Configuration Guides +============================ + +- :ref:`Copper Configuration Guide ` +- :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/templates/development/design/index.rst b/docs/templates/development/design/index.rst new file mode 100644 index 0000000..392b39f --- /dev/null +++ b/docs/templates/development/design/index.rst @@ -0,0 +1 @@ +.. To be decided diff --git a/docs/templates/development/overview/index.rst b/docs/templates/development/overview/index.rst new file mode 100644 index 0000000..caf4dfc --- /dev/null +++ b/docs/templates/development/overview/index.rst @@ -0,0 +1,15 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International +.. License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Ericsson AB and others. + +============================================= +OPNFV Overview +============================================= + +For example, the title might be "Qtip Danube Overview" + +.. toctree:: + :maxdepth: 1 + + overview diff --git a/docs/templates/development/overview/overview.rst b/docs/templates/development/overview/overview.rst new file mode 100644 index 0000000..498dc06 --- /dev/null +++ b/docs/templates/development/overview/overview.rst @@ -0,0 +1,16 @@ +============================================== +OPNFV 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 new file mode 100644 index 0000000..392b39f --- /dev/null +++ b/docs/templates/development/requirements/index.rst @@ -0,0 +1 @@ +.. To be decided diff --git a/docs/templates/release/configguide/feature.configuration.rst b/docs/templates/release/configguide/feature.configuration.rst new file mode 100644 index 0000000..e2fcbbb --- /dev/null +++ b/docs/templates/release/configguide/feature.configuration.rst @@ -0,0 +1,256 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Ferenc Cserepkei, Brady Allen Johnson, Manuel Buil and others + +Abstract +======== +This document provides information on how to install the OpenDayLigh SFC +features in OPNFV with the use of os_odl-l2_sfc-(no)ha scenario. + +SFC feature desciription +======================== +For details of the scenarios and their provided capabilities refer to +the scenario description documents: + +- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html + +- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html + + +The SFC feature enables creation of Service Fuction Chains - an ordered list +of chained network funcions (e.g. firewalls, NAT, QoS) + +The SFC feature in OPNFV is implemented by 3 major components: + +- OpenDayLight SDN controller + +- Tacker: Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO) + +- OpenvSwitch: The Service Function Forwarder(s) + +Hardware requirements +===================== + +The SFC scenarios can be deployed on a bare-metal OPNFV cluster or on a +virtual environment on a single host. + +Bare metal deployment on (OPNFV) Pharos lab +------------------------------------------- +Hardware requirements for bare-metal deployments of the OPNFV infrastructure +are given by the Pharos project. The Pharos project provides an OPNFV +hardware specification for configuring your hardware: +http://artifacts.opnfv.org/pharos/docs/pharos-spec.html + + +Virtual deployment +------------------ +To perform a virtual deployment of an OPNFV SFC scenario on a single host, +that host has to meet the following hardware requirements: + +- SandyBridge compatible CPU with virtualization support + +- capable to host 5 virtual cores (5 physical ones at least) + +- 8-12 GBytes RAM for virtual hosts (controller, compute), 48GByte at least + +- 128 GiBiBytes room on disk for each virtual host (controller, compute) + + 64GiBiBytes for fuel master, 576 GiBiBytes at least + +- Ubuntu Trusty Tahr - 14.04(.5) server operating system with at least ssh + service selected at installation. + +- Internet Connection (preferably http proxyless) + + +Pre-configuration activites - Preparing the host to install Fuel by script +========================================================================== +.. Not all of these options are relevant for all scenario's. I advise following the +.. instructions applicable to the deploy tool used in the scenario. + +Before starting the installation of the SFC scenarios some preparation of the +machine that will host the Colorado Fuel cluster must be done. + +Installation of required packages +--------------------------------- +To be able to run the installation of the basic OPNFV fuel installation the +Jumphost (or the host which serves the VMs for the virtual deployment) needs to +install the following packages: +:: + + sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \ + qemu-system tightvncserver virt-manager sshpass \ + fuseiso genisoimage blackbox xterm python-pip \ + python-git python-dev python-oslo.config \ + python-pip python-dev libffi-dev libxml2-dev \ + libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \ + expect curl python-netaddr p7zip-full + + sudo pip install GitPython pyyaml netaddr paramiko lxml scp \ + scp pycrypto ecdsa debtcollector netifaces enum + +During libvirt install the user is added to the libvirtd group, so you have to +logout then login back again + + +Download the installer source code and artifact +----------------------------------------------- +To be able to install the scenario os_odl-l2_sfc-(no)ha one can follow the way +CI is deploying the scenario. +First of all the opnfv-fuel repository needs to be cloned: +:: + + git clone -b 'stable/colorado' ssh://@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 new file mode 100644 index 0000000..287715d --- /dev/null +++ b/docs/templates/release/configguide/featureconfig.rst @@ -0,0 +1,34 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +======== +Abstract +======== +Add a brief introduction to configure OPNFV with this specific feature including +dependancies on platform components, this description should be at a level that +will apply to any installer providing the pre-requisite components. + +.. contents:: + :depth: 3 + :local: + +Pre-configuration activities +============================ +Describe specific pre-configuration activities. This should include ensuring the +right components are installed by the installation tools as required for your +feature to function. Refer to the previous installer configuration chapters, +installations guide and release notes + + +Hardware configuration +====================== +Describe the hardware configuration needed for this specific feature + + +Feature configuration +===================== +Describe the procedures to configure your feature on the platform in order +that it is ready to use according to the feature instructions in the platform +user guide. Where applicable you should add content in the postinstall.rst +to validate the feature is configured for use. +(checking components are installed correctly etc...) diff --git a/docs/templates/release/configguide/index.rst b/docs/templates/release/configguide/index.rst new file mode 100644 index 0000000..1789179 --- /dev/null +++ b/docs/templates/release/configguide/index.rst @@ -0,0 +1,12 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +********************************** + Configuration Guide +********************************** + +.. toctree:: + :maxdepth: 1 + + featureconfig + postinstall diff --git a/docs/templates/release/configguide/postinstall.rst b/docs/templates/release/configguide/postinstall.rst new file mode 100644 index 0000000..59a20c6 --- /dev/null +++ b/docs/templates/release/configguide/postinstall.rst @@ -0,0 +1,38 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +************************************* + 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 new file mode 100644 index 0000000..3dbb7c5 --- /dev/null +++ b/docs/templates/release/installation/index.rst @@ -0,0 +1,11 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +*************************************** + Installation Instruction +*************************************** + +.. toctree:: + :maxdepth: 1 + + installation.instruction diff --git a/docs/templates/release/installation/installation.instruction.rst b/docs/templates/release/installation/installation.instruction.rst new file mode 100644 index 0000000..449f25f --- /dev/null +++ b/docs/templates/release/installation/installation.instruction.rst @@ -0,0 +1,210 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +======== +Abstract +======== + +This document describes how to install , 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 new file mode 100644 index 0000000..e703944 --- /dev/null +++ b/docs/templates/release/release-notes/index.rst @@ -0,0 +1,11 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +**************************** + Release Notes +**************************** + +.. toctree:: + :maxdepth: 1 + + release-notes diff --git a/docs/templates/release/release-notes/release-notes.rst b/docs/templates/release/release-notes/release-notes.rst new file mode 100644 index 0000000..ead095c --- /dev/null +++ b/docs/templates/release/release-notes/release-notes.rst @@ -0,0 +1,233 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + + +This document provides the release notes for 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 new file mode 100644 index 0000000..37aab84 --- /dev/null +++ b/docs/templates/release/scenarios/scenario.name/index.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +**************************************** + overview and description +**************************************** +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 1 + + scenario.description + diff --git a/docs/templates/release/scenarios/scenario.name/scenario.description.rst b/docs/templates/release/scenarios/scenario.name/scenario.description.rst new file mode 100644 index 0000000..8c2cbab --- /dev/null +++ b/docs/templates/release/scenarios/scenario.name/scenario.description.rst @@ -0,0 +1,39 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +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 new file mode 100644 index 0000000..1d54d0e --- /dev/null +++ b/docs/templates/release/userguide/feature.userguide.rst @@ -0,0 +1,23 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +.. 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 new file mode 100644 index 0000000..5fec000 --- /dev/null +++ b/docs/templates/release/userguide/index.rst @@ -0,0 +1,23 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +===================== + User Guide +===================== + +.. The feature user guide should provide an OPNFV user with enough information to +.. use the features provided by the feature project in the supported scenarios. +.. This guide should walk a user through the usage of the features once a scenario +.. has been deployed and is active according to the installation guide provided +.. by the installer project. + +.. toctree:: + :maxdepth: 1 + + feature.userguide +.. The feature.userguide.rst file should contain the text for this document +.. additional documents can be added to this directory and added in the right order +.. to this file as a list below. + + diff --git a/docs/templates/testing/developer/devguide/index.rst b/docs/templates/testing/developer/devguide/index.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/templates/testing/developer/internship/index.rst b/docs/templates/testing/developer/internship/index.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/templates/testing/index.rst b/docs/templates/testing/index.rst new file mode 100644 index 0000000..392b39f --- /dev/null +++ b/docs/templates/testing/index.rst @@ -0,0 +1 @@ +.. To be decided diff --git a/docs/templates/testing/user/configguide/configguide.rst b/docs/templates/testing/user/configguide/configguide.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/templates/testing/user/configguide/index.rst b/docs/templates/testing/user/configguide/index.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/templates/testing/user/userguide/index.rst b/docs/templates/testing/user/userguide/index.rst new file mode 100644 index 0000000..e69de29 diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst new file mode 100644 index 0000000..8668859 --- /dev/null +++ b/docs/testing/developer/devguide/index.rst @@ -0,0 +1,353 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 + +*********************** +Testing developer guide +*********************** + +.. toctree:: + :numbered: + :maxdepth: 2 + + +============ +Introduction +============ + +The OPNFV testing ecosystem is wide. + +The goal of this guide consists in providing some guidelines for new developers +involved in test areas. + +For the description of the ecosystem, see `[1]`_. + + +================= +Developer journey +================= + +Be involved in the testing group +================================ + +Best practices +============== + +Unit tests +---------- + +Dockerization +------------- + +API +--- + +CLI +--- + +Traffic generators +------------------ + +Towards a pseudo micro services approach +---------------------------------------- + +====================================== +Testing group configuration parameters +====================================== + + +Testing categories +================== + +The testing group defined several categories also known as tiers. These +categories can be used to group test suites. + ++----------------+-------------------------------------------------------------+ +| Healthcheck | Simple and quick healthcheck tests case | ++----------------+-------------------------------------------------------------+ +| Smoke | Set of smoke test cases/suites to validate the release | ++----------------+-------------------------------------------------------------+ +| Features | Test cases that validate a specific feature on top of OPNFV.| +| | Those come from Feature projects and need a bit of support | +| | for integration | ++----------------+-------------------------------------------------------------+ +| Components | Tests on a specific component (e.g. OpenStack, OVS, DPDK,..)| +| | It may extend smoke tests | ++----------------+-------------------------------------------------------------+ +| Performance | Performance qualification | ++----------------+-------------------------------------------------------------+ +| VNF | Test cases related to deploy an open source VNF including | +| | an orchestrator | ++----------------+-------------------------------------------------------------+ +| Stress | Stress and robustness tests | ++----------------+-------------------------------------------------------------+ +| In Service | In service testing | ++----------------+-------------------------------------------------------------+ + +Testing domains +=============== + +The domains deal with the technical scope of the tests. It shall correspond to +domains defined for the certification program: + + * compute + * network + * storage + * hypervisor + * container + * vim + * mano + * vnf + * ... + +Testing coverage +================= +One of the goals of the testing working group is to identify the poorly covered +areas and avoid testing overlap. +Ideally based on the declaration of the test cases, through the tags, domains +and tier fields, it shall be possible to create heuristic maps. + + +============================== +Testing group generic enablers +============================== + + +TestAPI framework +================= + +The OPNFV testing group created a test collection database to collect +the test results from CI: + + + http://testresults.opnfv.org/test/swagger/spec.html + +Any test project running on any lab integrated in CI can push the +results to this database. +This database can be used to see the evolution of the tests and compare +the results versus the installers, the scenarios or the labs. +It is used to produce a dashboard with the current test status of the project. + + +Overall Architecture +-------------------- +The Test result management can be summarized as follows:: + + +-------------+ +-------------+ +-------------+ + | | | | | | + | Test | | Test | | Test | + | Project #1 | | Project #2 | | Project #N | + | | | | | | + +-------------+ +-------------+ +-------------+ + | | | + V V V + +-----------------------------------------+ + | | + | Test Rest API front end | + | | + +-----------------------------------------+ + A | + | V + | +-------------------------+ + | | | + | | Test Results DB | + | | Mongo DB | + | | | + | +-------------------------+ + | + | + +----------------------+ + | | + | test Dashboard | + | | + +----------------------+ + +TestAPI description +------------------- +The TestAPI is used to declare pods, projects, test cases and test +results. Pods are the sets of bare metal or virtual servers and networking +equipments used to run the tests. + +The results pushed in the database are related to pods, projects and test cases. +If you try to push results of test done on non referenced pod, the API will +return an error message. + +An additional method dashboard has been added to post-process +the raw results in release Brahmaputra (deprecated in Colorado). + +The data model is very basic, 5 objects are created: + + * Pods + * Projects + * Testcases + * Results + * Scenarios + +The code of the API is hosted in the releng repository `[6]`_. +The static documentation of the API can be found at `[7]`_. +The TestAPI has been dockerized and may be installed locally in your +lab. See `[15]`_ for details. + +The deployment of the TestAPI has been automated. +A jenkins job manages: + + * the unit tests of the TestAPI + * the creation of a new docker file + * the deployment of the new TestAPI + * the archive of the old TestAPI + * the backup of the Mongo DB + +TestAPI Authorization +~~~~~~~~~~~~~~~~~~~~~ + +PUT/DELETE/POST operations of the TestAPI now require token based authorization. The token needs +to be added in the request using a header 'X-Auth-Token' for access to the database. + +e.g:: + headers['X-Auth-Token'] + +The value of the header i.e the token can be accessed in the jenkins environment variable +*TestApiToken*. The token value is added as a masked password. + +.. code-block:: python + + headers['X-Auth-Token'] = os.environ.get('TestApiToken') + +The above example is in Python. Token based authentication has been added so that only ci pods +jenkins job can have access to the database. + +Please note that currently token authorization is implemented but is not yet enabled. + +Reporting +========= + +An automatic reporting page has been created in order to provide a +consistent view of the scenarios. + +In this page, each scenario is evaluated according to test criteria. +The code for the automatic reporting is available at `[8]`_. + +The results are collected from the centralized database every day and, +per scenario. A score is calculated based on the results from the last +10 days. + +Dashboard +========= + +Dashboard is used to provide a consistent view of the results collected in CI. +The results showed on the dashboard are post processed from the Database, +which only contains raw results. + +It can be used in addition of the reporting page (high level view) to allow +the creation of specific graphs according to what the test owner wants to show. + +In Brahmaputra, a basic home made dashboard was created in Functest. +In Colorado, Yardstick adopted Grafana (time based graphs) and ELK (complex +graphs). +Since Danube, the testing community decided to adopt ELK framework and to rely +on bitergia. It was not implemented for Danube but it is planned for Euphrates. + +Bitergia already provides a dashboard for code and infrastructure. +A new Test tab will be added. The dataset will be built by consuming +the TestAPI. + +See `[3]`_ for details. + + +======= +How TOs +======= + +Where can I find information on the different test projects? +=========================================================== + + +How can I contribute to a test project? +======================================= + + +Where can I find hardware resources? +==================================== + + +How do I integrate my tests in CI? +================================== + + +How to declare my tests in the test Database? +============================================= + + +How to push your results into the Test Database? +================================================ + +The test database is used to collect test results. By default it is +enabled only for CI tests from Production CI pods. + +Please note that it is possible to create your own local database. + +A dedicated database is for instance created for each plugfest. + +The architecture and associated API is described in previous chapter. +If you want to push your results from CI, you just have to call the API +at the end of your script. + +You can also reuse a python function defined in functest_utils.py `[5]`_ + + +Where can I find the documentation on the test API? +=================================================== + +http://artifacts.opnfv.org/releng/docs/testapi.html + + + +I have tests, to which category should I declare them? +====================================================== + + + +The main ambiguity could be between features and VNF. +In fact sometimes you have to spawn VMs to demonstrate the capabilities of the +feature you introduced. +We recommend to declare your test in the feature category. + +VNF category is really dedicated to test including: + + * creation of resources + * deployement of an orchestrator/VNFM + * deployment of the VNF + * test of the VNFM + * free resources + +The goal is not to study a particular feature on the infrastructure but to have +a whole end to end test of a VNF automatically deployed in CI. +Moreover VNF are run in weekly jobs (one a week), feature tests are in daily +jobs and use to get a scenario score. + +Where are the logs of CI runs? +============================== + +Logs and configuration files can be pushed to artifact server from the CI under +http://artifacts.opnfv.org/ + + +========== +References +========== + +_`[1]`: http://docs.opnfv.org/en/stable-danube/testing/ecosystem/overview.html + +_`[2]`: http://www.opnfv.org + +_`[3]`: https://wiki.opnfv.org/display/testing/Result+alignment+for+ELK+post-processing + +_`[4]`: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming + +_`[5]`: https://git.opnfv.org/functest/tree/functest/utils/functest_utils.py#176 + +_`[6]`: https://git.opnfv.org/functest/tree/releng + +_`[7]`: http://artifacts.opnfv.org/releng/docs/testapi.html + + +IRC support chan: #opnfv-testperf diff --git a/docs/testing/ecosystem/index.rst b/docs/testing/ecosystem/index.rst new file mode 100644 index 0000000..f51fa19 --- /dev/null +++ b/docs/testing/ecosystem/index.rst @@ -0,0 +1,14 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Christopher Price (Ericsson AB) + +======================== +Test Framework Overview +======================== + +.. toctree:: + :maxdepth: 2 + + ./abstract + ./overview + diff --git a/docs/testing/ecosystem/overview.rst b/docs/testing/ecosystem/overview.rst new file mode 100644 index 0000000..ed1657c --- /dev/null +++ b/docs/testing/ecosystem/overview.rst @@ -0,0 +1,274 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 + +============= +OPNFV testing +============= + +Introduction +============ + +Testing is one of the key activities in OPNFV and includes unit, feature, component, system +level testing for development, automated deployment, performance characterization or stress +testing. + +Test projects are dedicated to provide frameworks, tooling and test-cases categorized as +functional, performance or compliance testing. Test projects fulfill different roles such as +verifying VIM functionality, benchmarking components and platforms or analysis of measured +KPIs for the scenarios released in OPNFV. + +Feature projects also provide their own test suites that either run independently or within a +test project. + +This document details the OPNFV testing ecosystem, describes common test components used +by individual OPNFV projects and provides links to project specific documentation. + + +OPNFV testing ecosystem +======================= + +The testing projects +-------------------- + +The OPNFV testing projects may be summarized as follows: + +.. figure:: ../../images/OPNFV_testing_working_group.png + :align: center + :alt: Overview of OPNFV Testing projects + +The major testing projects are described in the table below: + ++----------------+---------------------------------------------------------+ +| Project | Description | ++================+=========================================================+ +| Bottlenecks | This project aims to find system bottlenecks by testing | +| | and verifying OPNFV infrastructure in a staging | +| | environment before committing it to a production | +| | environment. Instead of debugging a deployment in | +| | production environment, an automatic method for | +| | executing benchmarks which plans to validate the | +| | deployment during staging is adopted. This project | +| | forms a staging framework to find bottlenecks and to do | +| | analysis of the OPNFV infrastructure. | ++----------------+---------------------------------------------------------+ +| CPerf | SDN Controller benchmarks and performance testing, | +| | applicable to controllers in general. Collaboration of | +| | upstream controller testing experts, external test tool | +| | developers and the standards community. Primarily | +| | contribute to upstream/external tooling, then add jobs | +| | to run those tools on OPNFV's infrastructure. | ++----------------+---------------------------------------------------------+ +| Dovetail | This project intends to define and provide a set of | +| | OPNFV related validation criteria that will provide | +| | input for the evaluation of the use of OPNFV trademarks.| +| | The dovetail project is executed with the guidance and | +| | oversight of the Compliance and Certification committee | +| | and work to secure the goals of the C&C committee for | +| | each release. The project intends to incrementally | +| | define qualification criteria that establish the | +| | foundations of how we are able to measure the ability to| +| | utilize the OPNFV platform, how the platform itself | +| | should behave, and how applications may be deployed on | +| | the platform. | ++----------------+---------------------------------------------------------+ +| Functest | This project deals with the functional testing of the | +| | VIM and NFVI. It leverages several upstream test suites | +| | (OpenStack, ODL, ONOS, etc.) and can be used by feature | +| | project to launch feature test suites in CI/CD. | +| | The project is used for scenario validation. | ++----------------+---------------------------------------------------------+ +| Qtip | QTIP as the project for "Platform Performance | +| | Benchmarking" in OPNFV aims to provide user a simple | +| | indicator for performance, supported by comprehensive | +| | testing data and transparent calculation formula. | +| | It provides a platform with common services for | +| | performance benchmarking which helps users to build | +| | indicators by themselves with ease. | ++----------------+---------------------------------------------------------+ +| Storperf | The purpose of this project is to provide a tool to | +| | measure block and object storage performance in an NFVI.| +| | When complemented with a characterization of typical VF | +| | storage performance requirements, it can provide | +| | pass/fail thresholds for test, staging, and production | +| | NFVI environments. | ++----------------+---------------------------------------------------------+ +| VSperf | This project provides a framework for automation of NFV | +| | data-plane performance testing and benchmarking. The | +| | NFVI fast-path includes switch technology and network | +| | with physical and virtual interfaces. VSperf can be | +| | used to evaluate the suitability of different Switch | +| | implementations and features, quantify data-path | +| | performance and optimize platform configurations. | ++----------------+---------------------------------------------------------+ +| Yardstick | The goal of the Project is to verify the infrastructure | +| | compliance when running VNF applications. NFV Use Cases | +| | described in ETSI GS NFV 001 show a large variety of | +| | applications, each defining specific requirements and | +| | complex configuration on the underlying infrastructure | +| | and test tools.The Yardstick concept decomposes typical | +| | VNF work-load performance metrics into a number of | +| | characteristics/performance vectors, which each of them | +| | can be represented by distinct test-cases. | ++----------------+---------------------------------------------------------+ + + +=================================== +The testing working group resources +=================================== + +The assets +========== + +Overall Architecture +-------------------- +The Test result management can be summarized as follows:: + + +-------------+ +-------------+ +-------------+ + | | | | | | + | Test | | Test | | Test | + | Project #1 | | Project #2 | | Project #N | + | | | | | | + +-------------+ +-------------+ +-------------+ + | | | + V V V + +---------------------------------------------+ + | | + | Test Rest API front end | + | http://testresults.opnfv.org/test | + | | + +---------------------------------------------+ + ^ | ^ + | V | + | +-------------------------+ | + | | | | + | | Test Results DB | | + | | Mongo DB | | + | | | | + | +-------------------------+ | + | | + | | + +----------------------+ +----------------------+ + | | | | + | Testing Dashboards | | Landing page | + | | | | + +----------------------+ +----------------------+ + + +The testing databases +--------------------- +A Mongo DB Database has been introduced for the Brahmaputra release. +The following collections are declared in this database: + * pods: the list of pods used for production CI + * projects: the list of projects providing test cases + * testcases: the test cases related to a given project + * results: the results of the test cases + * scenarios: the OPNFV scenarios tested in CI + +This database can be used by any project through the testapi. +Please note that projects may also use additional databases. This database is +mainly use to colelct CI results and scenario trust indicators. + +This database is also cloned for OPNFV Plugfest. + + +The test API +------------ +The Test API is used to declare pods, projects, test cases and test results. +Pods correspond to the cluster of machines (3 controller and 2 compute nodes in +HA mode) used to run the tests and defined in Pharos project. +The results pushed in the database are related to pods, projects and cases. +If you try to push results of test done on non referenced pod, the API will +return an error message. + +An additional method dashboard has been added to post-process the raw results in +the Brahmaputra release (deprecated in Colorado release). + +The data model is very basic, 5 objects are available: + * Pods + * Projects + * Testcases + * Results + * Scenarios + +For detailed information, please go to http://artifacts.opnfv.org/releng/docs/testapi.html + + +The reporting +------------- +The reporting page for the test projects is http://testresults.opnfv.org/reporting/ + +.. figure:: ../../images/reporting_page.png + :align: center + :alt: Testing group reporting page + +This page provides a reporting per OPNFV release and per testing project. + +.. figure:: ../../images/reporting_danube_page.png + :align: center + :alt: Testing group Danube reporting page + +An evolution of this page is planned. +It was decided to unify the reporting by creating a landing page that should give +the scenario status in one glance (it was previously consolidated manually +on a wiki page). + +The landing page (planned for Danube 2.0) will be displayed per scenario: + * the status of the deployment + * the score of the test projectS + * a trust indicator + +Additional filters (version, installer, test collection time window,... ) are +included. + +The test case catalog +--------------------- +Until the Colorado release, each testing project was managing the list of its +test cases. It was very hard to have a global view of the available test cases +among the different test projects. A common view was possible through the API +but it was not very user friendly. +In fact you may know all the cases per project calling: + + http://testresults.opnfv.org/test/api/v1/projects//cases + +with project_name: bottlenecks, functest, qtip, storperf, vsperf, yardstick + +It was decided to build a web site providing a consistent view of the test cases +per project and allow any scenario owner to build his/her custom list of tests +(Danube 2.0). + +Other resources +=============== + +wiki: https://wiki.opnfv.org/testing + +mailing list: test-wg@lists.opnfv.org + +IRC chan: #opnfv-testperf + +weekly meeting (https://wiki.opnfv.org/display/meetings/TestPerf): + * Usual time: Every Thursday 15:00-16:00 UTC / 7:00-8:00 PST + * APAC time: 2nd Wednesday of the month 8:00-9:00 UTC + +======================= +Reference documentation +======================= + ++----------------+---------------------------------------------------------+ +| Project | Documentation links | ++================+=========================================================+ +| Bottlenecks | https://wiki.opnfv.org/display/bottlenecks/Bottlenecks | ++----------------+---------------------------------------------------------+ +| CPerf | https://wiki.opnfv.org/display/cperf | ++----------------+---------------------------------------------------------+ +| Dovetail | https://wiki.opnfv.org/display/dovetail | ++----------------+---------------------------------------------------------+ +| Functest | https://wiki.opnfv.org/display/functest/ | ++----------------+---------------------------------------------------------+ +| Qtip | https://wiki.opnfv.org/display/qtip | ++----------------+---------------------------------------------------------+ +| Storperf | https://wiki.opnfv.org/display/storperf/Storperf | ++----------------+---------------------------------------------------------+ +| VSperf | https://wiki.opnfv.org/display/vsperf | ++----------------+---------------------------------------------------------+ +| Yardstick | https://wiki.opnfv.org/display/yardstick/Yardstick | ++----------------+---------------------------------------------------------+ diff --git a/docs/testing/testing-dev.rst b/docs/testing/testing-dev.rst new file mode 100644 index 0000000..e7b6800 --- /dev/null +++ b/docs/testing/testing-dev.rst @@ -0,0 +1,51 @@ +.. _testing-dev: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +======================== +Testing Developer Guides +======================== + +Testing group +------------- +.. include:: ./developer/devguide/index.rst + +Bottlenecks +------------ +.. toctree:: + :maxdepth: 1 + + ../submodules/bottlenecks/docs/testing/developer/devguide/index + + +Functest +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/functest/docs/testing/developer/devguide/index + + +QTIP +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/qtip/docs/testing/developer/devguide/index + + +VSPERF +------- +.. toctree:: + :maxdepth: 1 + + ../submodules/vswitchperf/docs/testing/developer/devguide/index + + +Yardstick +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/yardstick/docs/testing/developer/devguide/index diff --git a/docs/testing/testing-user.rst b/docs/testing/testing-user.rst new file mode 100644 index 0000000..198b090 --- /dev/null +++ b/docs/testing/testing-user.rst @@ -0,0 +1,65 @@ +.. _testing-userguide: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +=================== +Testing User Guides +=================== + +Bottlenecks +------------ +.. toctree:: + :maxdepth: 1 + + ../submodules/bottlenecks/docs/testing/user/configguide/index + ../submodules/bottlenecks/docs/testing/user/userguide/index + + +Functest +--------- +.. toctree:: + :maxdepth: 1 + + ../submodules/functest/docs/testing/user/configguide/index + ../submodules/functest/docs/testing/user/userguide/index + + +QTIP +----- +.. toctree:: + :maxdepth: 1 + + ../submodules/qtip/docs/testing/user/configguide/index + ../submodules/qtip/docs/testing/user/userguide/index + + +Storperf +-------- + +.. toctree:: + :maxdepth: 1 + + ../submodules/storperf/docs/testing/user/index + + +VSPERF +------ + +.. toctree:: + :maxdepth: 1 + + ../submodules/vswitchperf/docs/testing/user/configguide/index + ../submodules/vswitchperf/docs/testing/user/userguide/index + + +Yardstick +---------- +.. toctree:: + :maxdepth: 1 + + ../submodules/yardstick/docs/testing/user/configguide/index + ../submodules/yardstick/docs/testing/user/userguide/index + + + -- cgit 1.2.3-korg