From 16e36edaec487300f1dd154110077d499bf7726e Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Thu, 6 Sep 2018 10:45:01 +0200 Subject: Adapting local docs build and remove build warnings The OPNFV docs project will remove its submodules and enable local docs builds. This patch prepares the Dovetail repo according to the official transition guide: https://docs.opnfv.org/en/latest/how-to-use-docs/local-build-transition.html This patch also applies syntactical changes which eliminate the sphinx doc build warnings. Change-Id: Ief8fd2d1c3e39b232d214a9ab392879ee4a492c8 Signed-off-by: Georg Kunz (cherry picked from commit a18e2b0d45c631709e457530f6f9d0b52f552156) --- docs/conf.py | 285 +------------- docs/conf.yaml | 3 + docs/index.rst | 24 ++ docs/release/release-notes/dovetail-release.rst | 299 --------------- docs/release/release-notes/index.rst | 261 ++++++++++++- docs/requirements.txt | 5 + .../exemption-strict-API-validation.rst | 2 +- docs/testing/user/reviewerguide/index.rst | 2 +- docs/testing/user/systempreparation/index.rst | 2 +- .../testspecification/highavailability/index.rst | 7 +- docs/testing/user/testspecification/index.rst | 42 +-- .../user/testspecification/stress/index.rst | 4 +- .../tempest_identity_v3/index.rst | 6 +- .../testspecification/tempest_ipv6/ipv6_api.rst | 8 +- .../tempest_network/network_scenario.rst | 417 --------------------- .../tempest_network_scenario/index.rst | 417 +++++++++++++++++++++ .../tempest_trunk_ports/index.rst | 4 +- docs/testing/user/userguide/cli_reference.rst | 2 +- 18 files changed, 745 insertions(+), 1045 deletions(-) create mode 100644 docs/conf.yaml create mode 100644 docs/index.rst delete mode 100644 docs/release/release-notes/dovetail-release.rst create mode 100644 docs/requirements.txt delete mode 100644 docs/testing/user/testspecification/tempest_network/network_scenario.rst create mode 100644 docs/testing/user/testspecification/tempest_network_scenario/index.rst (limited to 'docs') diff --git a/docs/conf.py b/docs/conf.py index fb87bf68..317a2aec 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -1,283 +1,6 @@ -#import sphinx_bootstrap_theme -import sphinx_opnfv_theme -import os +from docs_conf.conf import * -# 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 = 'Latest' -# The full version, including alpha/beta/rc tags. -release = 'Latest' - -# 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 = 'opnfv' - -# 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_opnfv_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'), +linkcheck_ignore = [ + 'https://github.com/opnfv/functest/blob/master/docs/testing/user/userguide/test_details.rst#', + 'https://review.openstack.org/#' ] - -# 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/conf.yaml b/docs/conf.yaml new file mode 100644 index 00000000..5b62ac6e --- /dev/null +++ b/docs/conf.yaml @@ -0,0 +1,3 @@ +--- +project_cfg: opnfv +project: dovetail diff --git a/docs/index.rst b/docs/index.rst new file mode 100644 index 00000000..88523e3b --- /dev/null +++ b/docs/index.rst @@ -0,0 +1,24 @@ +.. 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 + +.. _: dovetail + +======== +Dovetail +======== + +.. toctree:: + :numbered: + :maxdepth: 1 + + testing/user/certificationworkflow/index + testing/user/ovpaddendum/index + testing/user/reviewerguide/index + testing/user/systempreparation/index + testing/user/testspecification/index + testing/user/userguide/index + + testing/developer/testcaserequirements/index + + release/release-notes/index diff --git a/docs/release/release-notes/dovetail-release.rst b/docs/release/release-notes/dovetail-release.rst deleted file mode 100644 index 20129caf..00000000 --- a/docs/release/release-notes/dovetail-release.rst +++ /dev/null @@ -1,299 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 - -======= -License -======= - -OPNFV Fraser release note for Dovetail Docs -are licensed under a Creative Commons Attribution 4.0 International License. -You should have received a copy of the license along with this. -If not, see http://creativecommons.org/licenses/by/4.0/. - -================================================================== -OPNFV Verified Program (OVP) 2018.09 / Dovetail 2.0.0 Release Note -================================================================== - -Abstract -======== - -This document describes the release note of the OPNFV Verified Program and the Dovetail project. - - -Version History -=============== - -+------------+----------+--------------------------+ -| **Date** | **Ver.** | **Comment** | -| | | | -+------------+----------+--------------------------+ -| 2018-01-21 | 1.0.0 | Dovetail for OVP 2018.01 | -| | | Danube release | -+------------+----------+--------------------------+ -| 2018-08-09 | 2.0.0 | Dovetail for OVP 2018.09 | -| | | Fraser release | -+------------+----------+--------------------------+ - - -OPNFV 2018.09 Release -===================== - -The OPNFV Verified Program (OVP) allows vendors and operators to obtain 'OPNFV Verified' -status based on an agreed upon set of compliance verification test cases that align to OPNFV -releases. The reference System under Test (SUT) are the NFV components deployed by the OPNFV -installers for a given release, where OVP 2018.09 is based on the Fraser release. Participants -of the program can verify commercial or open source offerings against an OVP release. This implies -that the SUT used for verification has interfaces, components, functions and behaviors that align -to OPNFV installer integrations. - -Dovetail is the overall framework used to execute tests and collect results for OVP. Dovetail does -not deliver test content directly. Rather, test content is developed in other OPNFV test frameworks -such as Functest and upstream test communities such as OpenStack's RefStack/Tempest projects. -Dovetail leverages this upstream test content and provides a common set of test platform services -for the OVP. - -Dovetail works in conjunction with a web portal interface dubbed the 'OVP web portal' to allow -users to upload test results to a centralized community repository. This facilitates user -collaboration, result sharing, self-testing and community reviews. It also serves as a hub for -new participants to learn about the program and access key resources. The link for this portal -is at: `OPNFV Verified Program `_. - -Use of the OVP web portal is open to all and only requires a valid Linux Foundation or OpenStack -ID to login. Users are welcome to use the portal to upload, inspect and share results in a private -manner. In order to submit results for official review, the first step is apply for acceptance -into the program with the participation form provided in the link: `OPNFV Verified Program -Participation Form `_ - -Test Suites & Test Areas ------------------------- - -OVP/Dovetail groups test cases into test suites and test areas. Test suites are currently a basic -categorization around releases for the most part. Executing the test suite 'ovp.2018.09' without -further specification will run all the test cases in the OVP 2018.09 release. Test suites are -divided into test areas that can be executed separately. - -Test areas include a division into **'mandatory'** and **'optional'** in an overarching -categorization. - -All the mandatory test cases are required to be executed with passing results for all inclusive -test cases for results to be reviewed and approved by the community made up of peer reviewers. -The optional test cases are not required to be executed for the official compliance verification -review in the OVP 2018.09 release. However, execution of these cases is encouraged, as some -optional test cases may become mandatory in future releases. - -Test Cases and Sub Test Cases ------------------------------ - -Each test area consists of multiple test cases where each test case can be a single test or -broken down into sub test cases. A listing of test cases with the number of sub test cases noted -in parenthesis is shown below for the OVP 2018.09 release. - -**Mandatory** - -- functest.vping.userdata (1) -- functest.vping.ssh (1) -- bottlenecks.stress.ping (1) -- functest.tempest.osinterop (200) -- functest.tempest.compute (12) -- functest.tempest.identity_v3 (11) -- functest.tempest.image (2) -- functest.tempest.network_api (14) -- functest.tempest.volume (2) -- functest.tempest.neutron_trunk_ports (38) -- functest.tempest.ipv6_api (21) -- functest.security.patrole (119) -- yardstick.ha.nova_api (1) -- yardstick.ha.neutron_server (1) -- yardstick.ha.keystone (1) -- yardstick.ha.glance_api (1) -- yardstick.ha.cinder_api (1) -- yardstick.ha.cpu_load (1) -- yardstick.ha.disk_load (1) -- yardstick.ha.haproxy (1) -- yardstick.ha.rabbitmq (1) -- yardstick.ha.database (1) - - -There are a total of 432 mandatory test cases. - -**Optional** - -- functest.vnf.vims (1) -- functest.vnf.vepc (1) -- functest.snaps.smoke (1) -- yardstick.ha.neutron_l3_agent (1) -- yardstick.ha.controller_restart (1) -- functest.tempest.ipv6_scenario (8) -- functest.tempest.multi_node_scheduling (6) -- functest.tempest.network_security (6) -- functest.tempest.vm_lifecycle (12) -- functest.tempest.network_scenario (5) -- functest.tempest.bgpvpn (15) -- functest.bgpvpn.subnet_connectivity (1) -- functest.bgpvpn.tenant_separation (1) -- functest.bgpvpn.router_association (1) -- functest.bgpvpn.router_association_floating_ip (1) - - -There are a total of 61 optional test cases. - -OPNFV Test Projects and Components ----------------------------------- - -The OPNFV test frameworks integrated into the Dovetail framework that deliver test content are: - - * Functest (leverages OpenStack RefStack/Tempest projects in addition to supplying native test cases) - * Yardstick - * Bottlenecks - - -Acceptence and Marketing ------------------------- - -Upon successful community review of results for OVP 2018.09, the Linux Foundation Compliance -Verification Committee (LFN CVC) on behalf of the Board of Directors can award a product 'OPNFV -Verified' status. Use of 'OPNFV Verified' Program Marks shall be awarded to the platform used -for compliance verification. The category label of 'Infrastructure' is used within the Program -Marks logo and limits the scope of this OVP release to a SUT consisting of NFVI and VIM components -using ETSI terminology. It does not provide compliance verification for specific VNFs in any fashion. -The date '2018.09' corresponds to a reference SUT that aligns to the OPNFV Fraser release and -currently aligns to the Dovetail framework version 2.0.0. - -Organizations shall not use the Program Marks in any way that would associate it with any -individual or company logo or brand, beyond the association to the specific platform to which it -was awarded. While OpenStack RefStack interoperability and Tempest integration test cases are -executed as part of the OVP 2018.09 compliance verification test suites, the OVP does not grant or -award OpenStack Marks in any fashion. 'OPNFV Verified' status does not assert readiness for -commercial deployment. - -Please refer to the program governance guidelines and term & conditions documents for additional -details using the respective links: - -* `OVP Governance Guidelines `_ -* `OVP Terms and Conditions `_ - -Release Data -============ - -+--------------------------------------+---------------------------------------+ -| **Project** | Dovetail | -| | | -+--------------------------------------+---------------------------------------+ -| **Repo tag** | ovp.2.0.0 | -| | | -+--------------------------------------+---------------------------------------+ -| **Release designation** | OPNFV Verified Program (OVP) | -| | 2018.09 (Fraser) | -+--------------------------------------+---------------------------------------+ -| **Release date** | August xxxx 2018 | -| | | -+--------------------------------------+---------------------------------------+ -| **Purpose of the delivery** | Support OVP 2018.09 release with | -| | OPNFV Fraser release as reference SUT | -+--------------------------------------+---------------------------------------+ - -Deliverables -============ - -Software --------- -+-------------------------+-----------------------------------+---------------+ -| **Docker Container** | **Docker Image** | **Tag** | -+-------------------------+-----------------------------------+---------------+ -| dovetail | opnfv/dovetail | ovp.2.0.0 | -+-------------------------+-----------------------------------+---------------+ -| functest | opnfv/functest-smoke | fraser | -+-------------------------+-----------------------------------+---------------+ -| functest | opnfv/functest-healthcheck | fraser | -+-------------------------+-----------------------------------+---------------+ -| functest | opnfv/functest-features | fraser | -+-------------------------+-----------------------------------+---------------+ -| functest | opnfv/functest-vnf | fraser | -+-------------------------+-----------------------------------+---------------+ -| yardstick | opnfv/yardstick | stable | -+-------------------------+-----------------------------------+---------------+ -| bottlenecks | opnfv/bottlenecks | stable | -+-------------------------+-----------------------------------+---------------+ - - -Docker images: - -- `Dovetail Docker images `_ -- `Functest-smoke Docker images `_ -- `Functest-healthcheck Docker images `_ -- `Functest-features Docker images `_ -- `Functest-vnf Docker images `_ -- `Yardstick Docker images `_ -- `Bottlenecks Docker images `_ - - - -Documents ---------- - -- `System Preparation Guide `_ - -- `User Guide `_ - -- `OPV Test Specifications `_ - -- `Dovetail CLI Reference `_ - -- `OPV Workflow `_ - -- `OPV Reviewer Guide `_ - - -Testing with OPNFV Fraser Installers -==================================== - -OVP 2018.09 and Dovetail 2.0.0 are known to be have been tested with the following OPNFV -Fraser installer versions. - -+-----------------+----------------------+ -| Installer | Version | -+=================+======================+ -| Apex | opnfv-6.2.0 | -+-----------------+----------------------+ -| Compass | opnfv-6.2.0 | -+-----------------+----------------------+ -| Fuel | fraser.x.x | -+-----------------+----------------------+ - - -Fraser Known Restrictions/Issues -================================ - -Please refer to the following link for known issues with the Dovetail Fraser release: - -.. https://wiki.opnfv.org/display/dovetail/Running+history+for+the+dovetail+tool#Runninghistoryforthedovetailtool-4.KnownIssuesList - -Open JIRA Tickets -================= - -+------------------+-----------------------------------------------+ -| JIRA | Description | -+==================+===============================================+ -| | | -| xxxxxx | | -+------------------+-----------------------------------------------+ - -All blocking tickets have been fixed. - - -Useful Links -============ - - - `OVP Web Portal `_ - - - `Wiki Project Page `_ - - - `Dovetail Repo `_ - - - `Dovetail CI dashboard `_ - - - `JIRA dashboard `_ - - - Dovetail IRC Channel: #opnfv-dovetail - - - `Dovetail Test Configuration `_ diff --git a/docs/release/release-notes/index.rst b/docs/release/release-notes/index.rst index ad4cade0..0332622f 100644 --- a/docs/release/release-notes/index.rst +++ b/docs/release/release-notes/index.rst @@ -3,18 +3,259 @@ .. _dovetail-releasenotes: -********************** -Dovetail Release Notes -********************** +================================================================== +OPNFV Verified Program (OVP) 2018.09 / Dovetail 2.0.0 Release Note +================================================================== -.. toctree:: - :numbered: - :maxdepth: 4 - dovetail-release.rst +OPNFV 2018.09 Release +===================== -Revision: _sha1_ +The OPNFV Verified Program (OVP) allows vendors and operators to obtain 'OPNFV Verified' +status based on an agreed upon set of compliance verification test cases that align to OPNFV +releases. The reference System under Test (SUT) are the NFV components deployed by the OPNFV +installers for a given release, where OVP 2018.09 is based on the Fraser release. Participants +of the program can verify commercial or open source offerings against an OVP release. This implies +that the SUT used for verification has interfaces, components, functions and behaviors that align +to OPNFV installer integrations. -:Author: Eddie Arrage (eddie.arrage@huawei.com) +Dovetail is the overall framework used to execute tests and collect results for OVP. Dovetail does +not deliver test content directly. Rather, test content is developed in other OPNFV test frameworks +such as Functest and upstream test communities such as OpenStack's RefStack/Tempest projects. +Dovetail leverages this upstream test content and provides a common set of test platform services +for the OVP. -Build date: |today| +Dovetail works in conjunction with a web portal interface dubbed the 'OVP web portal' to allow +users to upload test results to a centralized community repository. This facilitates user +collaboration, result sharing, self-testing and community reviews. It also serves as a hub for +new participants to learn about the program and access key resources. The link for this portal +is at: `OPNFV Verified Program `_. + +Use of the OVP web portal is open to all and only requires a valid Linux Foundation or OpenStack +ID to login. Users are welcome to use the portal to upload, inspect and share results in a private +manner. In order to submit results for official review, the first step is apply for acceptance +into the program with the participation form provided in the link: `OPNFV Verified Program +Participation Form `_ + +Test Suites & Test Areas +------------------------ + +OVP/Dovetail groups test cases into test suites and test areas. Test suites are currently a basic +categorization around releases for the most part. Executing the test suite 'ovp.2018.09' without +further specification will run all the test cases in the OVP 2018.09 release. Test suites are +divided into test areas that can be executed separately. + +Test areas include a division into **'mandatory'** and **'optional'** in an overarching +categorization. + +All the mandatory test cases are required to be executed with passing results for all inclusive +test cases for results to be reviewed and approved by the community made up of peer reviewers. +The optional test cases are not required to be executed for the official compliance verification +review in the OVP 2018.09 release. However, execution of these cases is encouraged, as some +optional test cases may become mandatory in future releases. + +Test Cases and Sub Test Cases +----------------------------- + +Each test area consists of multiple test cases where each test case can be a single test or +broken down into sub test cases. A listing of test cases with the number of sub test cases noted +in parenthesis is shown below for the OVP 2018.09 release. + +**Mandatory** + +- functest.vping.userdata (1) +- functest.vping.ssh (1) +- bottlenecks.stress.ping (1) +- functest.tempest.osinterop (200) +- functest.tempest.compute (12) +- functest.tempest.identity_v3 (11) +- functest.tempest.image (2) +- functest.tempest.network_api (14) +- functest.tempest.volume (2) +- functest.tempest.neutron_trunk_ports (38) +- functest.tempest.ipv6_api (21) +- functest.security.patrole (119) +- yardstick.ha.nova_api (1) +- yardstick.ha.neutron_server (1) +- yardstick.ha.keystone (1) +- yardstick.ha.glance_api (1) +- yardstick.ha.cinder_api (1) +- yardstick.ha.cpu_load (1) +- yardstick.ha.disk_load (1) +- yardstick.ha.haproxy (1) +- yardstick.ha.rabbitmq (1) +- yardstick.ha.database (1) + + +There are a total of 432 mandatory test cases. + +**Optional** + +- functest.vnf.vims (1) +- functest.vnf.vepc (1) +- functest.snaps.smoke (1) +- yardstick.ha.neutron_l3_agent (1) +- yardstick.ha.controller_restart (1) +- functest.tempest.ipv6_scenario (8) +- functest.tempest.multi_node_scheduling (6) +- functest.tempest.network_security (6) +- functest.tempest.vm_lifecycle (12) +- functest.tempest.network_scenario (5) +- functest.tempest.bgpvpn (15) +- functest.bgpvpn.subnet_connectivity (1) +- functest.bgpvpn.tenant_separation (1) +- functest.bgpvpn.router_association (1) +- functest.bgpvpn.router_association_floating_ip (1) + + +There are a total of 61 optional test cases. + +OPNFV Test Projects and Components +---------------------------------- + +The OPNFV test frameworks integrated into the Dovetail framework that deliver test content are: + + * Functest (leverages OpenStack RefStack/Tempest projects in addition to supplying native test cases) + * Yardstick + * Bottlenecks + + +Acceptence and Marketing +------------------------ + +Upon successful community review of results for OVP 2018.09, the Linux Foundation Compliance +Verification Committee (LFN CVC) on behalf of the Board of Directors can award a product 'OPNFV +Verified' status. Use of 'OPNFV Verified' Program Marks shall be awarded to the platform used +for compliance verification. The category label of 'Infrastructure' is used within the Program +Marks logo and limits the scope of this OVP release to a SUT consisting of NFVI and VIM components +using ETSI terminology. It does not provide compliance verification for specific VNFs in any fashion. +The date '2018.09' corresponds to a reference SUT that aligns to the OPNFV Fraser release and +currently aligns to the Dovetail framework version 2.0.0. + +Organizations shall not use the Program Marks in any way that would associate it with any +individual or company logo or brand, beyond the association to the specific platform to which it +was awarded. While OpenStack RefStack interoperability and Tempest integration test cases are +executed as part of the OVP 2018.09 compliance verification test suites, the OVP does not grant or +award OpenStack Marks in any fashion. 'OPNFV Verified' status does not assert readiness for +commercial deployment. + +Please refer to the program governance guidelines and term & conditions documents for additional +details using the respective links: + +* `OVP Governance Guidelines `_ +* `OVP Terms and Conditions `_ + +Release Data +============ + ++--------------------------------------+---------------------------------------+ +| **Project** | Dovetail | +| | | ++--------------------------------------+---------------------------------------+ +| **Repo tag** | ovp.2.0.0 | +| | | ++--------------------------------------+---------------------------------------+ +| **Release designation** | OPNFV Verified Program (OVP) | +| | 2018.09 (Fraser) | ++--------------------------------------+---------------------------------------+ +| **Release date** | September 2018 | +| | | ++--------------------------------------+---------------------------------------+ +| **Purpose of the delivery** | Support OVP 2018.09 release with | +| | OPNFV Fraser release as reference SUT | ++--------------------------------------+---------------------------------------+ + +Deliverables +============ + +Software +-------- ++-------------------------+-----------------------------------+---------------+ +| **Docker Container** | **Docker Image** | **Tag** | ++-------------------------+-----------------------------------+---------------+ +| dovetail | opnfv/dovetail | ovp.2.0.0 | ++-------------------------+-----------------------------------+---------------+ +| functest | opnfv/functest-smoke | fraser | ++-------------------------+-----------------------------------+---------------+ +| functest | opnfv/functest-healthcheck | fraser | ++-------------------------+-----------------------------------+---------------+ +| functest | opnfv/functest-features | fraser | ++-------------------------+-----------------------------------+---------------+ +| functest | opnfv/functest-vnf | fraser | ++-------------------------+-----------------------------------+---------------+ +| yardstick | opnfv/yardstick | stable | ++-------------------------+-----------------------------------+---------------+ +| bottlenecks | opnfv/bottlenecks | stable | ++-------------------------+-----------------------------------+---------------+ + + +Docker images: + +- `Dovetail Docker images `_ +- `Functest-smoke Docker images `_ +- `Functest-healthcheck Docker images `_ +- `Functest-features Docker images `_ +- `Functest-vnf Docker images `_ +- `Yardstick Docker images `_ +- `Bottlenecks Docker images `_ + + + +Documents +--------- + +- `System Preparation Guide `_ + +- `User Guide `_ + +- `OPV Test Specifications `_ + +- `Dovetail CLI Reference `_ + +- `OPV Workflow `_ + +- `OPV Reviewer Guide `_ + + +Testing with OPNFV Fraser Installers +==================================== + +OVP 2018.09 and Dovetail 2.0.0 are known to be have been tested with the following OPNFV +Fraser installer versions. + ++-----------------+----------------------+ +| Installer | Version | ++=================+======================+ +| Apex | stable/fraser | ++-----------------+----------------------+ +| Compass | stable/fraser | ++-----------------+----------------------+ +| Fuel | stable/fraser | ++-----------------+----------------------+ + + +Fraser Known Restrictions/Issues +================================ + +Please refer to the Dovetail project JIRA for known issues with the Dovetail +Fraser release: + +.. https://jira.opnfv.org/projects/DOVETAIL + + +Useful Links +============ + + - `OVP Web Portal `_ + + - `Wiki Project Page `_ + + - `Dovetail Repo `_ + + - `Dovetail CI dashboard `_ + + - `JIRA dashboard `_ + + - Dovetail IRC Channel: #opnfv-dovetail + + - `Dovetail Test Configuration `_ diff --git a/docs/requirements.txt b/docs/requirements.txt new file mode 100644 index 00000000..44084358 --- /dev/null +++ b/docs/requirements.txt @@ -0,0 +1,5 @@ +lfdocs-conf +sphinx_opnfv_theme +# Uncomment the following line if your project uses Sphinx to document +# HTTP APIs +# sphinxcontrib-httpdomain diff --git a/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst b/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst index b4466111..aaac6c4c 100644 --- a/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst +++ b/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst @@ -89,7 +89,7 @@ Example: additional attributes per VM for HA policy --------------------------------------------------- This fictional example showcases the presence of an additional attribute in an -API response. The example shows that the 'server details', i.e. the VM +API response. The example shows that the 'server details' [3]_, i.e. the VM metadata, includes an additional attribute 'ha-policy' which is used to associate high-availability policies with a VM instance. This attribute is utilized by a proprietary add-on component to manage VM migration and recovery diff --git a/docs/testing/user/reviewerguide/index.rst b/docs/testing/user/reviewerguide/index.rst index 25dc2f68..dd9456ce 100644 --- a/docs/testing/user/reviewerguide/index.rst +++ b/docs/testing/user/reviewerguide/index.rst @@ -155,7 +155,7 @@ The bottlenecks log must contain the 'SUCCESS' result as shown in following exam Functest logs opens an html page that lists all test cases as shown in figure 7. All test cases must have run successfuly. -.. image:: images/ovp_log_functest_image.png +.. image:: images/ovp_log_files_functest_image.png :align: center :scale: 100% diff --git a/docs/testing/user/systempreparation/index.rst b/docs/testing/user/systempreparation/index.rst index 4e101146..5bc150a3 100644 --- a/docs/testing/user/systempreparation/index.rst +++ b/docs/testing/user/systempreparation/index.rst @@ -52,7 +52,7 @@ The SUT is expected to be connected with high performance networks. These networ are expected in the SUT: - A management network by which the Test Node can reach all identity, image, network, -and compute services in the SUT + and compute services in the SUT - A data network that supports the virtual network capabilities and data path testing Additional networks, such as Light Out Management or storage networks, may be diff --git a/docs/testing/user/testspecification/highavailability/index.rst b/docs/testing/user/testspecification/highavailability/index.rst index e024b1fc..dd98ba94 100644 --- a/docs/testing/user/testspecification/highavailability/index.rst +++ b/docs/testing/user/testspecification/highavailability/index.rst @@ -810,9 +810,10 @@ For second monitor is used a process monitor and the main purpose is to watch whether the database processes on the host node are killed properly. Therefore, in this test case, there are two metrics: -- service_outage_time, which indicates the maximum outage time (seconds) + +* service_outage_time, which indicates the maximum outage time (seconds) of the specified OpenStack command request -- process_recover_time, which indicates the maximum time (seconds) from the +* process_recover_time, which indicates the maximum time (seconds) from the process being killed to recovered Test execution @@ -1056,7 +1057,7 @@ Process recovery is verified by checking the existence of processes of Test execution '''''''''''''' * Test action 1: Two host VMs are booted, these two hosts are in two different -networks, the networks are connected by a virtual router. + networks, the networks are connected by a virtual router. * Test action 2: Start monitors: each monitor will run with independently process. The monitor info will be collected. * Test action 3: Do attacker: Connect the host through SSH, and then execute the kill diff --git a/docs/testing/user/testspecification/index.rst b/docs/testing/user/testspecification/index.rst index fff07ee9..9fff4689 100644 --- a/docs/testing/user/testspecification/index.rst +++ b/docs/testing/user/testspecification/index.rst @@ -25,24 +25,24 @@ All tests areas addressed in the OVP are covered in the following test specification documents. .. toctree:: - :maxdepth: 1 - - ./highavailability/index.rst - ./tempest_osinterop/index.rst - ./vping/index.rst - ./tempest_trunk_ports/index.rst - ./security_patrole/index.rst - ./tempest_ipv6/index.rst - ./tempest_network_security/index.rst - ./tempest_network/network_scenario.rst - ./tempest_vm_lifecycle/index.rst - ./tempest_multi_node_scheduling/index.rst - ./vpn/index.rst - ./vnf/index.rst - ./stress/index.rst - ./snaps_smoke/index.rst - ./tempest_compute/index.rst - ./tempest_identity_v3/index.rst - ./tempest_image/index.rst - ./tempest_network/index.rst - ./tempest_volume/index.rst \ No newline at end of file + :maxdepth: 2 + + highavailability/index + security_patrole/index + snaps_smoke/index + stress/index + tempest_compute/index + tempest_identity_v3/index + tempest_image/index + tempest_ipv6/index + tempest_multi_node_scheduling/index + tempest_network_api/index + tempest_network_scenario/index + tempest_network_security/index + tempest_osinterop/index + tempest_trunk_ports/index + tempest_vm_lifecycle/index + tempest_volume/index + vnf/index + vping/index + vpn/index diff --git a/docs/testing/user/testspecification/stress/index.rst b/docs/testing/user/testspecification/stress/index.rst index 41c84e7c..74961fd1 100644 --- a/docs/testing/user/testspecification/stress/index.rst +++ b/docs/testing/user/testspecification/stress/index.rst @@ -18,7 +18,7 @@ the SUT is able to absorb failures while providing an acceptable level of servic References -================ +========== This test area references the following specifications, definitions and reviews: @@ -96,7 +96,7 @@ Basic test flow execution description and pass/fail criteria ------------------------------------------------------------ Methodology for validating capacity of the SUT -''''''''''''''''''''''''''''''''''''''''''''' +'''''''''''''''''''''''''''''''''''''''''''''' Validating capacity of the SUT based on life-cycle ping test generally involves 2 subtests which provides secondary validation for the SUT furnishing users with reliable capacity without being crushed. diff --git a/docs/testing/user/testspecification/tempest_identity_v3/index.rst b/docs/testing/user/testspecification/tempest_identity_v3/index.rst index e5e8f901..bb60b204 100644 --- a/docs/testing/user/testspecification/tempest_identity_v3/index.rst +++ b/docs/testing/user/testspecification/tempest_identity_v3/index.rst @@ -31,7 +31,7 @@ These runtime operations may include that create, list, verify and delete: References ========== -`Identity API v3.0 `_ System Under Test (SUT) ======================= @@ -52,7 +52,7 @@ OVP test suite. - `Create, Get, Update and Delete Credentials `_ - tempest.api.identity.admin.v3.test_credentials.CredentialsTestJSON.test_credentials_create_get_update_delete -- `Create and Verify Domain `_ +- `Create and Verify Domain `_ - tempest.api.identity.admin.v3.test_domains.DefaultDomainTestJSON.test_default_domain_exists - `Create, Update and Delete Domain `_ @@ -80,4 +80,4 @@ OVP test suite. - tempest.api.identity.admin.v3.test_trusts.TrustsV3TestJSON.test_get_trusts_all - `List API Versions `_ - - tempest.api.identity.v3.test_api_discovery.TestApiDiscovery.test_list_api_versions \ No newline at end of file + - tempest.api.identity.v3.test_api_discovery.TestApiDiscovery.test_list_api_versions diff --git a/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst index 79005329..60a5633e 100644 --- a/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst +++ b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst @@ -161,10 +161,12 @@ Test preconditions ------------------ 1. The SUT has at least one external network. -2. In the external network list, there is no network without external router, i.e., -all networks in this list are with external router. + +2. In the external network list, there is no network without external router, + i.e., all networks in this list are with external router. + 3. There is one external network with configured public network id and there is -no subnet on this network + no subnet on this network Basic test flow execution description and pass/fail criteria ------------------------------------------------------------ diff --git a/docs/testing/user/testspecification/tempest_network/network_scenario.rst b/docs/testing/user/testspecification/tempest_network/network_scenario.rst deleted file mode 100644 index 6c172474..00000000 --- a/docs/testing/user/testspecification/tempest_network/network_scenario.rst +++ /dev/null @@ -1,417 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Huawei Technologies Co.,Ltd - -=========================================== -Tempest Network Scenario test specification -=========================================== - -.. toctree:: - :maxdepth: 2 - -Scope -===== - -The Tempest Network scenario test area evaluates the ability of the -system under test to support dynamic network runtime operations through the -life of a VNF (e.g. attach/detach, enable/disable, read stats). -The tests in this test area will evaluate IPv4 network runtime operations -functionality. These runtime operations includes hotpluging network interface, -detaching floating-ip from VM, attaching floating-ip to VM, updating subnet's -DNS, updating VM instance port admin state and updating router admin state. - -References -========== - -- DNS - - - https://docs.openstack.org/newton/networking-guide/config-dns-res.html - -Definitions and abbreviations -============================= - -The following terms and abbreviations are used in conjunction with this test -area - -- API - Application Programming Interface -- DNS - Domain Name System -- ICMP - Internet Control Message Protocol -- MAC - Media Access Control -- NIC - Network Interface Controller -- NFVi - Network Functions Virtualization infrastructure -- SSH - Secure Shell -- TCP - Transmission Control Protocol -- VIM - Virtual Infrastructure Manager -- VM - Virtual Machine - -System Under Test (SUT) -======================= - -The system under test is assumed to be the NFVi and VIM in operation on a -Pharos compliant infrastructure. - -Test Area Structure -=================== - -The test area is structured based on dynamic network runtime operations. Each -test case is able to run independently, i.e. irrelevant of the state created by -a previous test. Specifically, every test performs clean-up operations which -return the system to the same state as before the test. - -All these test cases are included in the test case dovetail.tempest.network_scenario of -OVP test suite. - -Test Descriptions -================= - ----------------------- -API Used and Reference ----------------------- - -Security Groups: https://developer.openstack.org/api-ref/network/v2/index.html#security-groups-security-groups - -- create security group -- delete security group - -Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks - -- create network -- delete network - -Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers - -- create router -- update router -- delete router -- add interface to router - -Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets - -- create subnet -- update subnet -- delete subnet - -Servers: https://developer.openstack.org/api-ref/compute/ - -- create keypair -- create server -- delete server -- add/assign floating IP -- disassociate floating IP - -Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports - -- create port -- update port -- delete port - -Floating IPs: https://developer.openstack.org/api-ref/networking/v2/index.html#floating-ips-floatingips - -- create floating IP -- delete floating IP - --------------------------------------- -Test Case 1 - Basic network operations --------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 via FIP1 successfully -* **Test assertion 2:** Ping the internal gateway from VM1 successfully -* **Test assertion 3:** Ping the default gateway from VM1 using its floating IP - FIP1 successfully -* Test action 6: Detach FIP1 from VM1 -* **Test assertion 4:** VM1 becomes unreachable after FIP1 disassociated -* Test action 7: Create a new server VM2 with NET1, and associate floating IP FIP1 to VM2 -* **Test assertion 5:** Ping FIP1 and SSH to VM2 via FIP1 successfully -* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1, VM2 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of basic network operations. -Specifically, the test verifies that: - -* The Tempest host can ping VM's IP address. This implies, but does not - guarantee (see the ssh check that follows), that the VM has been assigned the - correct IP address and has connectivity to the Tempest host. - -* The Tempest host can perform key-based authentication to an ssh server hosted - at VM's IP address. This check guarantees that the IP address is associated - with the target VM. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the internal gateway address, implying connectivity to another VM on the same network. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the default gateway, implying external connectivity. - -* Detach the floating-ip from the VM and VM becomes unreachable. - -* Associate attached floating ip to a new VM and the new VM is reachable. - -* Floating IP status is updated correctly after each change. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ---------------------------------------- -Test Case 2 - Hotplug network interface ---------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Compute interface_attach feature is enabled -* VM vnic_type is not set to 'direct' or 'macvtap' -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 6: Create a second neutron network NET2 and subnet SUBNET2, and - attach VM1 to NET2 -* Test action 7: Get VM1's ethernet interface NIC2 for NET2 -* **Test assertion 2:** Ping NET2's internal gateway successfully -* Test action 8: Delete SG1, NET1, NET2, SUBNET1, SUBNET2, R1, NIC2, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of adding network to an active VM. -Specifically, the test verifies that: - -* New network interface can be added to an existing VM successfully. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the new network's internal gateway address, implying connectivity to the new network. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - -------------------------------------------- -Test Case 3 - Update subnet's configuration -------------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* DHCP client is available -* Tenant networks should be non-shared and isolated -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface, - configure SUBNET1 with dns nameserver '1.2.3.4' -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 2:** Retrieve the VM1's configured dns and verify it matches - the one configured for SUBNET1 -* Test action 6: Update SUBNET1's dns to '9.8.7.6' -* **Test assertion 3:** After triggering the DHCP renew from the VM manually, - retrieve the VM1's configured dns and verify it has been successfully updated -* Test action 7: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of updating subnet's configurations. -Specifically, the test verifies that: - -* Updating subnet's DNS server configurations are affecting the VMs. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ----------------------------------------- -Test Case 4 - Update VM port admin state ----------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Network port_admin_state_change feature is enabled -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* Test action 6: Create a server VM2 with SG1 and NET1, and assign a floating - IP FIP2 to VM2 -* Test action 7: Get a SSH client SSHCLNT1 to VM2 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 2:** Ping FIP1 via SSHCLNT1 successfully -* Test action 8: Update admin_state_up attribute of VM1 port to False -* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 failed -* **Test assertion 4:** Ping FIP1 via SSHCLNT1 failed -* Test action 9: Update admin_state_up attribute of VM1 port to True -* **Test assertion 5:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 6:** Ping FIP1 via SSHCLNT1 successfully -* Test action 10: Delete SG1, NET1, SUBNET1, R1, SSHCLNT1, VM1, VM2 and FIP1, FIP2 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the VM public and project connectivity status by changing VM port -admin_state_up to True & False. Specifically, the test verifies that: - -* Public and project connectivity is reachable before updating admin_state_up - attribute of VM port to False. - -* Public and project connectivity is unreachable after updating admin_state_up - attribute of VM port to False. - -* Public and project connectivity is reachable after updating admin_state_up - attribute of VM port from False to True. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ---------------------------------------- -Test Case 5 - Update router admin state ---------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_router_admin_state - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Multi-tenant networks capabilities -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 6: Update admin_state_up attribute of R1 to False -* **Test assertion 2:** Ping FIP1 and SSH to VM1 with FIP1 failed -* Test action 7: Update admin_state_up attribute of R1 to True -* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the router public connectivity status by changing -router admin_state_up to True & False. -Specifically, the test verifies that: - -* Public connectivity is reachable before updating admin_state_up attribute of router to False. - -* Public connectivity is unreachable after updating admin_state_up attribute of router to False. - -* Public connectivity is reachable after updating admin_state_up attribute of router. - from False to True - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A diff --git a/docs/testing/user/testspecification/tempest_network_scenario/index.rst b/docs/testing/user/testspecification/tempest_network_scenario/index.rst new file mode 100644 index 00000000..6c172474 --- /dev/null +++ b/docs/testing/user/testspecification/tempest_network_scenario/index.rst @@ -0,0 +1,417 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Huawei Technologies Co.,Ltd + +=========================================== +Tempest Network Scenario test specification +=========================================== + +.. toctree:: + :maxdepth: 2 + +Scope +===== + +The Tempest Network scenario test area evaluates the ability of the +system under test to support dynamic network runtime operations through the +life of a VNF (e.g. attach/detach, enable/disable, read stats). +The tests in this test area will evaluate IPv4 network runtime operations +functionality. These runtime operations includes hotpluging network interface, +detaching floating-ip from VM, attaching floating-ip to VM, updating subnet's +DNS, updating VM instance port admin state and updating router admin state. + +References +========== + +- DNS + + - https://docs.openstack.org/newton/networking-guide/config-dns-res.html + +Definitions and abbreviations +============================= + +The following terms and abbreviations are used in conjunction with this test +area + +- API - Application Programming Interface +- DNS - Domain Name System +- ICMP - Internet Control Message Protocol +- MAC - Media Access Control +- NIC - Network Interface Controller +- NFVi - Network Functions Virtualization infrastructure +- SSH - Secure Shell +- TCP - Transmission Control Protocol +- VIM - Virtual Infrastructure Manager +- VM - Virtual Machine + +System Under Test (SUT) +======================= + +The system under test is assumed to be the NFVi and VIM in operation on a +Pharos compliant infrastructure. + +Test Area Structure +=================== + +The test area is structured based on dynamic network runtime operations. Each +test case is able to run independently, i.e. irrelevant of the state created by +a previous test. Specifically, every test performs clean-up operations which +return the system to the same state as before the test. + +All these test cases are included in the test case dovetail.tempest.network_scenario of +OVP test suite. + +Test Descriptions +================= + +---------------------- +API Used and Reference +---------------------- + +Security Groups: https://developer.openstack.org/api-ref/network/v2/index.html#security-groups-security-groups + +- create security group +- delete security group + +Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks + +- create network +- delete network + +Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers + +- create router +- update router +- delete router +- add interface to router + +Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets + +- create subnet +- update subnet +- delete subnet + +Servers: https://developer.openstack.org/api-ref/compute/ + +- create keypair +- create server +- delete server +- add/assign floating IP +- disassociate floating IP + +Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports + +- create port +- update port +- delete port + +Floating IPs: https://developer.openstack.org/api-ref/networking/v2/index.html#floating-ips-floatingips + +- create floating IP +- delete floating IP + +-------------------------------------- +Test Case 1 - Basic network operations +-------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 via FIP1 successfully +* **Test assertion 2:** Ping the internal gateway from VM1 successfully +* **Test assertion 3:** Ping the default gateway from VM1 using its floating IP + FIP1 successfully +* Test action 6: Detach FIP1 from VM1 +* **Test assertion 4:** VM1 becomes unreachable after FIP1 disassociated +* Test action 7: Create a new server VM2 with NET1, and associate floating IP FIP1 to VM2 +* **Test assertion 5:** Ping FIP1 and SSH to VM2 via FIP1 successfully +* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1, VM2 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of basic network operations. +Specifically, the test verifies that: + +* The Tempest host can ping VM's IP address. This implies, but does not + guarantee (see the ssh check that follows), that the VM has been assigned the + correct IP address and has connectivity to the Tempest host. + +* The Tempest host can perform key-based authentication to an ssh server hosted + at VM's IP address. This check guarantees that the IP address is associated + with the target VM. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the internal gateway address, implying connectivity to another VM on the same network. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the default gateway, implying external connectivity. + +* Detach the floating-ip from the VM and VM becomes unreachable. + +* Associate attached floating ip to a new VM and the new VM is reachable. + +* Floating IP status is updated correctly after each change. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +--------------------------------------- +Test Case 2 - Hotplug network interface +--------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Compute interface_attach feature is enabled +* VM vnic_type is not set to 'direct' or 'macvtap' +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 6: Create a second neutron network NET2 and subnet SUBNET2, and + attach VM1 to NET2 +* Test action 7: Get VM1's ethernet interface NIC2 for NET2 +* **Test assertion 2:** Ping NET2's internal gateway successfully +* Test action 8: Delete SG1, NET1, NET2, SUBNET1, SUBNET2, R1, NIC2, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of adding network to an active VM. +Specifically, the test verifies that: + +* New network interface can be added to an existing VM successfully. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the new network's internal gateway address, implying connectivity to the new network. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +------------------------------------------- +Test Case 3 - Update subnet's configuration +------------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* DHCP client is available +* Tenant networks should be non-shared and isolated +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface, + configure SUBNET1 with dns nameserver '1.2.3.4' +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 2:** Retrieve the VM1's configured dns and verify it matches + the one configured for SUBNET1 +* Test action 6: Update SUBNET1's dns to '9.8.7.6' +* **Test assertion 3:** After triggering the DHCP renew from the VM manually, + retrieve the VM1's configured dns and verify it has been successfully updated +* Test action 7: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of updating subnet's configurations. +Specifically, the test verifies that: + +* Updating subnet's DNS server configurations are affecting the VMs. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +---------------------------------------- +Test Case 4 - Update VM port admin state +---------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Network port_admin_state_change feature is enabled +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* Test action 6: Create a server VM2 with SG1 and NET1, and assign a floating + IP FIP2 to VM2 +* Test action 7: Get a SSH client SSHCLNT1 to VM2 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 2:** Ping FIP1 via SSHCLNT1 successfully +* Test action 8: Update admin_state_up attribute of VM1 port to False +* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 failed +* **Test assertion 4:** Ping FIP1 via SSHCLNT1 failed +* Test action 9: Update admin_state_up attribute of VM1 port to True +* **Test assertion 5:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 6:** Ping FIP1 via SSHCLNT1 successfully +* Test action 10: Delete SG1, NET1, SUBNET1, R1, SSHCLNT1, VM1, VM2 and FIP1, FIP2 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the VM public and project connectivity status by changing VM port +admin_state_up to True & False. Specifically, the test verifies that: + +* Public and project connectivity is reachable before updating admin_state_up + attribute of VM port to False. + +* Public and project connectivity is unreachable after updating admin_state_up + attribute of VM port to False. + +* Public and project connectivity is reachable after updating admin_state_up + attribute of VM port from False to True. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +--------------------------------------- +Test Case 5 - Update router admin state +--------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_router_admin_state + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Multi-tenant networks capabilities +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 6: Update admin_state_up attribute of R1 to False +* **Test assertion 2:** Ping FIP1 and SSH to VM1 with FIP1 failed +* Test action 7: Update admin_state_up attribute of R1 to True +* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the router public connectivity status by changing +router admin_state_up to True & False. +Specifically, the test verifies that: + +* Public connectivity is reachable before updating admin_state_up attribute of router to False. + +* Public connectivity is unreachable after updating admin_state_up attribute of router to False. + +* Public connectivity is reachable after updating admin_state_up attribute of router. + from False to True + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A diff --git a/docs/testing/user/testspecification/tempest_trunk_ports/index.rst b/docs/testing/user/testspecification/tempest_trunk_ports/index.rst index 0507cd9a..fd60a32e 100644 --- a/docs/testing/user/testspecification/tempest_trunk_ports/index.rst +++ b/docs/testing/user/testspecification/tempest_trunk_ports/index.rst @@ -36,7 +36,7 @@ test. For detailed information on the individual steps and assertions performed by the tests, review the Python source code accessible via the following links: - `Neutron Trunk API tests `_ -- `Neutron Trunk API negative tests `_ +- `Neutron Trunk API trunk details `_ - `Neutron Trunk API negative tests `_ @@ -117,7 +117,7 @@ These group of tests comprise negative tests which verify that invalid operation are handled correctly by the system under test. Implementation: -`TrunkTestJSON `_ +`TrunkTestNegative `_ - neutron.tests.tempest.api.test_trunk_negative.TrunkTestJSON.test_add_subport_duplicate_segmentation_details - neutron.tests.tempest.api.test_trunk_negative.TrunkTestJSON.test_add_subport_passing_dict diff --git a/docs/testing/user/userguide/cli_reference.rst b/docs/testing/user/userguide/cli_reference.rst index 891617aa..97eccffc 100644 --- a/docs/testing/user/userguide/cli_reference.rst +++ b/docs/testing/user/userguide/cli_reference.rst @@ -72,7 +72,7 @@ Commands List | dovetail run --optional --testsuite | Run Dovetail with all optional test cases within test suite | | | | +------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------+ -| dovetail run --debug | -d | Run Dovetail with debug mode and show all debug logs | +| dovetail run --debug | -d | Run Dovetail with debug mode and show all debug logs | | | | +------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------+ | dovetail run --offline | Run Dovetail offline, use local docker images instead of download online | -- cgit 1.2.3-korg