+++ /dev/null
-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.
-
+++ /dev/null
-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.
+++ /dev/null
-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>`_
-
OPNFV Projects
==============
-Apex
-----
-
-* :doc:`Apex Overview <apex:index>`
-* :doc:`Apex Installation instructions <apex:release/installation/index>`
-
-
Availability
------------
* :doc:`Availability overview <availability:index>`
* :doc:`High Availability Requirement Analysis in OPNFV <availability:development/overview/index>`
-
Barometer
---------
* :doc:`Barometer User Guide <barometer:release/userguide/index>`
* :doc:`Barometer Design Guide <barometer:development/design/index>`
-Clover
-------
-
-* :doc:`Clover Overview <clover:index>`
-
-Doctor
-------
-
-* :doc:`Doctor overview <doctor:index>`
-* :doc:`Doctor Requirements <doctor:development/requirements/index>`
-* :doc:`Doctor Config Guide <doctor:release/configguide/index>`
-* :doc:`Doctor User Guide <doctor:release/userguide/index>`
-* :doc:`Doctor Design Guide <doctor:development/design/index>`
-* :doc:`OpenStack NOVA API for marking host down <doctor:development/manuals/index>`
-
Edgecloud
---------
* :doc:`Edgecloud Overview <edgecloud:index>`
* :doc:`Edgecloud Requirements <edgecloud:development/requirements/index>`
-
-IPV6
-----
-
-* :doc:`IPV6 Overview <ipv6:index>`
-* :doc:`IPV6 Installation Guide <ipv6:release/installation/index>`
-* :doc:`IPV6 Config Guide <ipv6:release/configguide/index>`
-* :doc:`IPV6 User Guide <ipv6:release/userguide/index>`
-
-SFC
----
-
-* :doc:`SFC Overview <sfc:index>`
-* :doc:`SFC Requirements <sfc:development/requirements/index>`
-* :doc:`SFC Config Guide <sfc:release/configguide/index>`
-* :doc:`SFC User Guide <sfc:release/userguide/index>`
-* :doc:`SFC Devlopment Guide <sfc:development/design/index>`
documentation-guide
include-documentation
- local-build-transition
addendum
.. SPDX-License-Identifier: CC-BY-4.0
Anuket Documentation
-===================
+====================
The Anuket project facilitates the development and evolution
of cloud components across various open source ecosystems.
how-to-use-docs/index
Found a typo or any other feedback? Send an email to users@opnfv.org or
-talk to us on IRC_.
+talk to us on Slack_.
-.. _IRC: https://webchat.freenode.net/?channels=%23opnfv
+.. _Slack: https://anuketworkspace.slack.com/
There is no need to "install" the Anuket Reference Specifications! You can view them here:
.. * :doc:`Anuket Reference Specifications <cntt-cntt:/index>`
+
* `Anuket Reference Specifications <https://cntt.readthedocs.io/en/stable-kali/index.html>`_
.. toctree::
:maxdepth: 2
- ./abstract
./dev-guide
.. toctree::
:maxdepth: 2
- ./abstract
./overview
whitelist_externals = echo
[testenv:docs-linkcheck]
-deps = -r{toxinidir}/etc/requirements.txt
-commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/linkcheck
\ No newline at end of file
+deps = -r{toxinidir}/docs/requirements.txt
+commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/linkcheck