Fix all docker version and update all other docs 56/69456/1
authorxudan <xudan16@huawei.com>
Fri, 27 Dec 2019 09:25:43 +0000 (04:25 -0500)
committerxudan <xudan16@huawei.com>
Fri, 27 Dec 2019 09:25:43 +0000 (04:25 -0500)
JIRA: DOVETAIL-798

Change-Id: Ie10525d4534e7bf3bb263b9ad8cf200259a7bf7c
Signed-off-by: xudan <xudan16@huawei.com>
docs/release/release-notes/index.rst
docs/testing/user/certificationworkflow/ApplicationForm.rst
docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst
docs/testing/user/ovpaddendum/index.rst
docs/testing/user/userguide/testing_guide.rst
etc/conf/bottlenecks_config.yml
etc/conf/yardstick_config.yml

index 46a69a1..78f49fa 100644 (file)
@@ -179,7 +179,7 @@ Software
 +-------------------------+-----------------------------------+----------------+
 |   yardstick             |    opnfv/yardstick                |   opnfv-8.0.0  |
 +-------------------------+-----------------------------------+----------------+
-|   bottlenecks           |    opnfv/bottlenecks              |   <Need_Input> |
+|   bottlenecks           |    opnfv/bottlenecks              |   8.0.1-latest |
 +-------------------------+-----------------------------------+----------------+
 
 
index aac9a46..1aa937b 100644 (file)
@@ -2,9 +2,9 @@
 .. http://creativecommons.org/licenses/by/4.0
 .. (c) OPNFV, Intel Corporation and others.
 
-=======================================
-OPNFV Verified Program Application Form
-=======================================
+===========================================
+OPNFV Verification Program Application Form
+===========================================
 
 
 +----------------------------------+--------------------------------------------------------------------------------------------+
index 7e9cdaa..27173ed 100644 (file)
@@ -30,7 +30,7 @@ Consequently, such cloud implementations do not pass Tempest tests which
 validate API responses despite actually implementing and providing the tested
 functionality.
 
-This document describes an exemption process for use within the OPNFV Verified
+This document describes an exemption process for use within the OPNFV Verification
 Program which
 
 i) allows vendors to pass Tempest tests if the tested functionality is
@@ -63,7 +63,7 @@ is actually available. As a result, a Tempest test failing due to extended API
 responses does not provide information about whether the tested functionality
 is available or not.
 
-The OPNFV Verified Program has inherited the policy to strictly validate API
+The OPNFV Verification Program has inherited the policy to strictly validate API
 responses from OpenStack by including a selection of Tempest tests in its
 compliance test suite. However, it was never discussed if OVP should adopt this
 policy as well. It turns out that this policy causes challenges for vendors of
@@ -168,7 +168,7 @@ responses is as follows:
    not.
 
 #. The exemption will be made available to participants of OVP as part of a
-   service release of OVP 2018.01 and 2018.09.
+   service release of OVP 2018.01, 2018.09 and 2019.12.
 
 #. The C&C committee will monitor the situation around exemptions and may
    decide changes to the above process at any time, including the possibility
index 7072d3f..556b1b4 100644 (file)
@@ -4,7 +4,7 @@
 .. (c) Intel and others
 
 =======================================
-Guidelines Addendum for 2018.09 release
+Guidelines Addendum for 2019.12 release
 =======================================
 
 .. toctree::
@@ -15,10 +15,10 @@ Introduction
 ============
 
 This addendum provides a high-level description of the testing scope and
-pass/fail criteria used in the OPNFV Verified Program (OVP) for the 2018.09
+pass/fail criteria used in the OPNFV Verification Program (OVP) for the 2019.12
 release. This information is intended as an overview for OVP testers and for
 the Dovetail Project to help guide test-tool and test-case development for the
-OVP 2018.09 release. The Dovetail project is responsible for documenting
+OVP 2019.12 release. The Dovetail project is responsible for documenting
 test-case specifications as well as implementing the OVP tool-chain through
 collaboration with the OPNFV testing community. OVP testing focuses on
 establishing the ability of the System Under Test (SUT) to perform NFVI and VIM
@@ -31,7 +31,7 @@ Meaning of Compliance
 
 OPNFV Compliance indicates adherence of an NFV platform to behaviors defined
 through specific platform capabilities, allowing to prepare, instantiate,
-operate and remove VNFs running on the NFVI. OVP 2018.09 compliance evaluates
+operate and remove VNFs running on the NFVI. OVP 2019.12 compliance evaluates
 the ability of a platform to support Service Provider network capabilities and
 workloads that are supported in the OPNFV platform as of this release.
 Compliance test cases are designated as compulsory or optional based on the
@@ -137,7 +137,7 @@ test scope.
 Analysis of Scope
 -----------------
 
-In order to define the scope of the 2018.09 release of the compliance and
+In order to define the scope of the 2019.12 release of the compliance and
 verification program, this section analyzes NFV-focused platform capabilities
 with respect to the high-level objectives and the general approach outlined in
 the previous section. The analysis determines which capabilities are suitable
@@ -169,7 +169,7 @@ including:
   suspend/resume, reboot, migrate)
 - simple virtual machine resource scheduling on multiple nodes
 
-OPNFV mainly supports OpenStack as the VIM up to the 2018.09 release. The VNFs
+OPNFV mainly supports OpenStack as the VIM up to the 2019.12 release. The VNFs
 used in the OVP program, and features in scope for the program which are
 considered to be basic to all VNFs, require commercial OpenStack distributions
 to support a common basic level of cloud capabilities, and to be compliant to a
@@ -198,7 +198,7 @@ feature requirements expand beyond common OpenStack (or other VIM)
 requirements. OPNFV OVP will incorporate test cases to verify compliance in
 these areas as they become mature. Because these extensions may impose new API
 demands, maturity and industry adoption is a prerequisite for making them a
-mandatory requirement for OPNFV compliance. At the time of the 2018.09 release,
+mandatory requirement for OPNFV compliance. At the time of the 2019.12 release,
 we have promoted tests of the OpenStack IPv6 API from optional to mandatory
 while keeping BGPVPN as optional test area. Passing optional tests will not be
 required to pass OPNFV compliance verification.
@@ -207,7 +207,7 @@ BGPVPNs are relevant due to the wide adoption of MPLS/BGP based VPNs in wide
 area networks, which makes it necessary for data centers hosting VNFs to be
 able to seamlessly interconnect with such networks. SFC is also an important
 NFV requirement, however its implementation has not yet been accepted or
-adopted in the upstream at the time of the 2018.09 release.
+adopted in the upstream at the time of the 2019.12 release.
 
 3. High availability
 
@@ -233,7 +233,7 @@ Resiliency testing involves stressing the SUT and verifying its ability to
 absorb stress conditions and still provide an acceptable level of service.
 Resiliency is an important requirement for end-users.
 
-The 2018.09 release of OVP includes a load test which spins up a number of VMs
+The 2019.12 release of OVP includes a load test which spins up a number of VMs
 pairs in parallel to assert that the system under test can process the workload
 spike in a stable and deterministic fashion.
 
@@ -248,12 +248,12 @@ capabilities expected of an end-user deployment. It is an area that we should
 address in the near future, to define a common set of requirements and develop
 test cases for verifying those requirements.
 
-The 2018.09 release includes new test cases which verify that the role-based
+The 2019.12 release includes new test cases which verify that the role-based
 access control (RBAC) functionality of the VIM is behaving as expected.
 
 Another common requirement is security vulnerability scanning. While the OPNFV
 security project integrated tools for security vulnerability scanning, this has
-not been fully analyzed or exercised in 2018.09 release. This area needs
+not been fully analyzed or exercised in 2019.12 release. This area needs
 further work to identify the required level of security for the purpose of
 OPNFV in order to be integrated into the OVP. End-user inputs on specific
 requirements in security is needed.
@@ -266,7 +266,7 @@ essential information and control mechanisms. These subsystems include
 telemetry, fault management (e.g. alarms), performance management, audits, and
 control mechanisms such as security and configuration policies.
 
-The current 2018.09 release implements some enabling capabilities in NFVI/VIM
+The current 2019.12 release implements some enabling capabilities in NFVI/VIM
 such as telemetry, policy, and fault management. However, the specification of
 expected system components, behavior and the test cases to verify them have not
 yet been adequately developed. We will therefore not be testing this area at
@@ -285,7 +285,7 @@ compliance because it validates design patterns and support for the types of
 NFVI features that users care about.
 
 There are a lot of projects in OPNFV developing use cases and sample VNFs. The
-2018.09 release of OVP features two such use-case tests, spawning and verifying
+2019.12 release of OVP features two such use-case tests, spawning and verifying
 a vIMS and a vEPC, correspondingly.
 
 8. Additional capabilities
@@ -307,10 +307,10 @@ OVP.
 
 
 
-Scope of the 2018.09 release of the OVP
+Scope of the 2019.12 release of the OVP
 ---------------------------------------
 
-Summarizing the results of the analysis above, the scope of the 2018.09 release
+Summarizing the results of the analysis above, the scope of the 2019.12 release
 of OVP is as follows:
 
 - Mandatory test scope:
@@ -369,7 +369,7 @@ Scope considerations for future OVP releases
 --------------------------------------------
 
 Based on the previous analysis, the following items are outside the scope of
-the 2018.09 release of OVP but are being considered for inclusion in future
+the 2019.12 release of OVP but are being considered for inclusion in future
 releases:
 
 - service assurance
index 2044698..f8b8971 100644 (file)
@@ -504,8 +504,8 @@ The Docker images, Ubuntu and Cirros image below are necessary for all mandatory
    $ sudo docker pull opnfv/dovetail:ovp-3.0.0
    $ sudo docker pull opnfv/functest-smoke:hunter
    $ sudo docker pull opnfv/functest-healthcheck:hunter
-   $ sudo docker pull opnfv/yardstick:<need input>
-   $ sudo docker pull opnfv/bottlenecks:<need input>
+   $ sudo docker pull opnfv/yardstick:opnfv-8.0.0
+   $ sudo docker pull opnfv/bottlenecks:8.0.1-latest
    $ wget -nc http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img -P {ANY_DIR}
    $ wget -nc https://cloud-images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-amd64-disk1.img -P ${DOVETAIL_HOME}/images
 
@@ -527,7 +527,7 @@ At the online host, save the images with the command below.
    $ sudo docker save -o dovetail.tar opnfv/dovetail:ovp-3.0.0 \
      opnfv/functest-smoke:hunter opnfv/functest-healthcheck:hunter \
      opnfv/functest-vnf:hunter \
-     opnfv/yardstick:<need input> opnfv/bottlenecks:<need input>
+     opnfv/yardstick:opnfv-8.0.0 opnfv/bottlenecks:8.0.1-latest
 
 The command above creates a dovetail.tar file with all the images, which can then be copied
 to the Test Host. To load the Dovetail images on the Test Host execute the command below.
@@ -541,13 +541,13 @@ Now check to see that all Docker images have been pulled or loaded properly.
 .. code-block:: bash
 
    $ sudo docker images
-   REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
-   opnfv/dovetail                  ovp-3.0.0           ac3b2d12b1b0        24 hours ago        784 MB
-   opnfv/functest-smoke            hunter              010aacb7c1ee        17 hours ago        594.2 MB
-   opnfv/functest-healthcheck      hunter              2cfd4523f797        17 hours ago        234 MB
-   opnfv/functest-vnf              hunter              929e847a22c3        17 hours ago        1.87 GB
-   opnfv/yardstick                 <need input>        84b4edebfc44        17 hours ago        2.052 GB
-   opnfv/bottlenecks               <need input>        3d4ed98a6c9a        21 hours ago        638 MB
+   REPOSITORY                    TAG                 IMAGE ID            CREATED             SIZE
+   opnfv/dovetail                ovp-3.0.0           4b68659da24d        22 hours ago        825MB
+   opnfv/functest-smoke          hunter              c0253f6de153        3 weeks ago         556MB
+   opnfv/functest-healthcheck    hunter              fb6d766e38e0        3 weeks ago         379MB
+   opnfv/functest-vnf            hunter              31466d52d155        21 hours ago        1.1GB
+   opnfv/yardstick               opnfv-8.0.0         189d7d9fbcb2        7 months ago        2.54GB
+   opnfv/bottlenecks             8.0.1-latest        44c1b9fb25aa        5 hours ago         837MB
 
 After copying and loading the Dovetail images at the Test Host, also copy the test images
 (Ubuntu, Cirros and cloudify-manager) to the Test Host.
index d36f9bb..c23ad9c 100644 (file)
@@ -27,7 +27,7 @@
 
 bottlenecks:
   image_name: opnfv/bottlenecks
-  docker_tag: latest
+  docker_tag: 8.0.1-latest
   opts:
     detach: true
     stdin_open: true
@@ -35,7 +35,7 @@ bottlenecks:
   shell: '/bin/bash'
   envs:
     - 'DEPLOY_SCENARIO={{deploy_scenario}}'
-    - 'Yardstick_TAG=stable'
+    - 'Yardstick_TAG=opnfv-8.0.0'
     - 'OUTPUT_FILE={{testcase}}.out'
     - 'CI_DEBUG={{debug}}'
     - 'BUILD_TAG={{build_tag}}-{{testcase}}'
index 21716f8..3c4273f 100644 (file)
@@ -31,7 +31,7 @@
 
 yardstick:
   image_name: opnfv/yardstick
-  docker_tag: latest
+  docker_tag: opnfv-8.0.0
   opts:
     detach: true
     stdin_open: true