diff options
| -rw-r--r-- | docs/images/opnfvplatformgraphic.png | bin | 0 -> 136767 bytes | |||
| -rw-r--r-- | docs/overview/index.rst (renamed from docs/platformoverview/index.rst) | 9 | ||||
| -rw-r--r-- | docs/overview/overview.rst | 289 | ||||
| -rw-r--r-- | docs/platformoverview/deploymenttools.rst | 46 | ||||
| -rw-r--r-- | docs/platformoverview/introduction.rst | 70 | ||||
| -rw-r--r-- | docs/platformoverview/softwarearchitecture.rst | 211 | ||||
| -rw-r--r-- | docs/platformoverview/testcasesframework.rst | 110 |
7 files changed, 291 insertions, 444 deletions
diff --git a/docs/images/opnfvplatformgraphic.png b/docs/images/opnfvplatformgraphic.png Binary files differnew file mode 100644 index 000000000..9d6074f02 --- /dev/null +++ b/docs/images/opnfvplatformgraphic.png diff --git a/docs/platformoverview/index.rst b/docs/overview/index.rst index 49252002c..6b7b66846 100644 --- a/docs/platformoverview/index.rst +++ b/docs/overview/index.rst @@ -1,17 +1,12 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, Huawei +.. (c) Open Platform for NFV Project, Inc. and its contributors ******************************** OPNFV Platform Overview Document ******************************** -Colorado 1.0 ------------- .. toctree:: :maxdepth: 2 - introduction.rst - softwarearchitecture.rst - deploymenttools.rst - testcasesframework.rst + ./overview.rst diff --git a/docs/overview/overview.rst b/docs/overview/overview.rst new file mode 100644 index 000000000..26ec052b1 --- /dev/null +++ b/docs/overview/overview.rst @@ -0,0 +1,289 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Open Platform for NFV Project, Inc. and its contributors + +============ +Introduction +============ + +Network Functions Virtualization (NFV) is transforming the networking industry via +software-defined infrastructures and open source is the proven method for developing +software quickly for commercial products and services that can move markets. +Open Platform for NFV (OPNFV) facilitates the development and evolution of NFV +components across various open source ecosystems. Through system level integration, +deployment and testing, OPNFV constructs a reference NFV platform to accelerate the +transformation of enterprise and service provider networks. +As an open source project, OPNFV is uniquely positioned to bring together the work +of standards bodies, open source communities, and commercial suppliers to deliver a +de facto NFV platform for the industry. + +By integrating components from upstream projects, the community is able to conduct performance +and use case-based testing on a variety of solutions to ensure the platform’s suitability for +NFV use cases. OPNFV also works upstream with other open source communities to bring both contributions +and learnings from its work directly to those communities in the form of blueprints, patches, +and new code. + +OPNFV initially focused on building NFV Infrastructure (NFVI) and Virtualised Infrastructure +Management (VIM) by integrating components from upstream projects such as OpenDaylight, +OpenStack, Ceph Storage, KVM, Open vSwitch, and Linux. +More recently, OPNFV has extended its portfolio of forwarding solutions to include fd.io and ODP, +is able to run on both Intel and ARM commercial and white-box hardware, and includes +Management and Network Orchestration MANO components primarily for application composition +and management in the Colorado release. + +These capabilities, along with application programmable interfaces (APIs) to other NFV +elements, form the basic infrastructure required for Virtualized Network Functions (VNF) +and MANO components. + +Concentrating on these components while also considering proposed projects on additional +topics (such as the MANO components and applications themselves), OPNFV aims to enhance +NFV services by increasing performance and power efficiency improving reliability, +availability and serviceability, and delivering comprehensive platform instrumentation. + +=========================== +OPNFV Platform Architecture +=========================== + +The OPNFV project addresses a number of aspects in the development of a consistent virtualisation +platform including common hardware requirements, software architecture, MANO and applications. + + +OPNFV Platform Overview Diagram + +.. image:: ../images/opnfvplatformgraphic.png + :alt: Overview infographic of the opnfv platform and projects. + + +To address these areas effectively, the OPNFV platform architecture can be decomposed +into the following basic building blocks: + +* Hardware: with the Infra working group, Pharos project and associated activities +* Software Platform: through the platform integration and deployment projects +* MANO: through the MANO working group and associated projects +* Applications: which affect all other areas and drive requirements for OPNFV + +OPNFV Lab Infrastructure +======================== + +The infrastructure working group oversees such topics as lab management, workflow, +definitions, metrics and tools for OPNFV infrastructure. + +Fundamental to the WG is the `Pharos Project <https://www.opnfv.org/developers/pharos>`_ +which provides a set of defined lab infrastructures over a geographically and technically +diverse federated global OPNFV lab. + +Labs may instantiate bare-metal and virtual environments that are accessed remotely by the +community and used for OPNFV platform and feature development, build, deploy and testing. +No two labs are the same and the heterogeneity of the Pharos environment provides the ideal +platform for establishing hardware and software abstractions providing well understood +performance characteristics. + +Community labs are hosted by OPNFV member companies on a voluntary basis. +The Linux Foundation also hosts an OPNFV lab that provides centralized CI +and other production resources which are linked to community labs. +Future lab capabilities will include the ability easily automate deploy and test of any +OPNFV install scenario in any lab environment as well as on a nested "lab as a service" +virtual infrastructure. + +OPNFV Software Platform Architecture +==================================== + +The OPNFV software platform is comprised exclusively of open source implementations of +platform component pieces. OPNFV is able to draw from the rich ecosystem of NFV related +technologies available in open-source then integrate, test, measure and improve these +components in conjunction with our source communities. + +While the composition of the OPNFV software platform is highly complex and constituted of many +projects and components, a subset of these projects gain the most attention from the OPNFV community +to drive the development of new technologies and capabilities. + +--------------------------------- +Virtual Infrastructure Management +--------------------------------- + +OPNFV derives it's virtual infrastructure management from one of our largest upstream ecosystems +OpenStack. OpenStack provides a complete reference cloud management system and associated technologies. +While the OpenStack community sustains a broad set of projects, not all technologies are relevant in +an NFV domain, the OPNFV community consumes a sub-set of OpenStack projects where the usage and +composition may vary depending on the installer and scenario. + +For details on the scenarios available in OPNFV and the specific composition of components +refer to the OPNFV installation instruction: +https://artifacts.opnfv.org/opnfvdocs/colorado/docs/installationprocedure/index.rst + +----------------- +Operating Systems +----------------- + +OPNFV currently uses Linux on all target machines, this can include Ubuntu, Centos or SUSE linux. The +specific version of Linux used for any deployment is documented in the installation guide. + +----------------------- +Networking Technologies +----------------------- + +SDN Controllers +--------------- + +OPNFV, as an NFV focused project, has a significant investment on networking technologies +and provides a broad variety of integrated open source reference solutions. The diversity +of controllers able to be used in OPNFV is supported by a similarly diverse set of +forwarding technologies. + +There are many SDN controllers available today relevant to virtual environments +where the OPNFV community supports and contributes to a number of these. The controllers +being worked on by the community during this release of OPNFV include: + +* Neutron: an OpenStack project to provide “network connectivity as a service” between + interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova). +* OpenDaylight: addresses multivendor, traditional and greenfield networks, establishing the + industry’s de facto SDN platform and providing the foundation for networks of the future. +* ONOS: a carrier-grade SDN network operating system designed for high availability, + performance, scale-out. + +.. OpenContrail SDN controller is planned to be supported in the next release. + +Data Plane +---------- + +OPNFV extends Linux virtual networking capabilities by using virtual switching +and routing components. The OPNFV community proactively engages with these source +communities to address performance, scale and resiliency needs apparent in carrier +networks. + +* FD.io (Fast data - Input/Output): a collection of several projects and libraries to + amplify the transformation that began with Data Plane Development Kit (DPDK) to support + flexible, programmable and composable services on a generic hardware platform. +* Open vSwitch: a production quality, multilayer virtual switch designed to enable + massive network automation through programmatic extension, while still supporting standard + management interfaces and protocols. + +Deployment Architecture +======================= + +A typical OPNFV deployment starts with three controller nodes running in a high availability +configuration including control plane components from OpenStack, SDN, etc. and a minimum +of two compute nodes for deployment of workloads (VNFs). +A detailed description of the hardware requirements required to support the 5 node configuration +can be found in pharos specification: https://artifacts.opnfv.org/pharos/colorado/docs/specification/index.rst + +In addition to the deployment on a highly available physical infrastructure, OPNFV can be +deployed for development and lab purposes in a virtual environment. In this case each of the hosts +is provided by a virtual machine and allows control and workload placement using nested virtualization. + +The initial deployment is done using a staging server, referred to as the "jumphost". +This server-either physical or virtual-is first installed with the installation program +that then installs OpenStack and other components on the controller nodes and compute nodes. +See the `OPNFV User Guide`_ for more details. + +=========================== +The OPNFV Testing Ecosystem +=========================== + +The OPNFV community has set out to address the needs of virtualization in the carrier +network and as such platform validation and measurements are a cornerstone to the +iterative releases and objectives. + +To simplify the complex task of feature, component and platform validation and characterization +the testing community has established a fully automated method for addressing all key areas of +platform validation. This required the integration of a variety of testing frameworks in our CI +systems, real time and automated analysis of results, storage and publication of key facts for +each run. + + +Release Verification +==================== + +The OPNFV community relies on its testing community to establish release criteria for each OPNFV +release. Each release cycle the testing criteria become more stringent and better representative +of our feature and resiliency requirements. + + +As each OPNFV release establishes a set of deployment scenarios to validate, the testing +infrastructure and test suites need to accommodate these features and capabilities. It’s not +only in the validation of the scenarios themselves where complexity increases, there are test +cases that require multiple datacenters to execute when evaluating features, including multisite +and distributed datacenter solutions. + +The release criteria as established by the testing teams include passing a set of test cases +derived from the functional testing project ‘functest,’ a set of test cases derived from our +platform system and performance test project ‘yardstick,’ and a selection of test cases for +feature capabilities derived from other test projects such as bottlenecks, vsperf, cperf and +storperf. The scenario needs to be able to be deployed, pass these tests, and be removed from +the infrastructure iteratively (no less that 4 times) in order to fulfill the release criteria. + +-------- +Functest +-------- + +Functest provides a functional testing framework incorporating a number of test suites +and test cases that test and verify OPNFV platform functionality. +The scope of Functest and relevant test cases can be found in its +`user guide <http://artifacts.opnfv.org/functest/colorado/docs/userguide/index.html>`_. + +Functest provides both feature project and component test suite integration, leveraging +OpenStack and SDN controllers testing frameworks to verify the key components of the OPNFV +platform are running successfully. + +--------- +Yardstick +--------- + +Yardstick is a testing project for verifying the infrastructure compliance when running VNF applications. +Yardstick benchmarks a number of characteristics and performance vectors on the infrastructure making it +a valuable pre-deployment NFVI testing tools. + +Yardstick provides a flexible testing framework for launching other OPNFV testing projects. + +There are two types of test cases in Yardstick: + +* Yardstick generic test cases and OPNFV feature test cases; + including basic characteristics benchmarking in compute/storage/network area. +* OPNFV feature test cases include basic telecom feature testing from OPNFV projects; + for example nfv-kvm, sfc, ipv6, Parser, Availability and SDN VPN + +System Evaluation and compliance testing +======================================== + +The OPNFV community is developing a set of test suites intended to evaluate a set of reference +behaviors and capabilities for NFV systems developed externally from the OPNFV ecosystem to +evaluate and measure their ability to provide the features and capabilities developed in the +OPNFV ecosystem. + +The Dovetail project will provide a test framework and methodology able to be used on any NFV platform, +including an agreed set of test cases establishing an evaluation criteria for exercising +an OPNFV compatible system. The Dovetail project has begun establishing the test framework +and will provide a preliminary methodology for the Colorado release. Work will continue to +develop these test cases to establish a stand alone compliance evaluation solution +in future releases. + +Additional Testing +================== + +Besides the test suites and cases for release verification, additional testing is performed to validate +specific features or characteristics of the OPNFV platform. +These testing framework and test cases may include some specific needs; such as extended measurements, +additional testing stimuli, or tests simulating environmental disturbances or failures. + +These additional testing activities provide a more complete evaluation of the OPNFV platform. +Some of the projects focused on these testing areas include: + +------ +VSPERF +------ + +VSPERF provides a generic and architecture agnostic vSwitch testing framework and associated tests. +This serves as a basis for validating the suitability of different vSwitch implementations and deployments. + +----------- +Bottlenecks +----------- + +Bottlenecks provides a framework to find system limitations and bottlenecks, providing +root cause isolation capabilities to facilitate system evaluation. + + +.. _`OPNFV Configuration Guide`: http://artifacts.opnfv.org/opnfvdocs/colorado/docs/configguide +.. _`OPNFV User Guide`: http://artifacts.opnfv.org/opnfvdocs/colorado/docs/userguide +.. _Dovetail project: https://wiki.opnfv.org/display/dovetail + diff --git a/docs/platformoverview/deploymenttools.rst b/docs/platformoverview/deploymenttools.rst deleted file mode 100644 index 034ceda69..000000000 --- a/docs/platformoverview/deploymenttools.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, Huawei - -================ -Deployment Tools -================ - -Brahmaputra provides 4 different installers. - -The installers will deploy the target platform onto a set of virtual or bare metal servers according -to the configuration files. After the deployment, it doesn't matter which of the installers had been used -to deploy the target scenario. - -**Apex** is an OPNFV Installation tool based on RDO Manager that deploys OPNFV using the RDO Project -OpenStack Distribution. -RDO manager is a Triple-O based installation tool. -Triple-O is an image based life cycle deployment tool that is a member of the OpenStack Big Tent Governance. -Apex uses Centos on all target platforms and can deploy all SDN controllers. -Find more information at -`OpenStack Wiki for Triple-O <https://wiki.openstack.org/wiki/TripleO>`_ and `OPNFV Configuration Guide`_. - -**Compass** is an installer project based on open source project Compass, which provides automated deployment -and management of OpenStack and other distributed systems. -It can be considered as what the LiveCD to a single box for a pool of servers – bootstrapping the server pool. -Compass is based on Ansible. -It can deploy Ubuntu or Centos as target operating system and ODL and ONOS as SDN controllers. -Find more information at -`OpenStack Wiki for Compass <https://wiki.openstack.org/wiki/Compass>`_ and `OPNFV Configuration Guide`_. - -**Fuel** is an installer project based on the Fuel OpenStack open source project -providing automated deployment and management of OpenStack and other distributed systems. -Fuel is based on puppet and deploys the Ubuntu Linux operating system; -the OpenStack virtual Infra-structure manager, and OpenDaylight or ONOS SDN controllers. -Find more information at -`OpenStack Wiki for Fuel <https://wiki.openstack.org/wiki/Fuel>`_ and `OPNFV Configuration Guide`_. - -**Joid** is an installer utilizes the technology developed in Juju and MAAS. -Juju allows you to deploy, configure, manage, maintain, and scale -cloud services quickly and efficiently on public clouds, as well as on physical servers, -OpenStack, and containers. Together with MAAS hardware usage can be optimized. -For more info on Juju and MAAS, please visit `<https://jujucharms.com/>`_, -`<http://maas.ubuntu.com>`_ and the -`Joid User Guide <http://artifacts.opnfv.org/joid/brahmaputra/docs/userguide/index.html>`_. - -.. _`OPNFV Configuration Guide`: http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/configguide diff --git a/docs/platformoverview/introduction.rst b/docs/platformoverview/introduction.rst deleted file mode 100644 index eab30e9b1..000000000 --- a/docs/platformoverview/introduction.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, Huawei - -.. ==> All actions still to be resolved during the review are marked "==>" in comments. - -============ -Introduction -============ - -.. ==> take some more inputs from the marketing message - -OPNFV is an integration effort that takes outputs from several open source communities to build a NFV platform. This task of integration leads to providing different kinds of output to its users. - -The primary goal of the OPNFV project is the target software platform, which is a integrated solution -of a set of components/building blocks of the ETSI ISG NFV reference architecture. -In the Brahmaputra release, this is limited to the NFVI and VIM blocks. -OPNFV users will be able to deploy their VNFs there using some MANO solution. -The target software platform is integrated from a set of other open source components, -of which the biggest ones are OpenStack and SDN controllers. There are multiple combinations -possible and a subset is provided and tested by the Brahmaputra release. These subsets -are called here scenarios. - -Besides the target software platform, OPNFV provides a set of tools that helps the user -deploy this target software platform on a set of servers. These tools are installers. -Brahmaputra provides multiple options here. Naturally the different installers -have different capabilities, that is they support deployment of different scenarios. - -The installers allow users to deploy OPNFV target software platform on a bare metal environment -or a set of virtual machines. In both cases, some hosts (bare metal or virtual) will act -as controller nodes, while other hosts will be the compute nodes hosting the VNFs. -The installers use a separate server to control the deployment process. This server is called -"jump server" and is installed with the installer's software at the beginning of a deployment. -The jump server also can be bare metal or virtual. - -This configuration - jump servers and a set of typically 5 nodes to run the target software platform - -is also described as part of an OPNFV release. This allows the users to build their own labs -accordingly and deploy OPNFV easily. A lab compliant to this description sometimes is called -"Pharos-compliant" after the OPNFV project providing the lab description. - -Another major part of the OPNFV release is a testing framework and test cases. -This test framework allows users to verify their deployment of the OPNFV target software platform. -It will execute and test major functions of the platform relevant to NFV applications (VNFs) so -the user can be confident that VNFs can successfully run. - -OPNFV releases come with the necessary documentation describing -target software platform, deployment tools, test cases, etc. in their architecture, configuration and usage. -The most important documents here are configuration guides and user guides that help to set up -a OPNFV deployment and use it. - -The OPNFV project takes major effort to provide lab environments to the community. -The OPNFV community labs of course need to be Pharos-compliant. They are used for OPNFV development -tasks and release creation, but should also provide users with the opportunity to run their own -OPNFV tests. OPNFV community labs are not part of a OPNFV release. -Please find more information on the labs in the -`Pharos project documentation <http://artifacts.opnfv.org/pharos/brahmaputra/docs/index.html>`_. - -We should also mention that OPNFV works on requirements of open source projects used in OPNFV to -make these projects better suitable for NFV telco carrier use cases. -These requirements are described in requirement documents and also forwarded -to the "upstream" projects in the format required by these projects. -These requirement documents are not bound to OPNFV releases. - -OPNFV bundles the target software, installers, documentation, test cases and lab -description to releases. - -This overview document introduces these components and scenarios on a high level and -points you to more detailed documentation. - - diff --git a/docs/platformoverview/softwarearchitecture.rst b/docs/platformoverview/softwarearchitecture.rst deleted file mode 100644 index cf122a5ef..000000000 --- a/docs/platformoverview/softwarearchitecture.rst +++ /dev/null @@ -1,211 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, Huawei - -=========================== -OPNFV Platform Architecture -=========================== - -The OPNFV project addresses a number of aspects in the development of a consistent virtualization -platform including common hardware requirements, software architecture and installed state. -The platform architecture as the OPNFV project approaches it is dicussed in the following sections. - -OPNFV Lab Infrastructure -======================== - -The `Pharos Project <https://www.opnfv.org/developers/pharos>`_ provides a lab infrastructure -that is geographically and technically diverse. -Labs instantiate bare-metal and virtual environments that are accessed remotely by the -community and used for OPNFV platform and feature development, build, deploy and testing. -This helps in developing a highly robust and stable OPNFV platform -with well understood performance characteristics. - -Community labs are hosted by OPNFV member companies on a voluntary basis. -The Linux Foundation also hosts an OPNFV lab that provides centralised CI -and other production resources which are linked to community labs. -Future lab capabilities will include the ability easily automate deploy and test of any -OPNFV install scenario in any lab environemnt as well as on a virtual infrastructure. - -.. ==> I am not sure this is the best place to include this. - - -Software architecture -===================== - -This section will provide information which upstream projects, versions and components are -integrated in the release to implement OPNFV requirement. You can find the list of common -requirements for deployment tools here: -http://artifacts.opnfv.org/genesisreq/brahmaputra/requirements/requirements.pdf. - -OpenStack ---------- - -.. ==> didn't understand Chris' suggestion about reducing the heading level for these sub-topics - -OPNFV integrates OpenStack as cloud management system where Brahmaputra uses the OpenStack Liberty Release. -The set of sub-projects deployed in a brahmaputra platform varies slightly depending on the installer and scenario. - -The following table shows which components are deployed. - -+------------+----------------+-----------+-----------+-----------+-----------+ -| services | type | Apex | Compass | Fuel | Joid | -+============+================+===========+===========+===========+===========+ -| aodh | alarming | Available | --- | --- | --- | -+------------+----------------+-----------+-----------+-----------+-----------+ -| ceilometer | metering | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| cinder | volume | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| cloud | cloudformation | --- | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| glance | image | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| heat | orchestration | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| keystone | identity | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| neutron | network | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| nova | compute | Available | Available | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ -| swift | object-store | Available | --- | Available | Available | -+------------+----------------+-----------+-----------+-----------+-----------+ - - -Note that additional components of OpenStack are used as part of deployment tools and test frameworks -(Fuel, Tempest, Rally). - -For more information about the OpenStack features and usage refer to the -`official OpenStack documentation page <http://docs.openstack.org/>`_. -Please ensure that you have the Liberty release selected at the -``More Releases & Languages`` drop down menu. - -Operating System ----------------- - -OPNFV uses Linux on all target machines. Depending on the installers, different -distributions are supported. - -Ubuntu 14 supported by Fuel, Compass and Joid installers -CentOS 7 supported by Apex and Compass - - -SDN Controllers ---------------- - -OPNFV Brahmaputra release supports different SDN controllers. -Some scenarios don't use an SDN controller but rely just on Neutron networking capabilities. - -Depending on the SDN controller you are using, the featureset available will vary. -More information on feature support and scenarios can be found in `OPNFV Configuration Guide`_ and `OPNFV User Guide`_. -Brahmaputra also provides scenarios without an SDN controller, just using OpenStack Neutron. - -OpenDaylight is an SDN controller aiming to accelerate -adoption of Software-Defined Networking (SDN) and Network Functions Virtualization -(NFV) with a transparent approach that fosters new innovation. -OpenDaylight runs within a JVM and is installed in OPNFV within a container and integrated with OpenStack -using the ODL device driver. The Brahmaputra release of OPNFV integrates the Beryllium release. -You can find more information about OpenDaylight among the release artifacts at the -`Downloads page <https://www.opendaylight.org/downloads>`_. -Please ensure you are using the Beryllium documentation. - -ONOS is an SDN controller written in Java with a distributed architecture with special focus to -support scalability, fault tolerance and hardware and software upgrades without -interrupting network traffic. -More information on the internal design of ONOS may be found in -`User's Guide <https://wiki.onosproject.org/display/ONOS/User's+Guide>`_ and -`Architecture+Guide <https://wiki.onosproject.org/display/ONOS/Architecture+Guide>`_ on the -`wiki of the ONOS project <https://wiki.onosproject.org>`_. -ONOS is integrated to OPNFV using a framework ONOSFW and Neutron plugins. Details can be found in the -ONOS specific OPNFV documents, -`Design guide <http://artifacts.opnfv.org/onosfw/brahmaputra/design/design.pdf>`_, -`User guide <http://artifacts.opnfv.org/onosfw/brahmaputra/userguide/index.html>`_ and -`Configuration guide <http://artifacts.opnfv.org/onosfw/brahmaputra/configguide/index.html>`_. - -.. OpenContrail SDN controller will be supported in the next drop of the Brahmaputra release. - - -Data Plane ----------- - -OPNFV extends Linux's virtual networking capabilies by using virtual switch -and router components including improving those components by requirements -specific to telco use cases. - -For instance some scenarios use OpenVSwitch -to replace Linux bridges as it offers advantages in terms of mobility, hardware -integration and use by network controllers. OPNFV leverages these by upgrade -to a specific installation using user-space datapath. This includes changes to -other dataplane components, including libvirt, qemu, DPDK etc. -Please find more information in -`OVSNFV User's Guide <http://artifacts.opnfv.org/ovsnfv/brahmaputra/docs/userguides/userguides.pdf>`_. - -Other Components ----------------- - -**KVM** - -NFV infrastructure has special requirements on hypervisors with respect of -interrupt latency (timing correctness and packet latency in data plane) and -live migration. - -Besides additional software changes, this requires -some adjustments to system configuration -information, like hardware, BIOS, OS, etc. - -.. KVM4NFV is one implementation, we have three implementations of the OS virtualization layer -.. to capture here. -.. ==> need more input - -Please find more information at -`KVM4NFV project documentation <http://artifacts.opnfv.org/kvmfornfv/docs/all/all.pdf>`_. - -.. As it is a platform overview I think if we mention KVM as hypervisor we should focus on which version we are using and how as opposed to the OPNFV project that deals with KVM itself. - - - -Deployment Architecture -======================= - -OPNFV starts with a typical configuration with 3 controller nodes running -OpenStack, SDN, etc. and a minimum of 2 compute nodes for deployment of VNFs. -A detailed description of this 5 node configuration can be found in pharos documentation. - -The 3 controller nodes allow to provide an HA configuration. The number of compute -nodes can be increased dynamically after the initial deployment. - -OPNFV can be deployed on bare metal or in a virtual environment, where each of the hosts -is a virtual machine and provides the virtual resources using nested virtualization. - -The initial deployment is done using a so-called "jumphost". This server (either bare metal -or virtual) is first installed with the installer program that then installs OpenStack -and other components on the controller nodes and compute nodes. See the `OPNFV User Guide`_ -for more details. - -.. Editors note: -.. In a second level of detail, describe how software is distributed over the 3 controller -.. nodes, compute nodes and other hardware. - - -In Brahmaputra, different scenarios can be deployed to provide the different feature sets, e.g. -HA, IPV6, BGPVPN, KVM, or select the different implementations, e.g. SDN controllers. - -.. ==> Is it described somewhere what we mean by scenarios? If yes, then the original text is better. -.. If not, I would give a brief overview here to describe the term. - -The following scenarios are supported, some of them can be deployed using different installers. - -* nosdn-nofeature -* odl_l2-ha -* odl_l3-ha -* odl_l2-bgpvpn-noha -* onos-ha -* nosdn-ovs-ha -* nosdn-kvm-ha -* nosdn-ovs_kvm-ha - -Please find more information at: -http://artifacts.opnfv.org/opnfvdocs/brahmaputra/configguide/configoptions.html#opnfv-scenario-s. - -.. _`OPNFV Configuration Guide`: http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/configguide -.. _`OPNFV User Guide`: http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/userguide diff --git a/docs/platformoverview/testcasesframework.rst b/docs/platformoverview/testcasesframework.rst deleted file mode 100644 index 73c9cd187..000000000 --- a/docs/platformoverview/testcasesframework.rst +++ /dev/null @@ -1,110 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) OPNFV, Huawei - -================= -Testing ecosystem -================= - -Testing is a key area and also a challenge for OPNFV in order to be able to -verify and validate the platform we are creating. - -This is a complex task as we have to test the integration of the components, -the functionality we are creating and using and we have to verify -that the platform is suitable for telecom applications. -We do testing in an automated fashion by using several test tools and frameworks in our CI/CD pipeline. - -This chapter gives an overview about our testing tools and activities. - - -Release verification -==================== - -OPNFV releases the target platform together with the deployment tools in a set of scenarios -that provides choices regarding the deployed components and the available features. -The scenarios and the provided functionality are tested automatically in the CI/CD pipeline -mentioned above and they are considered to be ready for release after -at least 4 successful consecutive iterations. - -The functional testing and the platform validation are divided between two projects called Functest and Yardstick. - -Functest --------- - -Functest provides a functional testing framework along with a set of test suites -and test cases that test and verify OPNFV platform functionality. -The scope of Functest and relevant test cases can be found in its -`user guide <http://artifacts.opnfv.org/functest/brahmaputra/docs/userguide/userguide.pdf>`_. - -In Brahmaputra, Functest is focusing on OpenStack and SDN controllers deployment testing. -Its testing framework combines a number of testing tools -to verify the key components of the OPNFV platform are running successfully. -For example, Rally and Tempest are integrated for OpenStack basic functional testing and benchmark, -Robot is used for ODL testing, and Teston is integrated for ONOS testing. -Besides these, Functest also includes tests by deploying candidate VNFs such as vPing and vIMS, and testing their basic functionality. - -Yardstick ---------- - -Yardstick is a testing project for verifying the infrastructure compliance when running VNF applications. -Yardstick can benchmark a number of characteristics/performance vectors about the infrastructure, -that makes it become a useful pre-deployment NFVI testing tools. - -Yardstick is also a flexible testing framework supporting OPNFV feature testing by the various projects in OPNFV. -Projects can plug in their test cases for specific features easily. - -The detail of Yardstick project can be found in the -`yardstick user guide <http://artifacts.opnfv.org/yardstick/brahmaputra/user_guides_framework/user_guides_framework.pdf>`_. - -There are two types of test cases in Yardstick: Yardstick generic test cases and OPNFV feature test cases. -Yardstick generic test cases include basic characteristics benchmarking in compute/storage/network area. -OPNFV feature test cases include basic telecom feature testing from OPNFV projects, -for example nfv-kvm, sfc, ipv6, Parser, Availability and SDN VPN. - -All of the Yardstick test cases are listed on -`<http://artifacts.opnfv.org/yardstick/brahmaputra/docs/configguide_yardstick_testcases/03-list-of-tcs.html>`_. - - -Additional Testing -================== - -Besides the test suites and cases for release verification, there are some additional testing -for specific feature or characteristics on OPNFV platform. -These testing framework and test cases may include some specific needs, -such as extended measurements, or additional testing stimuli, or tests which cause disturbances on the environment. -These additional testing can provide a more complete evaluation about OPNFV platform deployment. - -Qtip ----- - -Qtip is a performance benchmark testing project by using a "Bottom-Up" approach -in characterizing and benchmarking OPNFV platform. -Qtip aims to benchmark the performance of components for a quantitative analysis and doesn't deal with validation of the platform. - -In Brahmaputra, Qtip develops a flexible framework, -adds a number of test cases covering compute/storage/network area, -and compares these benchmarks on a bare metal machine vs a VM. -These contrastive result can be used to evaluate the performance of these components on the OPNFV platform basically. - -VSPERF ------- - -VSPERF will develop a generic and architecture agnostic vSwitch testing framework and associated tests, -that will serve as a basis for validating the suitability of different vSwitch implementations -in a Telco NFV deployment environment. -The output of this project will be utilized as part of OPNFV Platform and VNF level testing and validation. - -Bottlenecks ------------ - -Bottlenecks will provide a framework to find system bottlenecks -by testing and verifying OPNFV infrastructure in a staging environment before committing it to a production environment. -The Bottlenecks framework can not only find specific system limitations and bottlenecks, -but also the root cause of these bottlenecks. - -In Brahmaputra, Bottlenecks includes two test cases: -rubbos and vstf. These test cases are executed on OPNFV community pods, -and test result report are visible on the community testing dashboard. - - - |
