diff options
Diffstat (limited to 'docs/development')
23 files changed, 0 insertions, 669 deletions
diff --git a/docs/development/feature.templates/scenarios/scenario.name/index.rst b/docs/development/feature.templates/scenarios/scenario.name/index.rst deleted file mode 100644 index 59ada34..0000000 --- a/docs/development/feature.templates/scenarios/scenario.name/index.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -=================================== -<scenario> overview and description -=================================== -.. This document will be used to provide a description of the scenario for an end user. -.. You should explain the purpose of the scenario, the types of capabilities provided and -.. the unique components that make up the scenario including how they are used. - -.. toctree:: - :maxdepth: 3 - - ./scenario.description.rst - diff --git a/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst b/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst deleted file mode 100644 index afd5879..0000000 --- a/docs/development/feature.templates/scenarios/scenario.name/scenario.description.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -Introduction -============ -.. In this section explain the purpose of the scenario and the types of capabilities provided - -Scenario components and composition -=================================== -.. In this section describe the unique components that make up the scenario, -.. what each component provides and why it has been included in order -.. to communicate to the user the capabilities available in this scenario. - -Scenario usage overview -======================= -.. Provide a brief overview on how to use the scenario and the features available to the -.. user. This should be an "introduction" to the userguide document, and explicitly link to it, -.. where the specifics of the features are covered including examples and API's - -Limitations, Issues and Workarounds -=================================== -.. Explain scenario limitations here, this should be at a design level rather than discussing -.. faults or bugs. If the system design only provide some expected functionality then provide -.. some insight at this point. - -References -========== - -For more information on the OPNFV Colorado release, please visit -http://www.opnfv.org/colorado - diff --git a/docs/development/feature.templates/userguide/feature.userguide.rst b/docs/development/feature.templates/userguide/feature.userguide.rst deleted file mode 100644 index b8adfa5..0000000 --- a/docs/development/feature.templates/userguide/feature.userguide.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -<Feature> description -===================== -.. Describe the specific features and how it is realised in the scenario in a brief manner -.. to ensure the user understand the context for the user guide instructions to follow. - -<Feature> capabilities and usage -================================ -.. Describe the specific capabilities and usage for <XYZ> feature. -.. Provide enough information that a user will be able to operate the feature on a deployed scenario. - -<Feature and API usage guidelines and example> ------------------------------------------------ -.. Describe with examples how to use specific features, provide API examples and details required to -.. operate the feature on the platform. - diff --git a/docs/development/feature.templates/userguide/index.rst b/docs/development/feature.templates/userguide/index.rst deleted file mode 100644 index cc84670..0000000 --- a/docs/development/feature.templates/userguide/index.rst +++ /dev/null @@ -1,23 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -==================== -<feature> user guide -==================== - -.. The feature user guide should provide an OPNFV user with enough information to -.. use the features provided by the feature project in the supported scenarios. -.. This guide should walk a user through the usage of the features once a scenario -.. has been deployed and is active according to the installation guide provided -.. by the installer project. - -.. toctree:: - :maxdepth: 3 - -.. The feature.userguide.rst file should contain the text for this document -.. additional documents can be added to this directory and added in the right order -.. to this file as a list below. - - ./feature.userguide.rst - diff --git a/docs/development/opnfvsecguide/_static/temp b/docs/development/opnfvsecguide/_static/temp deleted file mode 100644 index e69de29..0000000 --- a/docs/development/opnfvsecguide/_static/temp +++ /dev/null diff --git a/docs/development/opnfvsecguide/_templates/temp b/docs/development/opnfvsecguide/_templates/temp deleted file mode 100644 index e69de29..0000000 --- a/docs/development/opnfvsecguide/_templates/temp +++ /dev/null diff --git a/docs/development/opnfvsecguide/audit.rst b/docs/development/opnfvsecguide/audit.rst deleted file mode 100644 index cdeecba..0000000 --- a/docs/development/opnfvsecguide/audit.rst +++ /dev/null @@ -1,9 +0,0 @@ -Audit ----------------- - -.. toctree:: - :maxdepth: 2 - - audit/audit_reqs - audit/configuring - diff --git a/docs/development/opnfvsecguide/audit/audit_reqs.rst b/docs/development/opnfvsecguide/audit/audit_reqs.rst deleted file mode 100644 index ce76d01..0000000 --- a/docs/development/opnfvsecguide/audit/audit_reqs.rst +++ /dev/null @@ -1,110 +0,0 @@ -Requirements references related to OPNFV Audit - ------------------- -Source information ------------------- - -http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/003/01.01.01_60/gs_NFV-INF003v010101p.pdf -http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/004/01.01.01_60/gs_NFV-INF004v010101p.pdf - -* ETSI GS NFV-SEC 003 V1.1.1 (2014-12) - - - Network Functions Virtualisation NFV); - - NFV Security; Security and Trust Guidance - - NFV-SEC-003_. - - -.. _NFV-SEC-003: http://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/003/01.01.01_60/gs_NFV-SEC003v010101p.pdf -* ETSI GS NFV 004 V1.1.1 (2013-10) - - - Network Functions Virtualisation (NFV); - - Virtualisation Requirements - - NFV-SEC-004_. - -.. _NFV-SEC-004: http://www.etsi.org/deliver/etsi_gs/NFV/001_099/004/01.01.01_60/gs_NFV004v010101p.pdf - -Requirements on Auditing framework ----------------------------------- - -Audit records shall be maintained within protected binary logs so that the record of -malicious actions cannot be deleted from the logs. - -Necessary auditable events --------------------------- - -* access control management - - - Adding a user account - - Modifying user account - - Deleting a user account - - login event - - logout event - - IP whitelisting update - - IP blacklisting update - -* VNFC Creation - - - The instantiation of a newly-defined VNFC - - The instantiation of a VNFC with pre-configured state - - The cloning of an existing VNFC - -* VNFC Deletion - - - The deletion of VNFC and of all of its instances (e.g. snapshots, backups, archives, cloned images) - -* Software management - - - patching e.g. opreating system, drivers, VM components - - dynamic updates to the configuration e.g. DNS, DHCP - - application software updates - - software component updates - -* Data management - - - Root level access to NFVI file system - - User level access to NFVI file system - - Secured wipe, disk and memory - - Verified destruction - - Certificate revocation - -* VNFC Migration - - - VNFC original host identity - - VNFC target host identity - - high availability - - recovery - - data-in-motion changes - -* Other VNFC Operational State Changes - - - Hibernation, sleep, resumption, abort, restore, suspension - - Power-on and power-off (either physical or virtual) - - Integrity verification failure, crash and OS compromise - -* VNFC Topology Changes - - - Network IP address and VLAN updates - - Service chaining - - Failover and disaster recovery - -* traffic inspection - - - enabling virtual port mirroring - - enabling hypervisor introspection - - enabling in-line traffic inspection - - application insertion - -* initial provisioning of a public/private key pair - - - Self-generation of key pairs for later validation by an external party: - - - Certificate Authority - - VNFM - - - Provision by trusted party - - - network - - storage - - - Injection by hypervisor - diff --git a/docs/development/opnfvsecguide/compute.rst b/docs/development/opnfvsecguide/compute.rst deleted file mode 100644 index d6c1a01..0000000 --- a/docs/development/opnfvsecguide/compute.rst +++ /dev/null @@ -1,8 +0,0 @@ -Compute Security ----------------- - -.. toctree:: - :maxdepth: 2 - - compute/dacmaccontrols.rst - compute/trust.rst diff --git a/docs/development/opnfvsecguide/compute/dacmaccontrols.rst b/docs/development/opnfvsecguide/compute/dacmaccontrols.rst deleted file mode 100644 index 08cd7ee..0000000 --- a/docs/development/opnfvsecguide/compute/dacmaccontrols.rst +++ /dev/null @@ -1,3 +0,0 @@ -DAC & MAC Controls ------------------- - diff --git a/docs/development/opnfvsecguide/compute/trust.rst b/docs/development/opnfvsecguide/compute/trust.rst deleted file mode 100644 index 3022e59..0000000 --- a/docs/development/opnfvsecguide/compute/trust.rst +++ /dev/null @@ -1,124 +0,0 @@ -Trusted Compute ---------------- - -Trusted compute is centered on insuring the complete lifecycle of a VM, and -the VM's underlying infrastructure is of a 'trustful' state. - -**Trusted computing in a cloud environment** - -To ensure overall security in an OPNFV deployment, both the launch and the -operation of virtualized resources need to be secure. To build a trusted -computing in a cloud environment the following core features are essential: - -* boot integrity - the hardware platform can guarantee a trustworthy RoT for the overall cloud environment -* secure management of VMs – to secure the launch and migration of VMs in the cloud environment - -In this section we will cover some aspects of what is considered compute -security, such as secure/trusted boot, although of course these can be -extended to other actors such as neutron networking nodes. - -Secure Boot -########### - -Secure boot, a UEFI-based feature that has become controversial lately, -ensures that nodes in an OPNFV deployment boot only software that is trusted -by the admin or end user. - -In order to understand the secure boot procedure, we need to explain the related technology -and specification. - -**Unified Extensible Firmware Interface (UEFI)** - -UEFI is a specification intended to be the replacement and improvement on the -old BIOS (Basic Input/Output System). - -One UEFI-based feature that has become controversial lately is the secure boot feature. - -The UEFI specification is a standard that’s handled by a non-profit organization -with representatives of Intel, AMD, Microsoft, Apple, Dell, HP, IBM and others, -called the Unified EFI Forum. - -UEFI supports 32 and 64 bit processors and can be used with Itanium, x86, -x64 and ARM processors. - -**Trusted Execution Environment (TEE) vs Trusted Platform Mobile (TPM)** - -Two main components of platform security: - -* Trusted Execution Environment -* Trusted Platform Module - -These are not designed as a replacement of the other. TEE is the bulletproof -safe, while TPM is the 128-digit combination lock for the safe. Both are -needed to ensure the safe is protected. - -TPM is a dependency of TEE but not the other way around. - -The TPM is where TEE will store the measurements - hash of components - of the platform. - -If TEE is not supported by a platform but a TPM is still present you still have -all these features: - -* Integrity measurement – securely measure the platform's components (hashes stored within the TPM) - -* Authenticated boot – a process by which a platform's state (the sum of its - components) is reliably measured and stored - -* SRTM - Static Root of Trust for Measurements - -* Sealed Storage - encrypt data based on the current state of the platform - or in other words, what has been measured (the PCR hash values stored in the - TPM) - seal operation - -* Attestation - securely report to other parties the state of the platform - - -Trusted Compute Pools -##################### - -**Trusted Boot** - -Trusted boot (tboot) is an open source, pre- kernel/VMM module that uses -Intel(R) Trusted Execution Technology (Intel(R) TXT) to perform a measured -and verified launch of an OS kernel/VMM. The root of trust is in the hardware -and a TPM is required. Compute nodes in an OPNFV deployment boot with Intel -TXT technology enabled. - -Read more about `Trusted Boot <http://www.trustedcomputinggroup.org/resources/trusted_boot>`_ and -`Trusted Computing. <http://www.trustedcomputinggroup.org/trusted_computing>`_ - -**Trusted Execution Environments (TEE)** - -The Trusted Execution Environment is an isolated execution environment which -provides higher level of security such as isolated execution, integrity of -Trusted Applications along with confidentiality of their assets. - -**Goals of a Trusted Execution Environments:** - -* Isolated Execution -* Secure Storage -* Remote Attestation -* Secure Provisioning -* Trusted Path - -**TEE platforms/implementations** - -* Intel’s TXT (Trusted Execution Technology) -* AMD Secure Execution Environment -* ARM TrustZone - -All three of these TEE implementations provide a virtualized Execution -Environment for the secure OS and applications. - -To switch between the secure world and the normal world, Intel provides SMX -Instructions, while ARM uses SMC. Programmatically, they all achieve very -similar results. - -Read more about Trusted Execution Environments `here. <http://www.openvirtualization.org/open-source-arm-trustzone.html>`_ - -`NIST SP800-147 <http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf>`_ -, is a guidelines for firmware security, to ensure that the firmware itself is secure. - -Read more about "Trusted compute pools", in the -`OpenStack Security Guide. <http://docs.openstack.org/admin-guide-cloud/compute-security.html>`_ - diff --git a/docs/development/opnfvsecguide/contribution.rst b/docs/development/opnfvsecguide/contribution.rst deleted file mode 100644 index 683aa2d..0000000 --- a/docs/development/opnfvsecguide/contribution.rst +++ /dev/null @@ -1,45 +0,0 @@ -How to Contribute ------------------ - -Anyone is welcome to make additions, raise bugs, and fix issues within this Documentation. -To do so, you will however need to first get an enviroment set up. - -Development Environment -####################### - -All project data such as formatting guidelines, and upstream mapping is documented via sphinx -which uses reStructuredText - -It is recommended that you use a python virtualenv to keep things clean and contained. - -VirtualEnv -********** - -Use of a virtual environment is recommended, as not only is it a quick easy form of -getting the needed modules in place, it isolates the module versions to a project. - -From within your inspector directory, set up a new virtualenv:: - - virtualenv venv - -Activate the new virtual environment:: - - source venv/bin/activate - -Install requirements:: - - pip install -r requirements.txt - -Sphinx Basics -************* - -To get started with sphinx, visit the main tutorial which will provide a primer `http://sphinx-doc.org/tutorial.html` - -Hack your changes into opnfv-security-guide/source - -To compile changes: - - make html - -From here you can run a basic python web server or just navigate to the -file:///<repo>/opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/development/opnfvsecguide/getting_started.rst b/docs/development/opnfvsecguide/getting_started.rst deleted file mode 100644 index e09507d..0000000 --- a/docs/development/opnfvsecguide/getting_started.rst +++ /dev/null @@ -1,41 +0,0 @@ -Getting Started ---------------- - -Development Environment -####################### - -All project data such as formatting guidelines, and upstream mapping is documented via sphinx -which uses reStructuredText - -VirtualEnv -********** - -Use of a virtual environment is recommended, as not only is it a quick easy form of -getting the needed modules in place, it isolates the module versions to a project. - -From within your inspector directory, set up a new virtualenv:: - - virtualenv venv - -Activate the new virtual environment:: - - source venv/bin/activate - -Install requirements:: - - pip install -r requirements.txt - -Sphinx Basics -************* - -To get started with sphinx, visit the main tutorial which will provide a primer -`http://sphinx-doc.org/tutorial.html` - -Hack your changes into opnfv-security-guide/source - -To compile changes: - - make html - -From here you can run a basic python web server or just navigate to the -file:///<repo>/opnfv-security-guide/build/html/index.html in your browser diff --git a/docs/development/opnfvsecguide/index.rst b/docs/development/opnfvsecguide/index.rst deleted file mode 100644 index ecefd61..0000000 --- a/docs/development/opnfvsecguide/index.rst +++ /dev/null @@ -1,21 +0,0 @@ -.. OPNFV Security Guide documentation master file, created by - sphinx-quickstart on Tue Oct 27 19:30:29 2015. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Welcome to OPNFV Security Guide -================================================ - -This guide seeks to inform operators who to secure and maintain the security of the OPNFV Platform and its components. - -Contents: - -.. toctree:: - :maxdepth: 2 - - introduction - compute - network - contribution - audit - diff --git a/docs/development/opnfvsecguide/introduction.rst b/docs/development/opnfvsecguide/introduction.rst deleted file mode 100644 index ad80831..0000000 --- a/docs/development/opnfvsecguide/introduction.rst +++ /dev/null @@ -1,15 +0,0 @@ -Introduction ---------------- - -The OPNFV Security Guide is the collaborative work of many individuals, -involved in both the OPNFV Security Group and the wider OPNFV community. - -The purpose of this guide is to provide the best practice security guidelines for -deploying the OPNFV platfornm. It is a living document that is updated as -new changes are merged into it's repository. - -.. toctree:: - :maxdepth: 2 - - introduction/background - introduction/acknowledgements diff --git a/docs/development/opnfvsecguide/introduction/acknowledgements.rst b/docs/development/opnfvsecguide/introduction/acknowledgements.rst deleted file mode 100644 index 60c687d..0000000 --- a/docs/development/opnfvsecguide/introduction/acknowledgements.rst +++ /dev/null @@ -1,3 +0,0 @@ -Acknowledgements ----------------- - diff --git a/docs/development/opnfvsecguide/introduction/background.rst b/docs/development/opnfvsecguide/introduction/background.rst deleted file mode 100644 index bd7e44d..0000000 --- a/docs/development/opnfvsecguide/introduction/background.rst +++ /dev/null @@ -1,38 +0,0 @@ -Background ----------- - -Pre-virtualization security protection was largely centered on the network. -Malicious attacks from hostile machines, would seek to exploit network based -operating systems and applications, with the goal of compromising their -target node. - -Physical security had always been a much simpler business, with most focus on -the secure access of the data center hardware. -In-turn security was built up in layers (defense in depth) where machines -would be -daisy chained with network cables via security appliances to provide -controlled segmentation and isolation. -This form of security was built upon the principle of an 'air gap' -being present, -whereby machines were separate physical units, joined largely by the -network stack. - -With the advent of virtualization (namely the hypervisor), new attack -vectors have -surfaced as the 'air-gap' is no longer key design aspect for security. -Further to this elements orchestation nodes and network controllers -lead to an even wider attack surface: - -* Guests breaking isolation of the hypervisor. - -* Unauthorized access and control of supporting orchestration nodes. - -* Unauthorized access and control of supporting overlay network control systems. - -The hypervisor and the overlay network have now become the 'Achilles heel' -whereby all tenant data isolation is enforced within the hypervisor and its -abstraction -of hardware and the virtualized overlay network. - -This guide has been formulated, in order to assist users of the OPNFV platform -in securing an Telco NFV / SDN environment. diff --git a/docs/development/opnfvsecguide/network.rst b/docs/development/opnfvsecguide/network.rst deleted file mode 100644 index b174479..0000000 --- a/docs/development/opnfvsecguide/network.rst +++ /dev/null @@ -1,8 +0,0 @@ -Network Security ----------------- - - -.. toctree:: - :maxdepth: 2 - - network/neutron diff --git a/docs/development/opnfvsecguide/network/neutron.rst b/docs/development/opnfvsecguide/network/neutron.rst deleted file mode 100644 index e7ca060..0000000 --- a/docs/development/opnfvsecguide/network/neutron.rst +++ /dev/null @@ -1,2 +0,0 @@ -Neutron Security ----------------- diff --git a/docs/development/scenario/featurematrix.rst b/docs/development/scenario/featurematrix.rst deleted file mode 100644 index 2d00a40..0000000 --- a/docs/development/scenario/featurematrix.rst +++ /dev/null @@ -1,39 +0,0 @@ -Each scenario provides a set of platform capabilities and features that it supports. It is -possible to identify which features are provided by reviewing the scenario name, however -not all features and capabilities are discernible from the name itself. - -Brahmaputra feature support matrix -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following table provides an overview of the available scenarios and supported features -in the Brahmaputra release of OPNFV. - -.. image:: ../images/brahmaputrafeaturematrix.jpg - :alt: OPNFV Brahmaputra Feature Matrix - -The table above provides an overview of which scenarios will support certain feature capabilities. -The table does not indicate if the feature or scenario has limitations. Refer to the -`Configuration Guide <http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/configguide/configoptions.html#opnfv-scenarios>`_ -for details on the state of each scenario and further information. - -Feature development in the Brahmaputra release often consisted of the development of specific -requirements and the further integration and validation of those requirements. This results in some -features only being supported on the platform when a specific scenario, providing the -capabilities necessary to run the feature, is deployed. - -Scenario Naming -^^^^^^^^^^^^^^^ - -In OPNFV, scenarios are identified by short scenario names. These names follow a scheme that -identifies the key components and behaviours of the scenario, the rules for scenario naming are as follows: - - os-[controller]-[feature]-[mode]-[option] - -For example: *os-nosdn-kvm-noha* provides an OpenStack based deployment using neutron including -the OPNFV enhanced KVM hypervisor. - -The [feature] tag in the scenario name describes the main feature provided by the scenario. -This scenario may also provide support for features, such as advanced fault management, which are -not apparent in the scenario name. -The following section describes the features available in each scenario. - diff --git a/docs/development/scenario/scenariointro.rst b/docs/development/scenario/scenariointro.rst deleted file mode 100644 index dd80843..0000000 --- a/docs/development/scenario/scenariointro.rst +++ /dev/null @@ -1,13 +0,0 @@ -OPNFV Scenarios ---------------- - -The OPNFV project provides an integration and deployment environment for a variety of components -that can make up a virtualisation platform. OPNFV identifies these variations on the composition of -the platform as scenarios. - -A scenario in OPNFV can be defined as "a deployment of a specific set of platform components". The -composition of a scenario may include specific SDN controller technologies, specific accelerate -switching technologies, or even specific configurations of components to achieve targeted platform -capabilities. Each scenario behaves differetly and it is important to understand the behaviour you -want in order to target the specific scenario you wish to deploy prior to working with the -OPNFV platform. diff --git a/docs/development/scenario/scenariomatrix.rst b/docs/development/scenario/scenariomatrix.rst deleted file mode 100644 index 64e1150..0000000 --- a/docs/development/scenario/scenariomatrix.rst +++ /dev/null @@ -1,100 +0,0 @@ -Scenarios are implemented as deployable compositions through integration with an installation tool. -OPNFV supports multiple installation tools and for any given release not all tools will support all -scenarios. While our target is to establish parity across the installation tools to ensure they -can provide all scenarios, the practical challenge of achieving that goal for any given feature and -release results in some disparity. - -Brahmaputra scenario overeview -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following table provides an overview of the installation tools and available scenario's -in the Brahmaputra release of OPNFV. - -.. image:: ../images/brahmaputrascenariomatrix.jpg - :alt: OPNFV Brahmaputra Scenario Matrix - -Scenario status is indicated by a weather pattern icon. All scenarios listed with -a weather pattern are possible to deploy and run in your environment or a Pharos lab, -however they may have known limitations or issues as indicated by the icon. - -Weather pattern icon legend: - -+---------------------------------------------+----------------------------------------------------------+ -| Weather Icon | Scenario Status | -+=============================================+==========================================================+ -| .. image:: ../images/weather-clear.jpg | Stable, no known issues | -+---------------------------------------------+----------------------------------------------------------+ -| .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations | -+---------------------------------------------+----------------------------------------------------------+ -| .. image:: ../images/weather-overcast.jpg | Deployable, stability or feature limitations | -+---------------------------------------------+----------------------------------------------------------+ -| .. image:: ../images/weather-dash.jpg | Not deployed with this installer | -+---------------------------------------------+----------------------------------------------------------+ - -Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised -and updates will be made on the stable/brahmaputra branch. While we intend that all Brahmaputra -scenarios should be stable it is worth checking regularly to see the current status. Due to -our dependency on upstream communities and code some issues may not be resolved prior to the C release. - -Scenario Naming -^^^^^^^^^^^^^^^ - -In OPNFV scenarios are identified by short scenario names, these names follow a scheme that -identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows: - - os-[controller]-[feature]-[mode]-[option] - -Details of the fields are - * os: mandatory - - * Refers to the platform type used - * possible value: os (OpenStack) - -* [controller]: mandatory - - * Refers to the SDN controller integrated in the platform - * example values: nosdn, ocl, odl, onos - - * [feature]: mandatory - - * Refers to the feature projects supported by the scenario - * example values: nofeature, kvm, ovs, sfc - - * [mode]: mandatory - - * Refers to the deployment type, which may include for instance high availability - * possible values: ha, noha - - * [option]: optional - - * Used for the scenarios those do not fit into naming scheme. - * The optional field in the short scenario name should not be included if there is no optional scenario. - -Some examples of supported scenario names are: - - * os-nosdn-kvm-noha - - * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor - - * os-onos-nofeature-ha - - * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller - - * os-odl_l2-sfc - - * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features - -Installing your scenario -^^^^^^^^^^^^^^^^^^^^^^^^ - -There are two main methods of deploying your target scenario, one method is to follow this guide which will -walk you through the process of deploying to your hardware using scripts or ISO images, the other method is -to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master. - -For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed -virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing -virtual deployments can be found in the installer specific installation instructions. - -To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide. -<http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html>`_ - diff --git a/docs/development/scenario/scenariovalidation.rst b/docs/development/scenario/scenariovalidation.rst deleted file mode 100644 index e69de29..0000000 --- a/docs/development/scenario/scenariovalidation.rst +++ /dev/null |