diff options
Diffstat (limited to 'docs/testing/developer')
| -rw-r--r-- | docs/testing/developer/devguide/index.rst | 315 | ||||
| -rw-r--r-- | docs/testing/developer/internship/security_group/index.rst | 70 | ||||
| -rw-r--r-- | docs/testing/developer/internship/testapi_evolution/index.rst | 237 | ||||
| -rw-r--r-- | docs/testing/developer/internship/unit_tests/index.rst | 126 | ||||
| -rw-r--r-- | docs/testing/developer/internship/vnf_catalog/index.rst | 170 |
5 files changed, 0 insertions, 918 deletions
diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst deleted file mode 100644 index 19a1bdcb..00000000 --- a/docs/testing/developer/devguide/index.rst +++ /dev/null @@ -1,315 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 - -************************ -Functest Developer Guide -************************ - -.. toctree:: - :numbered: - :maxdepth: 2 - -============ -Introduction -============ - -Functest is a project dealing with functional testing. -The project produces its own internal test cases but can also be considered -as a framework to support feature and VNF onboarding project testing. - -Therefore there are many ways to contribute to Functest. You can: - - * Develop new internal test cases - * Integrate the tests from your feature project - * Develop the framework to ease the integration of external test cases - -Additional tasks involving Functest but addressing all the test projects -may also be mentioned: - - * The API / Test collection framework - * The dashboards - * The automatic reporting portals - * The testcase catalog - -This document describes how, as a developer, you may interact with the -Functest project. The first section details the main working areas of -the project. The Second part is a list of "How to" to help you to join -the Functest family whatever your field of interest is. - - -======================== -Functest developer areas -======================== - - -Functest High level architecture -================================ - -Functest is a project delivering test containers dedicated to OPNFV. -It includes the tools, the scripts and the test scenarios. -In Euphrates Alpine containers have been introduced in order to lighten the -container and manage testing slicing. The new containers are created according -to the different tiers: - - * functest-core: https://hub.docker.com/r/opnfv/functest-core/ - * functest-healthcheck: https://hub.docker.com/r/opnfv/functest-healthcheck/ - * functest-smoke: https://hub.docker.com/r/opnfv/functest-smoke/ - * functest-features: https://hub.docker.com/r/opnfv/functest-features/ - * functest-components: https://hub.docker.com/r/opnfv/functest-components/ - * functest-vnf: https://hub.docker.com/r/opnfv/functest-vnf/ - * functest-parser: https://hub.docker.com/r/opnfv/functest-parser/ - * functest-restapi: https://hub.docker.com/r/opnfv/functest-restapi/ - -Standalone functest dockers are maintained for Euphrates but Alpine containers -are recommended. - -Functest can be described as follow:: - - +----------------------+ - | | - | +--------------+ | +-------------------+ - | | | | Public | | - | | Tools | +------------------+ OPNFV | - | | Scripts | | | System Under Test | - | | Scenarios | | | | - | | | | | | - | +--------------+ | +-------------------+ - | | - | Functest Docker | - | | - +----------------------+ - -Functest internal test cases -============================ -The internal test cases in Euphrates are: - - - * api_check - * connection_check - * snaps_health_check - * vping_ssh - * vping_userdata - * odl - * odl_netvirt - * rally_full - * rally_sanity - * tempest_smoke_serial - * tempest_full_parallel - * cloudify_ims - -By internal, we mean that this particular test cases have been developed and/or -integrated by functest contributors and the associated code is hosted in the -Functest repository. -An internal case can be fully developed or a simple integration of -upstream suites (e.g. Tempest/Rally developed in OpenStack, or odl suites are -just integrated in Functest). - -The structure of this repository is detailed in `[1]`_. -The main internal test cases are in the opnfv_tests subfolder of the -repository, the internal test cases can be grouped by domain: - - * sdn: odl, odl_netvirt, odl_fds - * openstack: api_check, connection_check, snaps_health_check, vping_ssh, vping_userdata, tempest_*, rally_* - * vnf: cloudify_ims - -If you want to create a new test case you will have to create a new folder under -the testcases directory (See next section for details). - -Functest external test cases -============================ -The external test cases are inherited from other OPNFV projects, especially the -feature projects. - -The external test cases are: - - * barometer - * bgpvpn - * doctor - * domino - * fds - * parser - * promise - * refstack_defcore - * snaps_smoke - * functest-odl-sfc - * orchestra_clearwaterims - * orchestra_openims - * vyos_vrouter - * juju_vepc - -External test cases integrated in previous versions but not released in -Euphrates: - - * copper - * moon - * netready - * security_scan - - -The code to run these test cases is hosted in the repository of the project. -Please note that orchestra test cases are hosted in Functest repository and not -in orchestra repository. Vyos_vrouter and juju_vepc code is also hosted in -functest as there are no dedicated projects. - - -Functest framework -================== - -Functest is a framework. - -Historically Functest is released as a docker file, including tools, scripts and -a CLI to prepare the environment and run tests. -It simplifies the integration of external test suites in CI pipeline and provide -commodity tools to collect and display results. - -Since Colorado, test categories also known as **tiers** have been created to -group similar tests, provide consistent sub-lists and at the end optimize -test duration for CI (see How To section). - -The definition of the tiers has been agreed by the testing working group. - -The tiers are: - * healthcheck - * smoke - * features - * components - * vnf - -Functest abstraction classes -============================ - -In order to harmonize test integration, abstraction classes have been -introduced: - - * testcase: base for any test case - * unit: run unit tests as test case - * feature: abstraction for feature project - * vnf: abstraction for vnf onboarding - -The goal is to unify the way to run tests in Functest. - -Feature, unit and vnf_base inherit from testcase:: - - +----------------------------------------------------------------+ - | | - | TestCase | - | | - | - init() | - | - run() | - | - push_to_db() | - | - is_successful() | - | | - +----------------------------------------------------------------+ - | | | | - V V V V - +--------------------+ +---------+ +------------------------+ +-----------------+ - | | | | | | | | - | feature | | unit | | vnf | | robotframework | - | | | | | | | | - | | | | |- prepare() | | | - | - execute() | | | |- deploy_orchestrator() | | | - | BashFeature class | | | |- deploy_vnf() | | | - | | | | |- test_vnf() | | | - | | | | |- clean() | | | - +--------------------+ +---------+ +------------------------+ +-----------------+ - - -Testcase --------- -.. raw:: html - :url: http://artifacts.opnfv.org/functest/docs/apidoc/functest.core.testcase.html - -Feature -------- -.. raw:: html - :url: http://artifacts.opnfv.org/functest/docs/apidoc/functest.core.feature.html - -Unit ----- -.. raw:: html - :url: http://artifacts.opnfv.org/functest/docs/apidoc/functest.core.unit.html - -VNF ---- -.. raw:: html - :url: http://artifacts.opnfv.org/functest/docs/apidoc/functest.core.vnf.html - -Robotframework --------------- -.. raw:: html - :url: http://artifacts.opnfv.org/functest/docs/apidoc/functest.core.robotframework.html - - -see `[5]`_ to get code samples - - -Functest util classes -===================== - -In order to simplify the creation of test cases, Functest develops also some -functions that are used by internal test cases. -Several features are supported such as logger, configuration management and -Openstack capabilities (tacker,..). -These functions can be found under <repo>/functest/utils and can be described as -follows:: - - functest/utils/ - |-- config.py - |-- constants.py - |-- decorators.py - |-- env.py - |-- functest_utils.py - |-- openstack_tacker.py - `-- openstack_utils.py - -It is recommended to use the SNAPS-OO library for deploying OpenStack instances. -SNAPS `[4]`_ is an OPNFV project providing OpenStack utils. - - -TestAPI -======= -Functest is using the Test collection framework and the TestAPI developed by -the OPNFV community. See `[6]`_ for details. - - -Reporting -========= -A web page is automatically generated every day to display the status based on -jinja2 templates `[3]`_. - - -Dashboard -========= - -Additional dashboarding is managed at the testing group level, see `[7]`_ for -details. - - -======= -How TOs -======= - -See How to section on Functest wiki `[8]`_ - - -========== -References -========== - -_`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/index.html Functest configuration guide - -_`[2]`: http://artifacts.opnfv.org/functest/docs/userguide/index.html functest user guide - -_`[3]`: https://git.opnfv.org/cgit/releng/tree/utils/test/reporting - -_`[4]`: https://git.opnfv.org/snaps/ - -_`[5]` : http://testresults.opnfv.org/functest/framework/index.html - -_`[6]`: http://docs.opnfv.org/en/latest/testing/testing-dev.html - -_`[7]`: https://opnfv.biterg.io/goto/283dba93ca18e95964f852c63af1d1ba - -_`[8]`: https://wiki.opnfv.org/pages/viewpage.action?pageId=7768932 - -IRC support chan: #opnfv-functest diff --git a/docs/testing/developer/internship/security_group/index.rst b/docs/testing/developer/internship/security_group/index.rst deleted file mode 100644 index d1cdbdd8..00000000 --- a/docs/testing/developer/internship/security_group/index.rst +++ /dev/null @@ -1,70 +0,0 @@ -======= -License -======= - -Functest 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/>. - -================================== -Functest Security group test cases -================================== - -Author: Girish Sukhatankar -mentors: D.Blaisonneau, J.Lausuch, M.Richomme - -Abstract -======== - - -Version history -=============== - -+------------+----------+------------------+------------------------+ -| **Date** | **Ver.** | **Author** | **Comment** | -| | | | | -+------------+----------+------------------+------------------------+ -| 2016-??-?? | 0.0.1 | Morgan Richomme | Beginning of the | -| | | (Orange) | Internship | -+------------+----------+------------------+------------------------+ - - -Overview: -========= - - - - -Problem Statement: ------------------- - - - -Curation Phase --------------- - - - - - -Schedule: -========= - - - -+--------------------------+------------------------------------------+ -| **Date** | **Comment** | -| | | -+--------------------------+------------------------------------------+ -| December - January | ........ | -+--------------------------+------------------------------------------+ -| January - february | ........ | -+--------------------------+------------------------------------------+ - - -References: -=========== - -.. _`[1]` : https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Security+groups+test+case+in+Functest - diff --git a/docs/testing/developer/internship/testapi_evolution/index.rst b/docs/testing/developer/internship/testapi_evolution/index.rst deleted file mode 100644 index 3038d0ac..00000000 --- a/docs/testing/developer/internship/testapi_evolution/index.rst +++ /dev/null @@ -1,237 +0,0 @@ -======= -License -======= - -Functest 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/>. - -================= -TestAPI evolution -================= - -Author: Sakala Venkata Krishna Rohit -Mentors: S. Feng, J.Lausuch, M.Richomme - -Abstract -======== - -The TestAPI is used by all the test opnfv projects to report results. -It is also used to declare projects, test cases and labs. A major refactoring -has been done in Colorado with the introduction of swagger. The TestAPI is defined in Functest -developer guide. The purpose of this project is to add more features to the TestAPI that automate -the tasks that are done manually now, though there are tasks other than automation. - -Version history -=============== - -+------------+----------+------------------+------------------------+ -| **Date** | **Ver.** | **Author** | **Comment** | -| | | | | -+------------+----------+------------------+------------------------+ -| 2016-11-14 | 0.0.1 | Morgan Richomme | Beginning of the | -| | | (Orange) | Internship | -+------------+----------+------------------+------------------------+ -| 2017-02-17 | 0.0.2 | S.V.K Rohit | End of the Internship | -| | | (IIIT Hyderabad) | | -+------------+----------+------------------+------------------------+ - -Overview: -========= - -The internhip time period was from Nov 14th to Feb 17th. The project prosposal page is here `[1]`_. -The intern project was assigned to Svk Rohit and was mentored by S. Feng, J.Lausuch, M.Richomme. -The link to the patches submitted is `[2]`_. The internship was successfully completed and the -documentation is as follows. - -Problem Statement: ------------------- - -The problem statement could be divided into pending features that needed to be added into TestAPI -repo. The following were to be accomplished within the internship time frame. - -* **Add verification jenkins job for the TestAPI code** - The purpose of this job is to verify whehter the unit tests are successful or not with the - inclusion of the patchset submitted. - -* **Automatic update of opnfv/testapi docker image** - The docker image of TestAPI is hosted in the opnfv docker hub. To ensure that the TestAPI image - is always updated with the repository, automatic updation of the image is necessary and a job - is triggered whenever a new patch gets merged. - -* **Automation deployment of testresults.opnfv.org/test/ website** - In the same manner as the docker image of TestAPI is updated, the TestAPI website needs to be - in sync with the repository code. So, a job has been added to the opnfv jenkins ci for the - updation of the testresults website. - -* **Generate static documentation of TestAPI calls** - The purpose of this is to give an static/offline view of TestAPI. If someone wants to have a - look at the Restful APIs of TestAPI, he/she does't need to go to the website, he can download - a html page and view it anytime. - -* **Backup MongoDB of TestAPI** - The mongoDB needs to be backed up every week. Till now it was done manually, but due to this - internship, it is now automated using a jenkins job. - -* **Add token based authorization to the TestAPI calls** - The token based authorization was implemented to ensure that only ci_pods could access the - database. Authentication has been added to only delete/put/post requests. - -Curation Phase: ---------------- - -The curation phase was the first 3 to 4 weeks of the internship. This phase was to get familiar -with the TestAPI code and functionality and propose the solutions/tools for the tasks mentioned -above. Swagger codegen was choosen out of the four tools proposed `[3]`_ for generating static -documentaion. - -Also, specific amount of time was spent on the script flow of the jenkins jobs. The automatic -deployment task involves accessing a remote server from inside the jenkins build. The deployment -had to be done only after the docker image update is done. For these constraints to satisfy, a -multijob jenkins job was choosen instead of a freestyle job. - -Important Links: ----------------- - -* MongoDB Backup Link - `[4]`_ -* Static Documentation - `[5]`_ -* TestAPI Token addition to ci_pods - `[6]`_ - -Schedule: -========= - -The progress and completion of the tasks is described in the below table. - -+--------------------------+------------------------------------------+ -| **Date** | **Comment** | -| | | -+--------------------------+------------------------------------------+ -| Nov 14th - Dec 31st | Understand TestAPI code and the | -| | requirements. | -+--------------------------+------------------------------------------+ -| Jan 1st - Jan 7th | Add jenkins job to create static | -| | documentation and write build scripts. | -+--------------------------+------------------------------------------+ -| Jan 8th - Jan 21st | Add verification jenkins job for unit | -| | tests. | -+--------------------------+------------------------------------------+ -| Jan 22nd - Jan 28th | Add jenkins job for mongodb backup | -| | | -+--------------------------+------------------------------------------+ -| Jan 29th - Feb 11th | Enable automatic deployment of | -| | testresults.opnfv.org/test/ | -+--------------------------+------------------------------------------+ -| Feb 12th - Feb 17th | Add token based authentication | -| | | -+--------------------------+------------------------------------------+ - -FAQ's -===== - -This section lists the problems that I have faced and the understanding that I have acquired during -the internship. This section may help other developers in solving any errors casused because of the -code written as a part of this internship. - - -TestAPI -------- - -What is the difference between defining data_file as "/etc/.." and "etc/.." in setup.cfg ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If in the setup.cfg, it is defined as - -[files] -data_files = -etc/a.conf = etc/a.conf.sample - -then it ends up installed in the /usr/etc/. With this configuration, it would be installed -correctly within a venv. but when it is defined as - -[files] -data_files = -/etc/a.conf = etc/a.conf.sample - -then it ends up installed on the root of the filesystem instead of properly be installed within the -venv. - -Which attribute does swagger-codegen uses as the title in the generation of document generation ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It uses the nickname of the api call in swagger as the title in the generation of the document -generation. - -Does swagger-codegen take more than one yaml file as input ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -No, swagger-codegen only takes one yaml file as input to its jar file. If there more than one yaml -file, one needs to merge them and give it as an input keeping mind the swagger specs. - - -Jenkins & JJB -------------- - -Which scm macro is used for verification jenkins jobs ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are two macros for scm one is git-scm and other git-scm-gerrit. git-scm-gerrit is used for -verification jenkins job. - -Does the virtualenv created in one build script exists in other build scripts too ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -No, the virtualenv created in one build script only exists in that build script/shell. - -What parameters are needed for the scm macros ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Project and Branch are the two parameters needed for scm macros. - -What is the directory inside the jenkins build ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The directory of the jenkins build is the directory of the repo. `ls $WORKSPACE` command will give -you all the contents of the directory. - -How to include a bash script in jenkins job yaml file ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -An example might be apt here as an answer. - -builders: - - shell: - !include-raw: include-raw001-hello-world.sh - - -How do you make a build server run on a specific machine ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It can be done by defining a label parameter 'SLAVE_LABEL' or in OPNFV , there are macros for each -server, one can use those parameter macros. -Ex: opnfv-build-defaults. Note, if we use macro, then no need to define GIT_BASE, but if one uses -SLAVE_LABEL, one needs to define a parameter GIT_BASE. This is because macro already has GIT_BASE -defined. - -What job style should be used when there is a situation like one build should trigger other builds -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -or when different build scripts need to be run on different machines ? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -MultiJob style should be used as it has phases where each phase can be taken as a build scipt and -can have its own parameters by which one can define the SLAVE_LABEL parameter. - -References: -=========== - -_`[1]` : https://wiki.opnfv.org/display/DEV/Intern+Project%3A+testapi+evolution - -_`[2]` : https://gerrit.opnfv.org/gerrit/#/q/status:merged+owner:%22Rohit+Sakala+%253Crohitsakala%2540gmail.com%253E%22 - -_`[3]` : https://docs.google.com/document/d/1jWwVZ1ZpKgKcOS_zSz2KzX1nwg4BXxzBxcwkesl7krw/edit?usp=sharing - -_`[4]` : http://artifacts.opnfv.org/testapibackup.html - -_`[5]` : http://artifacts.opnfv.org/releng/docs/testapi.html - -_`[6]` : http://artifacts.opnfv.org/functest/docs/devguide/index.html#test-api-authorization diff --git a/docs/testing/developer/internship/unit_tests/index.rst b/docs/testing/developer/internship/unit_tests/index.rst deleted file mode 100644 index a117c860..00000000 --- a/docs/testing/developer/internship/unit_tests/index.rst +++ /dev/null @@ -1,126 +0,0 @@ -======= -License -======= - -Functest 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/>. - -=================== -Functest Unit tests -=================== - -Author: Ashish Kumar -Mentors: H.Yao, J.Lausuch, M.Richomme - -Abstract -======== - - -Version history -=============== - -+------------+----------+------------------+------------------------+ -| **Date** | **Ver.** | **Author** | **Comment** | -| | | | | -+------------+----------+------------------+------------------------+ -| 2016-11-14 | 0.0.1 | Morgan Richomme | Beginning of the | -| | | (Orange) | Internship | -+------------+----------+------------------+------------------------+ -| 2017-03-31 | 0.0.2 | Ashish Kumar | During the | -| | | (IIIT Hyderabad) | Internship | -+------------+----------+------------------+------------------------+ - - -Overview: -========= -Functest project is developing and integrating functional test cases for OPNFV -and it is part of OPNFV since the beginning. Functest develops its own testcases -and framework. This framework includes several utility libraries. The Project is -growing rapidly with more features, tests added as per requirement. It becomes -the responsibility of every developer to maintain the integrity of code i.e. new -patch should not break the previous functionality of the project. To automate this -process of software development, we should write unit tests and add them to CI so -that when a new patch is ready to merge, we shouldn't allow those which are breaking -previous unit tests or decreasing the coverage. - - - -Problem Statement: ------------------- -The goal of the intership consists in creating unit test suites on Functest code -with good code coverage (>80%) and integrate it in continuous integration in order -to consolidate existing code. - - -Curation Phase --------------- -The curation phase was the first 3 to 4 weeks of the internship. This phase was to get -familiar with the functest code and functionality and explore the solutions for unit -testing in other projects and come up with the strategy for writing unit tests in functest. - -In this phase we decided, -- Coverage should be 80%. There are some functions like __init__, getter, setter and other - private methods for which writing unit test is a tedious job, so we are leaving these methods - for now. -- Do method wise testing for every module. -- Use mock for external or third party services, system calls and other external library calls - which could impact the behaviour of system during the run of unit test. -- Add it in jenkins as passing criteria for patches. -- Write tests in modular way so that it can help to serve as a form of documentation. - - - -Schedule: -========= -+--------------------------+------------------------------------------+ -| **Date** | **Comment** | -| | | -+--------------------------+------------------------------------------+ -| Nov 14th - Nov 28th | 1. Learn Functest Project Business | -| | 2. Set up the development environment | -| | 3. Run Functest code | -+--------------------------+------------------------------------------+ -| Nov 28th - Dec.9th | 1. Explore Unit Testing Strategy, | -| | 2. Learn about Mock in python | -+--------------------------+------------------------------------------+ -| Dec 12th - Dec 23rd | Implement Unit Tests for CLI | -| | | -+--------------------------+------------------------------------------+ -| Dec 26th - Jan 6th | Implement Unit Tests for Utils | -| | | -+--------------------------+------------------------------------------+ -| Jan 9th - Jan 20th | Implement Unit Tests for CI | -| | | -+--------------------------+------------------------------------------+ -| Jan 23rd - Feb 3rd | Implement Unit Tests for Core | -| | | -+--------------------------+------------------------------------------+ -| Feb 6th - Feb 17th | Implement Unit Tests for | -| | opnfv_tests/openstack/tempest | -+--------------------------+------------------------------------------+ -| Feb 20th - Mar 3rd | Implement Unit Tests for | -| | opnfv_tests/openstack/rally | -+--------------------------+------------------------------------------+ -| Mar 6th - Mar 17th | Implement Unit Tests for | -| | opnfv_tests/vnf/ims | -+--------------------------+------------------------------------------+ -| Mar 20th - Mar 31st | Recheck and Increase Coverage for all | -| | modules > 80% | -+--------------------------+------------------------------------------+ -| Apr 3rd - Apr 14th | Add CI Gating for unit tests | -| | | -+--------------------------+------------------------------------------+ -| Apr 17th - Apr 28th | Use Tox Utility, Documentation | -| | | -+--------------------------+------------------------------------------+ -| Apr 28th - End | Bug Fixing | -| | | -+--------------------------+------------------------------------------+ - - -References: -=========== - -.. _`[1]` : https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Functest+unit+tests diff --git a/docs/testing/developer/internship/vnf_catalog/index.rst b/docs/testing/developer/internship/vnf_catalog/index.rst deleted file mode 100644 index df763339..00000000 --- a/docs/testing/developer/internship/vnf_catalog/index.rst +++ /dev/null @@ -1,170 +0,0 @@ -======= -License -======= - -Functest 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/>. - -======================= -Open Source VNF Catalog -======================= - -Author: Kumar Rishabh -Mentors: B.Souville, M.Richomme, J.Lausuch - -Abstract -======== - - - -Version hissory -=============== - -+------------+----------+------------------+------------------------+ -| **Date** | **Ver.** | **Author** | **Comment** | -| | | | | -+------------+----------+------------------+------------------------+ -| 2016-12-12 | 0.0.1 | Morgan Richomme | Beginning of the | -| | | (Orange) | Internship | -+------------+----------+------------------+------------------------+ - - -Overview: -========= - - -This project aims to create an Open Source catalog for reference and -classification of Virtual Network Functions (VNFs)s available on -Internet. The classification method proposed will be in sync with the -requirements of Telcos active in NFV landscape. The project aims to have -running web platform similar to [1] by the mid of internship (2nd week -of March). By the penultimate month of internship I aim to have fully -functional implementation of an Open Source VNF in functest. - - -Problem Statement: ------------------- - -OPNFV aims to be the reference platform for development, -standardization and integration of Open Source NFV components across -various Open Source Platforms. It mainly deals with the infrastructure -through the Network Function Virtualization Infrastructure (NFVI) and -Virtual Infrastructure manager (VIM). The MANO (Management and -orchestration) stacks have been introduced recently. VNFs are not -directly in OPNFV scope, however VNFs are needed to test and qualify the -infrastructure. In this regard having a common curated Open Source -Reference VNF catalog would be of immense importance to community. - -Since major focus of OPNFV is Telcos, a curated platform targeted from -industry point of view would be very useful. We plan to divide the -entire project into three major phases(with some iterative improvements -and overlaps) - - -Curation Phase --------------- -This phase pertains to studying various Open Source VNFs available and -classification of them based on certain parameters. The parameters that -I currently have in mind are: - * Developer Metrics: These pertain to repo characteristics of VNF under - study - * Usage Statistics - Activity, Number of Commits, stars - * Maturity Statistics - For instance if an NFV community decides code - coverage is important for them, it shows the NFV community is serious - about taking the project forward - * Technical Tagging: These are the tags that pertain to technical - characteristics of a VNF - * Broad Use Cases - Whether the VNF fits strictly in IaaS, PaaS or - SaaS layer or is an hybrid of two/all. - * Generic Use Cases - This in my opinion is the broadest - classification category. For instance a VNF could be built with a - broad idea of powering IOT devices at home or from usage perspective - of Telco Operators (vFW, vEPC, vIMS, vCDN, vAAA, vCPE,...).`[2]`_ - * Fields of Application - * Library Status - Whether APIs are standardized, support RESTful - services. - * Dependency Forwarding Graph - This is pretty complex tagging - mechanism. It essentially tries to establish a graph relationship - between the VNFs (elementary VNFs are used in Service Function - Chaining chains such as Firewall, DPI, content enrichment,..). In my - opinion this is useful immensely. This will allow users to go to - platform and ask a question like - “I have this X tech stack to - support, Y and Z are my use cases, which NFVs should I use to support - this. - * Visitor Score - Based on `[1]`_ I plan to evolve a visitor score for - the platform. This will allow users to score an NFV on certain - parameters, may be post comments. - -**I plan to use the above three scores and evolve cumulative score which -will be displayed next to each of the NFV on the platform.** - - * Platform building phase - This will involve erecting a Web Platform - which will be similar to this `[1]`_. I am decently familiar with - Django and hence I will write the platform in Django. There are two - action plans that I have in mind right now. Either I can start writing - the platform simultaneously which will help keep track of my progress - or I can write the platform after 1.5 - 2 months into the internship. - Either way I aim to have the Web Platform ready by March 12. - - * Functest VNF implementation phase - This is the last phase that will - involve writing a fully functional implementation of an Open Source VNF - into Functest. I will undertake this after I am 3 months into the - internship. I have a decent familiarity with python and hence I think - it shouldn’t be too difficult. I need to decide how complex the VNFI - should undertake this exercise for (e.g. AAA such as free radius sounds - relatively easy, vCDN is much more challenging). - This will be decided in consent with my mentors. - - - - -Schedule: -========= -I plan to take this project in 6 months time frame as I want to use it -as a chance to read more about NFVs in particular and SDN in general - - -+--------------------------+------------------------------------------+ -| **Date** | **Comment** | -| | | -+--------------------------+------------------------------------------+ -| December 12 - January 12 | Study the above mentioned metrics | -| | Decide which of them are important for | -| | community (and which are not). | -+--------------------------+------------------------------------------+ -| January 12 - January 27 | Make a database for the above studied | -| | metrics and evolve it further based on | -| | Mentors’ input. + associated API | -+--------------------------+------------------------------------------+ -| January 27 - February 5 | Compile the data collected above and make| -| | it public. Although I can keep everything| -| | public from the beginning too. My | -| | rationale of not making the entire data | -| | public in initial stage as the errors | -| | caused by me could be misleading for | -| | developers. | -+--------------------------+------------------------------------------+ -| February 5 - March 5 | Erect the Web Platform and release it | -| | for restricted group for alpha testing. | -+--------------------------+------------------------------------------+ -| March 5 - March 12 | Make it public. Release it to public for | -| | beta testing. Fix Bugs. | -+--------------------------+------------------------------------------+ -| March 12 - April 12 | Start working on implementation of an | -| | Open Source VNF in Functest. | -+--------------------------+------------------------------------------+ -| April 12 - May 12 | I will decided what to do here based on | -| | discussion with mentors. | -+--------------------------+------------------------------------------+ - - -References: -=========== - -.. _`[1]` : Openhub: https://www.openhub.net/explore/projects - -.. _`[2]` : ETSI NFV White Paper: https://portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV_White_Paper3.pdf - -.. _`[3]` : https://wiki.opnfv.org/display/DEV/Intern+Project%3A+Open+Source+VNF+catalog |