aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorroot <juan.vidal.allende@ericsson.com>2017-03-30 09:42:19 +0000
committerroot <juan.vidal.allende@ericsson.com>2017-03-30 13:03:12 +0000
commite61239dbb4f96bb4b798cd3c6e6d6c953d4fcee4 (patch)
tree39374f192a83aaa7c19c29b6e6ba2c0afd5e90ba
parent89b68dcce2e79251e38e6231a3556b1bdc5fea79 (diff)
Remove references to older releases on documentation
- Rename all Brahmaputra/Colorado links to Danube - Bumped OvS version from 2.5.90 to 2.6.1 - Bumped ODL version from Boron to Boron SR2 - Changed release date Change-Id: I4286cbd074b377b4b33e25f33646bb05075f10f5 Signed-off-by: Juan Vidal <juan.vidal.allende@ericsson.com>
-rw-r--r--docs/development/design/architecture.rst6
-rw-r--r--docs/development/design/requirements.rst8
-rw-r--r--docs/development/design/usecases.rst15
-rw-r--r--docs/release/configguide/feature.configuration.rst16
-rw-r--r--docs/release/release-notes/releasenotes.rst4
-rw-r--r--docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst19
-rw-r--r--docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst19
7 files changed, 53 insertions, 34 deletions
diff --git a/docs/development/design/architecture.rst b/docs/development/design/architecture.rst
index 679bb2f9..98520ecf 100644
--- a/docs/development/design/architecture.rst
+++ b/docs/development/design/architecture.rst
@@ -5,7 +5,7 @@ Architecture
------------
This section describes the architectural approach to incorporating the upstream
-OpenDaylight (ODL) SFC project into the OPNFV Colorado platform.
+OpenDaylight (ODL) SFC project into the OPNFV Danube platform.
Service Functions
+++++++++++++++++
@@ -97,7 +97,7 @@ sequence diagram details the interactions with the VNF Mgr:
OPNFV SFC Network Topology
++++++++++++++++++++++++++
-The following image details the Network Topology used in OPNFV Colorado SFC:
+The following image details the Network Topology used in OPNFV Danube SFC:
.. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg
@@ -113,7 +113,7 @@ bridge. There is work ongoing in the upstream OVS community to implemement NSH
encapsulation. To get around the way OpenStack handles VXLAN tunnels, the OVS
work will also include the ability to encapsulate/decapsulate VXLAN tunnels from
OpenFlow rules, instead of relying on the Vtep ports. The ongoing upstream OVS
-work will not be finished by the time OPNFV Colorado is released, so
+work will not be finished by the time OPNFV Danube is released, so
a work-around has been created. This work-around will use a private branch of
OVS that has a preliminary version of NSH implemented.
diff --git a/docs/development/design/requirements.rst b/docs/development/design/requirements.rst
index 1c15a9b9..6d35d946 100644
--- a/docs/development/design/requirements.rst
+++ b/docs/development/design/requirements.rst
@@ -16,15 +16,15 @@ in an OPNFV environment.
Detailed Requirements
+++++++++++++++++++++
-These are the Colorado specific requirements:
+These are the Danube specific requirements:
1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE.
2 The version of OVS used must support NSH.
-3 The SF VM life cycle will be managed by the Tacker VNF Mgr.
+3 The SF VM life cycle will be managed by the Tacker VNF Manager.
-4 The supported classifiers will be either ODL Netvirt or ODL GBP.
+4 The supported classifier is OpenDaylight NetVirt.
5 ODL will be the OpenStack Neutron backend and will handle all networking
on the compute nodes.
@@ -32,7 +32,7 @@ These are the Colorado specific requirements:
Long Term Requirements
++++++++++++++++++++++
-These requirements are out of the scope of the Colorado release.
+These requirements are out of the scope of the Danube release.
1 Dynamic movement of SFs across multiple Compute nodes.
diff --git a/docs/development/design/usecases.rst b/docs/development/design/usecases.rst
index 23e94417..cc20ecea 100644
--- a/docs/development/design/usecases.rst
+++ b/docs/development/design/usecases.rst
@@ -4,13 +4,24 @@
Use Cases
---------
-This section outlines the Colorado use cases driving the initial OPNFV
+This section outlines the Danube use cases driving the initial OPNFV
SFC implementation.
-The use cases targeted in the OPNFV SFC Colorado release focus on creating
+Use Case 1 - Two chains
+***********************
+
+This use case is targeted on creating
simple Service Chains using Firewall Service Functions. As can be seen in the
following diagram, 2 service chains are created, each through a different
Service Function Firewall. Service Chain 1 will block HTTP, while Service
Chain 2 will block SSH.
.. image:: ./images/OPNFV_SFC_Brahmaputra_UseCase.jpg
+
+Use Case 2 - One chain traverses two service functions
+******************************************************
+
+This use case creates two service functions, and a chain that makes the traffic
+flow through both of them. More information is available in OPNFV-SFC wiki:
+
+https://wiki.opnfv.org/display/sfc/Functest+SFC-ODL+-+Test+2
diff --git a/docs/release/configguide/feature.configuration.rst b/docs/release/configguide/feature.configuration.rst
index f5502082..8bd39436 100644
--- a/docs/release/configguide/feature.configuration.rst
+++ b/docs/release/configguide/feature.configuration.rst
@@ -12,9 +12,9 @@ SFC feature desciription
For details of the scenarios and their provided capabilities refer to
the scenario description documents:
-- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html
+- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-ha/index.html
-- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html
+- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-noha/index.html
The SFC feature enables creation of Service Fuction Chains - an ordered list
@@ -68,7 +68,7 @@ Pre-configuration activites - Preparing the host to install Fuel by script
.. instructions applicable to the deploy tool used in the scenario.
Before starting the installation of the SFC scenarios some preparation of the
-machine that will host the Colorado Fuel cluster must be done.
+machine that will host the Danube Fuel cluster must be done.
Installation of required packages
---------------------------------
@@ -99,17 +99,17 @@ CI is deploying the scenario.
First of all the opnfv-fuel repository needs to be cloned:
::
- git clone -b 'stable/colorado' ssh://<user>@gerrit.opnfv.org:29418/fuel
+ git clone -b 'stable/danube' ssh://<user>@gerrit.opnfv.org:29418/fuel
-This command copies the whole colorado branch of repository fuel.
+This command copies the whole danube branch of repository fuel.
Now download the appropriate OPNFV Fuel ISO into an appropriate folder:
::
- wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso
+ wget http://artifacts.opnfv.org/fuel/danube/opnfv-danube.1.0.iso
The exact name of the ISO image may change.
-Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO.
+Check https://www.opnfv.org/opnfv-danube-fuel-users to get the latest ISO.
Simplified scenario deployment procedure using Fuel
===================================================
@@ -242,7 +242,7 @@ Openvswitch are not provided install them by:
If plugins are installed and you want to update them use --force flag.
-Note that One may inject other - Colorado compatible - plugins to the Fuel
+Note that One may inject other - Danube compatible - plugins to the Fuel
Master host using the command scp:
scp <plugin>.rpm root@10.20.0.2:<plugin>.rpm
diff --git a/docs/release/release-notes/releasenotes.rst b/docs/release/release-notes/releasenotes.rst
index 3e37b6d7..f73e6672 100644
--- a/docs/release/release-notes/releasenotes.rst
+++ b/docs/release/release-notes/releasenotes.rst
@@ -55,7 +55,7 @@ Release Data
| **Release designation** | Danube base release |
| | |
+--------------------------------------+--------------------------------------+
-| **Release date** | March 27 2017 |
+| **Release date** | March 31 2017 |
| | |
+--------------------------------------+--------------------------------------+
| **Purpose of the delivery** | Add two new test cases and improve |
@@ -86,7 +86,7 @@ the following documentation:
- `User Guide <http://artifacts.opnfv.org/sfc/danube/docs/userguide/index.html>`_
-- `Installation Instructions <http://artifacts.opnfv.org/sfc/colorado/docs/installationprocedure/index.html>`_
+- `Installation Instructions <http://artifacts.opnfv.org/sfc/danube/docs/installationprocedure/index.html>`_
- Release notes (This document)
diff --git a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
index cb918002..881ca967 100644
--- a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
+++ b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst
@@ -5,9 +5,10 @@
Introduction
============
.. In this section explain the purpose of the scenario and the types of capabilities provided
+
The os-odl_l2-sfc-ha is intended to be used to install the OPNFV SFC project in a standard
OPNFV High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC project
-into the OPNFV environment. The OPNFV SFC Colorado release uses the OpenDaylight Boron release.
+into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight Boron SR2 release.
Scenario components and composition
===================================
@@ -72,8 +73,10 @@ 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.
-This scenario is not working in Colorado 1.0 with the Fuel installer, since Tacker is not
-registered in the HA Proxy and calls to Tacker fail. This will be fixed in Colorado 2.0.
+
+The *client* virtual machine needs to be located in a compute node where at least
+one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight,
+Boron, which only installs the traffic classifier in the compute nodes where the SFs are.
Specific version of OVS
-----------------------
@@ -81,8 +84,8 @@ Specific version of OVS
SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining
encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still
has not been officially merged. Previously, SFC used NSH from a branched version of OVS
-based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron release, SFC was
-changed to use a newer, branched version of OVS based on 2.5.90, called the "Yi Yang
+based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron SR2 release, SFC was
+changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang
Patch".
The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer
@@ -98,7 +101,7 @@ NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunne
are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has
been created to address this issue, which can be found here:
-http://artifacts.opnfv.org/sfc/brahmaputra/docs/design/architecture.html#ovs-nsh-patch-workaround
+http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround
In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH,
which will obviate this work around.
@@ -112,7 +115,7 @@ https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
-For more information on the OPNFV Colorado release, please visit:
+For more information on the OPNFV Danube release, please visit:
-http://www.opnfv.org/colorado
+http://www.opnfv.org/danube
diff --git a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
index b5d41044..74d386b0 100644
--- a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
+++ b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst
@@ -5,10 +5,11 @@
Introduction
============
.. In this section explain the purpose of the scenario and the types of capabilities provided
+
The os-odl_l2-sfc-noha is intended to be used to install the OPNFV SFC project in a standard
OPNFV Non-High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC
-project into the OPNFV environment. The OPNFV SFC Colorado release uses the OpenDaylight
-Boron release.
+project into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight
+Boron SR2 release.
Scenario components and composition
===================================
@@ -75,14 +76,18 @@ Limitations, Issues and Workarounds
.. faults or bugs. If the system design only provide some expected functionality then provide
.. some insight at this point.
+The *client* virtual machine needs to be located in a compute node where at least
+one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight,
+Boron, which only installs the traffic classifier in the compute nodes where the SFs are.
+
Specific version of OVS
-----------------------
SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining
encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still
has not been officially merged. Previously, SFC used NSH from a branched version of OVS
-based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron release, SFC was
-changed to use a newer, branched version of OVS based on 2.5.90, called the "Yi Yang
+based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron SR2 release, SFC was
+changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang
Patch".
The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer
@@ -98,7 +103,7 @@ NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunne
are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has
been created to address this issue, which can be found here:
-http://artifacts.opnfv.org/sfc/brahmaputra/docs/design/architecture.html#ovs-nsh-patch-workaround
+http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround
In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH,
which will obviate this work around.
@@ -112,7 +117,7 @@ https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
-For more information on the OPNFV Colorado release, please visit:
+For more information on the OPNFV Danube release, please visit:
-http://www.opnfv.org/colorado
+http://www.opnfv.org/danube