summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/development/overview/index.rst490
-rw-r--r--docs/release/installation/index.rst29
-rw-r--r--docs/release/release-notes/release-notes.rst61
-rw-r--r--docs/release/scenarios/os-odl-bgpvpn/scenario.description.rst33
4 files changed, 302 insertions, 311 deletions
diff --git a/docs/development/overview/index.rst b/docs/development/overview/index.rst
index 021ace9..4511e0a 100644
--- a/docs/development/overview/index.rst
+++ b/docs/development/overview/index.rst
@@ -1,20 +1,14 @@
-.. _sdnvpn-overview:
-
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) Tim Irnich, (tim.irnich@ericsson.com) and others
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) OPNFV, Ericsson AB and others.
=======
SDN VPN
=======
-A high-level description of the scenarios is provided in this section.
-For details of the scenarios and their provided capabilities refer to
-the scenario description document:
-http://artifacts.opnfv.org/danube/sdnpvn/scenarios/os-odl_l2-bgpvpn/index.html
-
The BGPVPN feature enables creation of BGP VPNs on the Neutron API according to the OpenStack
-BGPVPN blueprint at https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn.
+BGPVPN blueprint at `Neutron Extension for BGP Based VPN <https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn>`_.
+
In a nutshell, the blueprint defines a BGPVPN object and a number of ways
how to associate it with the existing Neutron object model, as well as a unique
definition of the related semantics. The BGPVPN framework supports a backend
@@ -26,238 +20,244 @@ implementation through the ODL NetVirt project.
SDNVPN Testing Suite
====================
-An overview of the SDNVPN Test is depicted here. More details for each test case are provided:
-https://wiki.opnfv.org/display/sdnvpn/SDNVPN+Testing
-
- BGPVPN Tempest test cases
- - Create BGPVPN passes
- - Create BGPVPN as non-admin fails
- - Delete BGPVPN as non-admin fails
- - Show BGPVPN as non-owner fails
- - List BGPVPNs as non-owner fails
- - Show network associated BGPVPNs as non-owner fails
- - List network associated BGPVPNs as non-owner fails
- - Associate/Deassociate a network to a BGPVPN resource passes
- - Update route targets on a BGPVPN passes
- - Update route targets on a BGPVPN as non-admin fails
- - Reject the creation of BGPVPN with invalid route targets passes
- - Reject the update of BGPVPN with invalid route targets passes
- - Reject the association on an invalid network to a BGPVPN passes
- - Reject the diassociation on an invalid network to a BGPVPN passes
- - Associate/Deassociate a router to a BGPVPN resource passes
- - Attach the subnet of an associated network to an associated router of the same BGVPN passes
-
-
-
- Functest scenario specific tests:
-
- Test Case 1 - VPN provides connectivity between subnets, using network association
- Name: VPN connecting Neutron networks and subnets
- Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1
- Moreover all ports have 10.10.10/24 addresses (this subnet is denoted SN1 in the following)
- Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
- Moreover all ports have 10.10.11/24 addresses (this subnet is denoted SN2 in the following)
-
- Test execution:
- Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
- Associate SN1 to VPN1
- Ping from VM1 to VM2 should work
- Ping from VM1 to VM3 should work
- Ping from VM1 to VM4 should not work
- Associate SN2 to VPN1
- Ping from VM4 to VM5 should work
- Ping from VM1 to VM4 should not work (disabled until isolation fixed upstream)
- Ping from VM1 to VM5 should not work (disabled until isolation fixed upstream)
- Change VPN 1 so that iRT=eRT
- Ping from VM1 to VM4 should work
- Ping from VM1 to VM5 should work
-
- Test Case 2 - tenant separation
- Name: Using VPNs for tenant separation
- Description: Using VPNs to isolate tenants so that overlapping IP address ranges can be used
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1.
- VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24
- VM1: 10.10.10.11, running an HTTP server which returns "I am VM1" for any HTTP request
- (or something else than an HTTP server)
- VM2: 10.10.10.12, running an HTTP server which returns "I am VM2" for any HTTP request
- VM3 has an IP address in a subnet SN2 with range 10.10.11/24
- VM3: 10.10.11.13, running an HTTP server which returns "I am VM3" for any HTTP request
- Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
- VM4 has an address in a subnet SN1b with range 10.10.10/24
- VM4: 10.10.10.12 (the same as VM2), running an HTTP server which returns "I am VM4" for any HTTP request
- VM5 has an address in a subnet SN2b with range 10.10.11/24
- VM5: 10.10.11.13 (the same as VM3), running an HTTP server which returns "I am VM5" for any HTTP request
-
- Test execution:
- Create VPN 1 with iRT=eRT=RT1 and associate N1 to it
- HTTP from VM1 to VM2 and VM3 should work
- It returns "I am VM2" and "I am VM3" respectively
- HTTP from VM1 to VM4 and VM5 should not work
- It never returns "I am VM4" or "I am VM5"
- Create VPN2 with iRT=eRT=RT2 and associate N2 to it
- HTTP from VM4 to VM5 should work
- It returns "I am VM5"
- HTTP from VM4 to VM1 and VM3 should not work
- It never returns "I am VM1" or "I am VM3"
-
-
- Test Case 3 - Data Center Gateway integration
- Name: Data Center Gateway integration
- Description: Investigate the peering functionality of BGP protocol,
- using a Zrpcd/Quagga router and OpenDaylight Controller
-
- Test setup procedure:
- Search in the pool of nodes and find one Compute node and one Controller nodes, that have OpenDaylight controller running
- Start an instance using ubuntu-16.04-server-cloudimg-amd64-disk1.img image and in it run the Quagga setup script
- Start bgp router in the Controller node, using odl:configure-bgp
-
- Test execution:
- Set up a Quagga instance in a nova compute node
- Start a BGP router with OpenDaylight in a controller node
- Add the Quagga running in the instance as a neighbor
- Check that bgpd is running
- Verify that the OpenDaylight and gateway Quagga peer each other
- Start an instance in a second nova compute node and connect it with a new network, (Network 3-3).
- Create a bgpvpn (include parameters route-distinguisher and route-targets) and associate it with the network created
- Define the same route-distinguisher and route-targets on the simulated quagga side
- Check that the routes from the Network 3-3 are advertised towards simulated Quagga VM
-
- Test Case 4 - VPN provides connectivity between subnets using router association
- Functest: variant of Test Case 1.
- Set up a Router R1 with one connected network/subnet N1/S1.
- Set up a second network N2.
- Create VPN1 and associate Router R1 and Network N2 to it.
- Hosts from N2 should be able to reach hosts in N1.
-
- Name: VPN connecting Neutron networks and subnets using router association
- Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
-
- Test setup procedure:
- Set up VM1 and VM2 on Node1 and VM3 on Node2,
- All VMs have ports in the same Neutron Network N1 and 10.10.10/24 addresses
- (this subnet is denoted SN1 in the following).
- N1/SN1 are connected to router R1.
- Set up VM4 on Node1 and VM5 on Node2,
- Both VMs have ports in Neutron Network N2 and having 10.10.11/24 addresses
- (this subnet is denoted SN2 in the following)
-
- Test execution:
- Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
- Associate R1 to VPN1
- Ping from VM1 to VM2 should work
- Ping from VM1 to VM3 should work
- Ping from VM1 to VM4 should not work
- Associate SN2 to VPN1
- Ping from VM4 to VM5 should work
- Ping from VM1 to VM4 should not work
- Ping from VM1 to VM5 should not work
- Change VPN1 so that iRT=eRT
- Ping from VM1 to VM4 should work
- Ping from VM1 to VM5 should work
-
- Test Case 7 - Network associate a subnet with a router attached to a VPN and
- verify floating IP functionality (disabled, because of ODL Bug 6962)
-
- A test for https://bugs.opendaylight.org/show_bug.cgi?id=6962
-
- Setup procedure:
- Create VM1 in a subnet with a router attached.
- Create VM2 in a different subnet with another router attached.
- Network associate them to a VPN with iRT=eRT
- Ping from VM1 to VM2 should work
- Assign a floating IP to VM1
- Pinging the floating IP should work
-
- Test Case 8 - Router associate a subnet with a router attached to a VPN and
- verify floating IP functionality
-
- Setup procedure:
- Create VM1 in a subnet with a router which is connected with the gateway
- Create VM2 in a different subnet without a router attached.
- Assoc the two networks in a VPN iRT=eRT
- One with router assoc, other with net assoc
- Try to ping from one VM to the other
- Assign a floating IP to the VM in the router assoc network
- Ping it
-
- Test Case 9 - Check fail mode in OVS br-int interfaces
- This testcase checks if the fail mode is always “secure”.
- To accomplish it, a check is performed on all OVS br-int interfaces, for all OpenStack nodes.
- The testcase is considered as successful if all OVS br-int interfaces have fail_mode=secure
-
-
- Test Case 10 - Check the communication between a group of VMs
- This testcase investigates if communication between a group of VMs is interrupted upon deletion
- and creation of VMs inside this group.
-
- Test case flow:
- Create 3 VMs: VM_1 on compute 1, VM_2 on compute 1, VM_3 on compute 2.
- All VMs ping each other.
- VM_2 is deleted.
- Traffic is still flying between VM_ 1 and VM_3.
- A new VM, VM_ 4 is added to compute 1.
- Traffic is not interrupted and VM_4 can be reached as well.
-
-
- Testcase 11: test Opendaylight resync and group_add_mod feature mechanisms
- This is testcase to test Opendaylight resync and group_add_mod feature functionalities
-
- Sub-testcase 11-1:
- Create and start 2 VMs, connected to a common Network.
- New groups should appear in OVS dump
- OVS disconnects and the VMs and the networks are cleaned.
- The new groups are still in the OVS dump,
- cause OVS is not connected anymore, so it is not notified that the groups are deleted
- OVS re-connects.
- The new groups should be deleted, as Opendaylight has to resync the groups totally and
- should remove the groups since VMS are deleted.
-
- Sub-testcase 11-2:
- Create and start 2 VMs, connected to a common Network.
- New groups should appear in OVS dump
- OVS disconnects.
- The new groups are still in the OVS dump, cause OVS is not connected anymore,
- so it is not notified that the groups are deleted
- OVS re-connects.
- The new groups should be still there, as the topology remains. Opendaylight Carbon's
- group_add_mod mechanism should handle the already existing group.
- OVS re-connects.
- The new groups should be still there, as the topology remains.
- Opendaylight Carbon’ group_add_mod mechanism should handle the already existing group.
-
- Testcase 12: Test Resync mechanism between Opendaylight and OVS
- This is the testcase to validate flows and groups are programmed correctly
- after resync which is triggered by OVS del-controller/set-controller commands
- and adding/remove iptables drop rule on OF port 6653.
-
- Sub-testcase 12-1:
- Create and start 2 VMs, connected to a common Network
- New flows and groups were added to OVS
- Reconnect the OVS by running del-ontroller and set-controller commands
- The flows and groups are still intact and none of the flows/groups
- are removed
- Reconnect the OVS by adding ip tables drop rule and then remove it
- The flows and groups are still intact and none of the flows/groups
- are removed
-
- Testcase 13: Test ECMP (Equal-cost multi-path routing) for the extra route
- This testcase validates spraying behavior in OvS when an extra route is
- configured such that it can be reached from two nova VMs in the
- same network.
-
- Setup procedure:
- Create and start VM1 and VM2 configured with sub interface set to same ip
- address in both VMs, connected to a common network/router.
- Update the VM1 and VM2's Neutron ports with allowed address pairs for sub
- interface ip/mac addresses.
- Create BGPVPN with two route distinguishers.
- Associate router with BGPVPN.
- Update the router with above sub-interface ip address with nexthops set to
- VMs ip addresses.
- Create VM3 and connected to the same network.
- Ping sub-interface IP address from VM3.
+An overview of the SDNVPN Test is depicted here. A more detailed description of each test case can
+be found at `SDNVPN Testing <https://wiki.opnfv.org/display/sdnvpn/SDNVPN+Testing>`_.
+
+BGPVPN Tempest test cases
+"""""""""""""""""""""""""
+
+#. Create BGPVPN passes
+#. Create BGPVPN as non-admin fails
+#. Delete BGPVPN as non-admin fails
+#. Show BGPVPN as non-owner fails
+#. List BGPVPNs as non-owner fails
+#. Show network associated BGPVPNs as non-owner fails
+#. List network associated BGPVPNs as non-owner fails
+#. Associate/Deassociate a network to a BGPVPN resource passes
+#. Update route targets on a BGPVPN passes
+#. Update route targets on a BGPVPN as non-admin fails
+#. Reject the creation of BGPVPN with invalid route targets passes
+#. Reject the update of BGPVPN with invalid route targets passes
+#. Reject the association on an invalid network to a BGPVPN passes
+#. Reject the diassociation on an invalid network to a BGPVPN passes
+#. Associate/Deassociate a router to a BGPVPN resource passes
+#. Attach the subnet of an associated network to an associated router of the same BGVPN passes
+
+
+
+Functest scenario specific tests
+""""""""""""""""""""""""""""""""""
+- **Test Case 1**: VPN provides connectivity between subnets, using network association
+
+ Name: VPN connecting Neutron networks and subnets
+ Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
+ Test setup procedure:Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1
+
+ Moreover all ports have 10.10.10/24 addresses (this subnet is denoted SN1 in the following)
+ Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
+ Moreover all ports have 10.10.11/24 addresses (this subnet is denoted SN2 in the following)
+
+ Test execution:
+ * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
+ * Associate SN1 to VPN1
+ * Ping from VM1 to VM2 should work
+ * Ping from VM1 to VM3 should work
+ * Ping from VM1 to VM4 should not work
+ * Associate SN2 to VPN1
+ * Ping from VM4 to VM5 should work
+ * Ping from VM1 to VM4 should not work (disabled until isolation fixed upstream)
+ * Ping from VM1 to VM5 should not work (disabled until isolation fixed upstream)
+ * Change VPN 1 so that iRT=eRT
+ * Ping from VM1 to VM4 should work
+ * Ping from VM1 to VM5 should work
+
+- **Test Case 2**: Tenant separation
+
+ Name: Using VPNs for tenant separation
+ Description: Using VPNs to isolate tenants so that overlapping IP address ranges can be used
+
+ Test setup procedure:
+ * Set up VM1 and VM2 on Node1 and VM3 on Node2, all having ports in the same Neutron Network N1.
+ * VM1 and VM2 have IP addresses in a subnet SN1 with range 10.10.10/24
+ * VM1: 10.10.10.11, running an HTTP server which returns "I am VM1" for any HTTP request (or something else than an HTTP server)
+ * VM2: 10.10.10.12, running an HTTP server which returns "I am VM2" for any HTTP request
+ * VM3 has an IP address in a subnet SN2 with range 10.10.11/24
+ * VM3: 10.10.11.13, running an HTTP server which returns "I am VM3" for any HTTP request
+ * Set up VM4 on Node1 and VM5 on Node2, both having ports in Neutron Network N2
+ * VM4 has an address in a subnet SN1b with range 10.10.10/24
+ * VM4: 10.10.10.12 (the same as VM2), running an HTTP server which returns "I am VM4" for any HTTP request
+ * VM5 has an address in a subnet SN2b with range 10.10.11/24
+ * VM5: 10.10.11.13 (the same as VM3), running an HTTP server which returns "I am VM5" for any HTTP request
+
+ Test execution:
+ * Create VPN 1 with iRT=eRT=RT1 and associate N1 to it
+ * HTTP from VM1 to VM2 and VM3 should work
+ It returns "I am VM2" and "I am VM3" respectively
+ * HTTP from VM1 to VM4 and VM5 should not work
+ It never returns "I am VM4" or "I am VM5"
+ * Create VPN2 with iRT=eRT=RT2 and associate N2 to it
+ * HTTP from VM4 to VM5 should work
+ It returns "I am VM5"
+ * HTTP from VM4 to VM1 and VM3 should not work
+ It never returns "I am VM1" or "I am VM3"
+
+
+- **Test Case 3**: Data Center Gateway integration
+
+ Name: Data Center Gateway integration
+ Description: Investigate the peering functionality of BGP protocol, using a Zrpcd/Quagga router
+ and OpenDaylight Controller
+
+ Test setup procedure:
+ * Search in the pool of nodes and find one Compute node and one Controller nodes, that have OpenDaylight controller running
+ * Start an instance using ubuntu-16.04-server-cloudimg-amd64-disk1.img image and in it run the Quagga setup script
+ * Start bgp router in the Controller node, using odl:configure-bgp
+
+ Test execution:
+ * Set up a Quagga instance in a nova compute node
+ * Start a BGP router with OpenDaylight in a controller node
+ * Add the Quagga running in the instance as a neighbor
+ * Check that bgpd is running
+ * Verify that the OpenDaylight and gateway Quagga peer each other
+ * Start an instance in a second nova compute node and connect it with a new network, (Network 3-3).
+ * Create a bgpvpn (include parameters route-distinguisher and route-targets) and associate it with the network created
+ * Define the same route-distinguisher and route-targets on the simulated quagga side
+ * Check that the routes from the Network 3-3 are advertised towards simulated Quagga VM
+
+- **Test Case 4**: VPN provides connectivity between subnets using router association
+
+ Functest: variant of Test Case 1.
+ * Set up a Router R1 with one connected network/subnet N1/S1.
+ * Set up a second network N2.
+ * Create VPN1 and associate Router R1 and Network N2 to it.
+ * Hosts from N2 should be able to reach hosts in N1.
+
+ Name: VPN connecting Neutron networks and subnets using router association
+ Description: VPNs provide connectivity across Neutron networks and subnets if configured accordingly.
+
+ Test setup procedure:
+ * Set up VM1 and VM2 on Node1 and VM3 on Node2,
+ * All VMs have ports in the same Neutron Network N1 and 10.10.10/24 addresses
+ * (this subnet is denoted SN1 in the following).
+ * N1/SN1 are connected to router R1.
+ * Set up VM4 on Node1 and VM5 on Node2,
+ * Both VMs have ports in Neutron Network N2 and having 10.10.11/24 addresses
+ * (this subnet is denoted SN2 in the following)
+
+ Test execution:
+ * Create VPN1 with eRT<>iRT (so that connected subnets should not reach each other)
+ * Associate R1 to VPN1
+ Ping from VM1 to VM2 should work
+ Ping from VM1 to VM3 should work
+ Ping from VM1 to VM4 should not work
+ * Associate SN2 to VPN1
+ Ping from VM4 to VM5 should work
+ Ping from VM1 to VM4 should not work
+ Ping from VM1 to VM5 should not work
+ * Change VPN1 so that iRT=eRT
+ Ping from VM1 to VM4 should work
+ Ping from VM1 to VM5 should work
+
+- **Test Case 7** - Network associate a subnet with a router attached to a VPN and verify floating IP
+ functionality (disabled, because of ODL Bug 6962)
+
+ A test for https://bugs.opendaylight.org/show_bug.cgi?id=6962
+
+ Setup procedure:
+ * Create VM1 in a subnet with a router attached.
+ * Create VM2 in a different subnet with another router attached.
+ * Network associate them to a VPN with iRT=eRT
+ * Ping from VM1 to VM2 should work
+ * Assign a floating IP to VM1
+ * Pinging the floating IP should work
+
+- **Test Case 8** - Router associate a subnet with a router attached to a VPN and
+ verify floating IP functionality
+
+ Setup procedure:
+ * Create VM1 in a subnet with a router which is connected with the gateway
+ * Create VM2 in a different subnet without a router attached.
+ * Assoc the two networks in a VPN iRT=eRT
+ * One with router assoc, other with net assoc
+ * Try to ping from one VM to the other
+ * Assign a floating IP to the VM in the router assoc network
+ * Ping it
+
+- **Test Case 9** - Check fail mode in OVS br-int interfaces
+
+ This testcase checks if the fail mode is always 'secure'.
+ To accomplish it, a check is performed on all OVS br-int interfaces, for all OpenStack nodes.
+ The testcase is considered as successful if all OVS br-int interfaces have fail_mode=secure
+
+- **Test Case 10** - Check the communication between a group of VMs
+
+ This testcase investigates if communication between a group of VMs is interrupted upon deletion
+ and creation of VMs inside this group.
+
+ Test case flow:
+ * Create 3 VMs: VM_1 on compute 1, VM_2 on compute 1, VM_3 on compute 2.
+ * All VMs ping each other.
+ * VM_2 is deleted.
+ * Traffic is still flying between VM_1 and VM_3.
+ * A new VM, VM_4 is added to compute 1.
+ * Traffic is not interrupted and VM_4 can be reached as well.
+
+
+- **Testcase 11**: test Opendaylight resync and group_add_mod feature mechanisms
+
+ This is testcase to test Opendaylight resync and group_add_mod feature functionalities
+
+ Sub-testcase 11-1:
+ * Create and start 2 VMs, connected to a common Network.
+ New groups should appear in OVS dump
+ * OVS disconnects and the VMs and the networks are cleaned.
+ The new groups are still in the OVS dump,
+ cause OVS is not connected anymore, so it is not notified that the groups are deleted
+ * OVS re-connects.
+ The new groups should be deleted, as Opendaylight has to resync the groups totally and
+ should remove the groups since VMS are deleted.
+
+ Sub-testcase 11-2:
+ * Create and start 2 VMs, connected to a common Network.
+ New groups should appear in OVS dump
+ * OVS disconnects.
+ The new groups are still in the OVS dump, cause OVS is not connected anymore,
+ so it is not notified that the groups are deleted
+ * OVS re-connects.
+ The new groups should be still there, as the topology remains. Opendaylight Carbon's
+ group_add_mod mechanism should handle the already existing group.
+ * OVS re-connects.
+ The new groups should be still there, as the topology remains.
+ Opendaylight Carbon’ group_add_mod mechanism should handle the already existing group.
+
+- **Testcase 12**: Test Resync mechanism between Opendaylight and OVS
+ This is the testcase to validate flows and groups are programmed correctly
+ after resync which is triggered by OVS del-controller/set-controller commands
+ and adding/remove iptables drop rule on OF port 6653.
+
+ Sub-testcase 12-1:
+ * Create and start 2 VMs, connected to a common Network
+ New flows and groups were added to OVS
+ * Reconnect the OVS by running del-ontroller and set-controller commands
+ The flows and groups are still intact and none of the flows/groups
+ are removed
+ * Reconnect the OVS by adding ip tables drop rule and then remove it
+ The flows and groups are still intact and none of the flows/groups
+ are removed
+
+- **Testcase 13**: Test ECMP (Equal-cost multi-path routing) for the extra route
+
+ This testcase validates spraying behavior in OvS when an extra route is
+ configured such that it can be reached from two nova VMs in the
+ same network.
+
+ Setup procedure:
+ * Create and start VM1 and VM2 configured with sub interface set to same ip address in both VMs,
+ connected to a common network/router.
+ * Update the VM1 and VM2's Neutron ports with allowed address pairs for sub interface ip/mac
+ addresses.
+ * Create BGPVPN with two route distinguishers.
+ * Associate router with BGPVPN.
+ * Update the router with above sub-interface ip address with nexthops set to VMs ip addresses.
+ * Create VM3 and connected to the same network.
+ * Ping sub-interface IP address from VM3.
diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst
index 2625ef9..ded6a78 100644
--- a/docs/release/installation/index.rst
+++ b/docs/release/installation/index.rst
@@ -1,8 +1,6 @@
-.. _sdnvpn-installation:
-
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) Tim Irnich, (tim.irnich@ericsson.com) and others
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) OPNFV, Ericsson AB and others.
============================
SDN VPN feature installation
@@ -71,8 +69,8 @@ install the following packages:
fuseiso genisoimage blackbox xterm python-pip \
python-git python-dev python-oslo.config \
python-pip python-dev libffi-dev libxml2-dev \
- libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
- expect curl python-netaddr p7zip-full
+ libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
+ expect curl python-netaddr p7zip-full
sudo pip install GitPython pyyaml netaddr paramiko lxml scp \
python-novaclient python-neutronclient python-glanceclient \
@@ -87,17 +85,14 @@ First of all the opnfv-fuel repository needs to be cloned:
git clone ssh://<user>@gerrit.opnfv.org:29418/fuel
-To check out a specific
-version of OPNFV, checkout the appropriate branch:
+To check out a specific version of OPNFV, checkout the appropriate branch:
::
cd fuel
- git checkout stable/<colorado|danube|euphrates|fraser>
+ git checkout stable/gambia
Now download the corresponding OPNFV Fuel ISO into an appropriate folder from
-the website
-::
- https://www.opnfv.org/software/downloads/release-archives
+the website https://www.opnfv.org/software/downloads/release-archives
Have in mind that the fuel repo version needs to map with the downloaded
artifact. Note: it is also possible to build the Fuel image using the
@@ -226,19 +221,21 @@ Virtual deployment using Apex installer
=======================================
Prerequisites
-^^^^^^^^^^^^^
+-------------
+
For Virtual Apex deployment a host with Centos 7 is needed. This installation
was tested on centos-release-7-2.1511.el7.centos.2.10.x86_64 however any other
Centos 7 version should be fine.
Build and Deploy
-^^^^^^^^^^^^^^^^
-Download the Apex repo from opnfv gerrit and checkout stable/danube:
+----------------
+
+Download the Apex repo from opnfv gerrit and checkout stable/gambia:
::
git clone ssh://<user>@gerrit.opnfv.org:29418/apex
cd apex
- git checkout stable/danube
+ git checkout stable/gambia
In apex/contrib you will find simple_deploy.sh:
::
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst
index 1a3e9a5..54ada98 100644
--- a/docs/release/release-notes/release-notes.rst
+++ b/docs/release/release-notes/release-notes.rst
@@ -3,31 +3,26 @@
.. _-os-odl-bgpvpn-ha:
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
+.. SPDX-License-Identifier: CC-BY-4.0
.. (c) Periyasamy Palanisamy <periyasamy.palanisamy@ericsson.com> and others
=====================
SDN VPN Release Notes
=====================
-License
-=======
-
-This work is licensed under a Creative Commons Attribution 4.0 International
-License. .. http://creativecommons.org/licenses/by/4.0 ..
-(c) Tim Irnich (Ericsson) and others
Abstract
========
-This document comprises the release notes for the SDN VPN feature contained in the Fraser
+This document comprises the release notes for the SDN VPN feature contained in the Gambia
release of OPNFV.
Important notes
===============
-In the Fraser release, SDN VPN only supports ODL as a backend. Make sure to always deploy
-SDN VPN and ODL together. Make use of deployment scenarios including the SDNVPN feature such as os_odl_bgpvpn_{ha|noha}.
+In the Gambia release, SDN VPN only supports ODL as a backend. Make sure to always deploy
+SDN VPN and ODL together. Make use of deployment scenarios including the SDNVPN feature such
+as os_odl_bgpvpn_{ha|noha}.
Summary
=======
@@ -44,13 +39,13 @@ Release Data
| **Project** | sdnvpn |
| | |
+--------------------------------------+-------------------------------------------+
-| **Repo/tag** | opnfv-6.2.0 |
+| **Repo/tag** | opnfv-7.0.0 |
| | |
+--------------------------------------+-------------------------------------------+
-| **Release designation** | Fraser 6.2 |
+| **Release designation** | Gambia 7.0 |
| | |
+--------------------------------------+-------------------------------------------+
-| **Release date** | June 29 2018 |
+| **Release date** | Nov 02 2018 |
| | |
+--------------------------------------+-------------------------------------------+
| **Purpose of the delivery** | New test cases |
@@ -60,12 +55,12 @@ Release Data
Version change
--------------
-Compared to the Euphrates release, new testcases were added to
-functest to guarantee functionality.
+Compared to the Fraser release, functest testcases were enriched to guarantee functionality.
+Also several enhancements were added to improve testing efficiency.
Module version changes
~~~~~~~~~~~~~~~~~~~~~~
-ODL has been upgraded to Nitrogen.
+.. ODL has been upgraded to Nitrogen.
Document changes
~~~~~~~~~~~~~~~~
@@ -96,23 +91,23 @@ Deliverables
Software deliverables
~~~~~~~~~~~~~~~~~~~~~
-- Changes to Apex to enable a BGPVPN deployment and integration of Quagga BGP.
-- Integration of VPN Service functional tests and BGPVPN API tests into Functest framework.
-- Enabling performance tests in Yardstick.
-- Changes to 6Wind Zrpcd to enable integration with Apex.
-- Intra Datacenter ECMP (Equal Cost Multi Pathing) Testcase.
-- OpenDaylight and Open vSwitch Resynchronization Testcase.
-- Improved quality and stability of Testcase runs in CI environment.
-- External BGPVPN scenario added for XCI based deployment for BGPVPN scenarios.
+- Orchestrate BGPVPN with Openstack HEAT templates
+- Verify BGP route exchange with a peer in both directions
+- Support for ECMP load balancing
+- Consolidate image creation in Apex and Fuel
+- Remove the dependency between not running quagga and created flows
+- Delete ODL configuration after each test case run
+- Add BGPVPN scenarios to XCI and enable SDNVPN tests
+- Enable and test ODL clustering for bgpvpn-ha scenario
+
Documentation deliverables
~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Configuration guide
-
-- User guide
-
+- Installation guide
- Release notes (this document)
+- Overview
+- Test scenario description
Known Limitations, Issues and Workarounds
=========================================
@@ -127,12 +122,12 @@ Known issues
Moving to the new NetVirt has caused a regression in which a subnet
cannot be both attached to a Router and Network associated to a VPN.
This has been worked around in the tests and the upstream bug is being
-tracked [0] and [2].
+tracked [0]_ and [2]_.
NAT for a VM which is in a private neutron network does not work. Instances
created in subnets that are connected to the public network via a gateway
should have external connectivity. This does not work and can be worked
-around by assigning a Floating IP to the instance [1].
+around by assigning a Floating IP to the instance [1]_.
Currently we observe non-deterministic failures of individual tests within the
SDNVPN section of the Functest suite, which are not reproducible in the development
@@ -159,6 +154,6 @@ with the exceptions described above.
References
==========
-[0] https://jira.opnfv.org/projects/SDNVPN/issues/SDNVPN-94
-[1] https://jira.opnfv.org/projects/SDNVPN/issues/SDNVPN-99
-[2] https://jira.opendaylight.org/browse/NETVIRT-932
+.. [0] https://jira.opnfv.org/projects/SDNVPN/issues/SDNVPN-94
+.. [1] https://jira.opnfv.org/projects/SDNVPN/issues/SDNVPN-99
+.. [2] https://jira.opendaylight.org/browse/NETVIRT-932 \ No newline at end of file
diff --git a/docs/release/scenarios/os-odl-bgpvpn/scenario.description.rst b/docs/release/scenarios/os-odl-bgpvpn/scenario.description.rst
index 5d6c06d..8d1cb9c 100644
--- a/docs/release/scenarios/os-odl-bgpvpn/scenario.description.rst
+++ b/docs/release/scenarios/os-odl-bgpvpn/scenario.description.rst
@@ -1,5 +1,5 @@
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
+.. SPDX-License-Identifier: CC-BY-4.0
.. (c) Periyasamy Palanisamy <periyasamy.palanisamy@ericsson.com> and others
Introduction
@@ -21,9 +21,8 @@ deployment scenarios, which is derived from the baseline
os-odl-nofeature scenario.
The BGPVPN feature enables creation of BGP VPNs on the Neutron API
-according to the OpenStack BGPVPN blueprint at
-https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn. In a
-nutshell, the blueprint defines a BGPVPN object and a number of ways how
+according to the `OpenStack BGPVPN blueprint <https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn>`_.
+In a nutshell, the blueprint defines a BGPVPN object and a number of ways how
to associate it with the existing Neutron object model, as well as a
unique definition of the related semantics. The BGPVPN framework
supports a backend driver model with currently available drivers for
@@ -72,23 +71,23 @@ Scenario usage overview
Configuring SDNVPN features
---------------------------
-Apex installer has specific procedures to deploy the OPNFV platform so that the SDNVPN feature is enabled.
+Apex installer has specific procedures to deploy the OPNFV platform so that the SDNVPN feature is
+enabled.
-APEX installer configuration
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+APEX installer configuration and BGPVPN deployment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To install the SDNVPN feature using the APEX installer, follow the APEX installation guide
-(https://wiki.opnfv.org/display/apex/Integration+Guide) and activate the SDNVPN feature when prompted (step "# Now execute a deployment")
+To install the SDNVPN feature using the APEX installer, follow the `APEX installation guide <(https://wiki.
+opnfv.org/display/apex/Integration+Guide)>`_ . When prompted activate the SDNVPN feature based on
+openstack configuration:
-For os-odl-bgpvpn-noha deployment:
-----------------------------------
+* For os-odl-bgpvpn-noha deployment:
-python3 deploy.py -v -n ../config/network/network_settings.yaml -d ../config/deploy/os-odl-bgpvpn-noha.yaml --deploy-dir ../build --lib-dir ../lib --image-dir ../.build --virtual-computes 2 --virtual-default-ram 16
+ python3 deploy.py -v -n ../config/network/network_settings.yaml -d ../config/deploy/os-odl-bgpvpn-noha.yaml --deploy-dir ../build --lib-dir ../lib --image-dir ../.build --virtual-computes 2 --virtual-default-ram 16
-For os-odl-bgpvpn-ha deployment:
---------------------------------
+* For os-odl-bgpvpn-ha deployment:
-python3 deploy.py -v -n ../config/network/network_settings.yaml -d ../config/deploy/os-odl-bgpvpn-ha.yaml --deploy-dir ../build --lib-dir ../lib --image-dir ../.build --virtual-computes 2 --virtual-default-ram 16
+ python3 deploy.py -v -n ../config/network/network_settings.yaml -d ../config/deploy/os-odl-bgpvpn-ha.yaml --deploy-dir ../build --lib-dir ../lib --image-dir ../.build --virtual-computes 2 --virtual-default-ram 16
Limitations, Issues and Workarounds
===================================
@@ -107,5 +106,5 @@ Integration with data center gateway will not work due to missing OVS patches fo
References
==========
-For more information on the OPNFV Fraser release, please visit
-https://www.opnfv.org/software
+For more information on the OPNFV latest stable release, please visit
+https://www.opnfv.org/software \ No newline at end of file