From 3c21801514b259d1d1093f6b5f4c03eca2706670 Mon Sep 17 00:00:00 2001 From: Onong Tayeng Date: Thu, 24 May 2018 18:26:13 +0530 Subject: release notes and scenario doc updates for Fraser 6.1.0 Change-Id: Idbd25b91c4cb27aa36e7efa4ce011f7045fc0fca Signed-off-by: Onong Tayeng (cherry picked from commit 7a27dece748d84f7f665bd7b66e3e3567ee735c3) --- docs/release/release-notes/fds-release.rst | 163 +++++++-------------- .../os-nosdn-fdio-ha/FDS-nosdn-overview.png | Bin 88294 -> 67246 bytes .../os-nosdn-fdio-ha/scenario.description.rst | 37 +++-- .../os-nosdn-fdio-noha/FDS-nosdn-overview.png | Bin 88294 -> 67246 bytes .../os-nosdn-fdio-noha/scenario.description.rst | 38 +++-- 5 files changed, 90 insertions(+), 148 deletions(-) mode change 100755 => 100644 docs/scenarios/os-nosdn-fdio-noha/FDS-nosdn-overview.png diff --git a/docs/release/release-notes/fds-release.rst b/docs/release/release-notes/fds-release.rst index b44310a..e6b8729 100644 --- a/docs/release/release-notes/fds-release.rst +++ b/docs/release/release-notes/fds-release.rst @@ -6,15 +6,15 @@ License ======= -OPNFV Euphrates release notes for FastDataStacks +OPNFV Fraser release notes for FastDataStacks -OPNFV Euphrates release notes for FastDataStacks +OPNFV Fraser release notes for FastDataStacks are licensed under a Creative Commons Attribution 4.0 International License. You should have received a copy of the license along with this. If not, see . =================================================== -OPNFV Euphrates release notes for FastDataStacks +OPNFV Fraser release notes for FastDataStacks =================================================== Abstract @@ -22,7 +22,7 @@ Abstract This document describes the release notes of FastDataStacks project. -OPNFV Euphrates Release +OPNFV Fraser Release ======================= @@ -63,9 +63,8 @@ FastDataStacks is a great example of OPNFV’s modus operandi: create, compose, deploy, test, iterate. The key ingredient for all these scenarios is the data-plane forwarding and -control infrastructure supplied by FD.io, i.e. VPP and Honeycomb along with -OpenStack as the VM manager. In addition, OpenDaylight as a network controller -plays a key role in many of the scenarios built by FastDataStacks. +control infrastructure supplied by FD.io, i.e. VPP and networking-vpp along with +OpenStack as the VM manager. Release Data ============ @@ -74,142 +73,90 @@ Release Data | **Project** | FastDataStacks | | | | +--------------------------------------+--------------------------------------+ -| **Repo/tag** | fds/opnfv-5.1.0 | +| **Repo/tag** | fds/opnfv-6.1.0 | | | | +--------------------------------------+--------------------------------------+ -| **Release designation** | 5.1.0 | +| **Release designation** | 6.1.0 | | | | +--------------------------------------+--------------------------------------+ -| **Release date** | 2017-12-15 | +| **Release date** | 2018-05-25 | | | | +--------------------------------------+--------------------------------------+ -| **Purpose of the delivery** | OPNFV Euphrates release | +| **Purpose of the delivery** | OPNFV Fraser release | | | | +--------------------------------------+--------------------------------------+ -FastDataStacks Scenarios in Euphrates +FastDataStacks Scenarios in Fraser ====================================== -In release Euphrates, FastDataStacks releases the following scenarios: +In release Fraser, FastDataStacks releases the following scenarios: - * `os-nosdn-fdio-noha `_: + * `os-nosdn-fdio-noha `_: OpenStack (with Neutron networking-vpp mechanism driver), VPP - * `os-nosdn-fdio-ha `_: + * `os-nosdn-fdio-ha `_: OpenStack (in a high-availability setup, with Neutron networking-vpp mechanism driver), VPP - * `os-odl-fdio-noha `_: - OpenStack, - OpenDaylight (for Layer 2 and Layer 3 networking control), - HoneyComb, VPP - * `os-odl-fdio-ha `_: - OpenStack (in a high-availability setup), - OpenDaylight (for Layer 2 and Layer 3 networking control in clustered mode), - HoneyComb, VPP - * `os-odl-fdio_dvr-noha `_: - OpenStack, - OpenDaylight (for Layer 3 networking control; there is no Layer 2 configuration), - HoneyComb, VPP - - -All of the scenarios are installed using the APEX installer. + +Both scenarios are installed using the APEX installer. Known Issues/Restrictions ========================= -Scenario os-nosdn-fdio-noha known issues in Euphrates +Scenario os-nosdn-fdio-noha known issues in Fraser ----------------------------------------------------- * `FDS-156 `_: Race conditions for network-vif-plugged notification * `FDS-160 `_: Vlan fix on controller -* `FDS-401 `_: - SimpleHealthCheck fails in snaps_smoke -* `FDS-483 `_: - Live migration not supported - -Scenario os-nosdn-fdio-ha known issues in Euphrates +* `FDS-491 `_: + neutron trunk port feature is not supported in networking-vpp +* `FDS-492 `_: + VxLAN is not yet fully functional +* `FDS-493 `_: + snaps_smoke has some failures around floating ip +* `FDS-494 `_: + refstack has random failures +* `FDS-495 `_: + tempest test cases test_network_basic_ops and test_server_basic_ops fail but + pass when run standalone +* `FDS-496 `_: + NAT does not work with VPP 18.04 in some scenarios +* `FUNCTEST-970 `_: + vping_ssh/vping_userdata fail with fraser +* `APEX-593 `_: + cirros instance stays stuck in boot for a very long time causing functest + testcases to timeout + +Scenario os-nosdn-fdio-ha known issues in Fraser --------------------------------------------------- * `FDS-156 `_: Race conditions for network-vif-plugged notification * `FDS-160 `_: Vlan fix on controller -* `FDS-371 `_: - Tempest_full_parallel failures due to DBDeadlock error * `FDS-399 `_: Neutron ports are not marked ACTIVE * `FDS-400 `_: Race condition between VPP ML2 agent and tempest code -* `FDS-401 `_: - SimpleHealthCheck fails in snaps_smoke -* `FDS-483 `_: - Live migration not supported -* `APEX-468 `_: - Mariadb/mysqld fails to start post a reboot -* `APEX-469 `_: - Undercloud iptables rules are messed up post a power outage -* `FUNCTEST-841 `_: - Cloudify_ims testcase keeps timing out -* `ORCEHSTRA-13 `_: - Internal Server Error/java.lang.OutOfMemoryError: Java heap space - -Scenario os-odl-fdio-noha known issues in Euphrates ---------------------------------------------------- - -* `FDS-476 `_: - Race conditions in GBP -* `FDS-481 `_: - VPP hangs on blocking read from vhost user interface -* `FDS-482 `_: - Live migration not supported -* `FDS-484 `_: - snaps_smoke failures +* `FDS-491 `_: + neutron trunk port feature is not supported in networking-vpp +* `FDS-492 `_: + VxLAN is not yet fully functional +* `FDS-493 `_: + snaps_smoke has some failures around floating ip +* `FDS-494 `_: + refstack has random failures +* `FDS-495 `_: + tempest test cases test_network_basic_ops and test_server_basic_ops fail but + pass when run standalone +* `FDS-496 `_: + NAT does not work with VPP 18.04 in some scenarios +* `FUNCTEST-970 `_: + vping_ssh/vping_userdata fail with fraser +* `APEX-593 `_: + cirros instance stays stuck in boot for a very long time causing functest + testcases to timeout * `APEX-468 `_: Mariadb/mysqld fails to start post a reboot -* `APEX-469 `_: - Undercloud iptables rules are messed up post a power outage -* `APEX-532 `_: - Add nat undercloud configuration for fdio scenarios - -Scenario os-odl-fdio-ha known issues in Euphrates -------------------------------------------------- - -* `FDS-476 `_: - Race conditions in GBP -* `FDS-481 `_: - VPP hangs on blocking read from vhost user interface -* `FDS-482 `_: - Live migration not supported -* `FDS-484 `_: - snaps_smoke failures -* `APEX-468 `_: - Mariadb/mysqld fails to start post a reboot -* `APEX-469 `_: - Undercloud iptables rules are messed up post a power outage -* `APEX-532 `_: - Add nat undercloud configuration for fdio scenarios - -Scenario os-odl-fdio_dvr-noha known issues in Euphrates -------------------------------------------------- - -* `FDS-481 `_: - VPP hangs on blocking read from vhost user interface -* `FDS-482 `_: - Live migration not supported -* `FDS-484 `_: - snaps_smoke failures -* `FDS-485 `_: - LISP errors, improvements and cleanup in GBP -* `APEX-468 `_: - Mariadb/mysqld fails to start post a reboot -* `APEX-469 `_: - Undercloud iptables rules are messed up post a power outage -* `APEX-532 `_: - Add nat undercloud configuration for fdio scenarios -* `HC2VPP-249 `_: - Route can be created even if output interface does not exist -* `HC2VPP-250 `_: - Cannot add EID if it's already present in operational DS - diff --git a/docs/scenarios/os-nosdn-fdio-ha/FDS-nosdn-overview.png b/docs/scenarios/os-nosdn-fdio-ha/FDS-nosdn-overview.png index 0692374..d790fd4 100755 Binary files a/docs/scenarios/os-nosdn-fdio-ha/FDS-nosdn-overview.png and b/docs/scenarios/os-nosdn-fdio-ha/FDS-nosdn-overview.png differ diff --git a/docs/scenarios/os-nosdn-fdio-ha/scenario.description.rst b/docs/scenarios/os-nosdn-fdio-ha/scenario.description.rst index ee4196e..8501b76 100755 --- a/docs/scenarios/os-nosdn-fdio-ha/scenario.description.rst +++ b/docs/scenarios/os-nosdn-fdio-ha/scenario.description.rst @@ -15,7 +15,7 @@ are: - APEX (TripleO) installer (please also see APEX installer documentation) - Openstack (in HA configuration) - FD.io/VPP virtual forwarder for tenant networking - - networking-vpp (Neutron ML2 mechanism driver for FD.io/VPP) + - networking-vpp (Neutron ML2 mechanism driver and L3 plugin for FD.io/VPP) - etcd (networking-vpp's distributed key-value store) in clustered mode Introduction @@ -45,19 +45,17 @@ servers: * 2 or more Computehosts -Tenant networking leverages FD.io/VPP. Open VSwitch (OVS) is used for all other -connectivity, in particular the connectivity to public networking / the -Internet (i.e. br-ext) is performed via OVS as in any standard OpenStack -deployment. Neutron ML2 plugin is configured to use networking-vpp, the ML2-VPP -networking mechanism driver. Networking-vpp also provides the VPP management -agent used to setup and manage layer 2 networking for the scenario. Tenant -networking can either leverage VLANs or plain interfaces. Layer 3 connectivity -for a tenant network is provided centrally via qrouter on the control node. As -in a standard OpenStack deployment, the Layer3 agent configures the qrouter and -associated rulesets for security (security groups) and NAT (floating IPs). Public -IP network connectivity for a tenant network is provided by interconnecting the -VPP-based bridge domain representing the tenant network to qrouter using a tap -interface. +Tenant as well as public networking leverages FD.io/VPP. Neutron ML2 plugin is +configured to use networking-vpp as the mechanism driver for VPP. +Networking-vpp also provides the VPP management agent used to setup and manage +layer 2 networking for the scenario. Tenant networking can either leverage +VLANs or plain interfaces. Layer 3 connectivity for a tenant network is +provided by the networking-vpp L3 plugin. The networking-vpp agent, which also +acts as the L3 agent, configures the necessary artifacts in VPP for providing +layer 3 connectivity. Public IP network connectivity for a tenant network is +provided by interconnecting the VPP-based bridge domain representing the +tenant network to a high-performance VPP tapv2 interface which in turn is +bridged to a linux bridge, br-ex, on the network node. The setup is depicted below: @@ -72,11 +70,10 @@ Main features of the "os-nosdn-fdio-ha" scenario: * Automated installation using the APEX installer * Fast and scalable tenant networking using FD.io/VPP as forwarder * Layer 2 networking using VLANs, managed and controlled - through the VPP ML2 plugin - * Layer 3 connectivitiy for tenant networks supplied centrally - on the Control node through standard OpenStack mechanisms. - All layer 3 features apply, including floating IPs (i.e. NAT) - and security groups + through the VPP ML2 plugin and the agent + * Layer 3 connectivitiy for tenant networks is provided through the + networking-vpp L3 plugin and agent on the Control/network node. All layer 3 + features apply, including floating IPs (i.e. NAT) and security groups * DHCP server for tenant instances provided using the standard OpenStack dnsmasq server * OpenStack high availability @@ -92,7 +89,7 @@ light-weight control plane agent for VPP forwarder has been created. For details see also https://github.com/openstack/networking-vpp. Networking-vpp provides a Neutron ML2 mechanism driver to bring the advantages -of VPP to OpenStack deployments.It uses an etcd cluster on the control node to +of VPP to OpenStack deployments. It uses an etcd cluster on the control node to keep track of the compute nodes, agent state and port bindings/unbindings. It's been written to be as simple and readable as possible, which means it's diff --git a/docs/scenarios/os-nosdn-fdio-noha/FDS-nosdn-overview.png b/docs/scenarios/os-nosdn-fdio-noha/FDS-nosdn-overview.png old mode 100755 new mode 100644 index 0692374..d790fd4 Binary files a/docs/scenarios/os-nosdn-fdio-noha/FDS-nosdn-overview.png and b/docs/scenarios/os-nosdn-fdio-noha/FDS-nosdn-overview.png differ diff --git a/docs/scenarios/os-nosdn-fdio-noha/scenario.description.rst b/docs/scenarios/os-nosdn-fdio-noha/scenario.description.rst index aeecbb8..2e18ffc 100755 --- a/docs/scenarios/os-nosdn-fdio-noha/scenario.description.rst +++ b/docs/scenarios/os-nosdn-fdio-noha/scenario.description.rst @@ -15,7 +15,7 @@ are: - APEX (TripleO) installer (please also see APEX installer documentation) - Openstack (in non-HA configuration) - FD.io/VPP virtual forwarder for tenant networking - - networking-vpp (Neutron ML2 mechanism driver for FD.io/VPP) + - networking-vpp (Neutron ML2 mechanism driver and L3 plugin for FD.io/VPP) Introduction ============ @@ -44,22 +44,21 @@ servers: * 1 or more Computehosts -Tenant networking leverages FD.io/VPP. Open VSwitch (OVS) is used for all other -connectivity, in particular the connectivity to public networking / the -Internet (i.e. br-ext) is performed via OVS as in any standard OpenStack -deployment. Neutron ML2 plugin is configured to use networking-vpp, the ML2-VPP -networking mechanism driver. Networking-vpp also provides the VPP management -agent used to setup and manage layer 2 networking for the scenario. Tenant -networking can either leverage VLANs or plain interfaces. Layer 3 connectivity -for a tenant network is provided centrally via qrouter on the control node. As -in a standard OpenStack deployment, the Layer3 agent configures the qrouter and -associated rulesets for security (security groups) and NAT (floating IPs). Public -IP network connectivity for a tenant network is provided by interconnecting the -VPP-based bridge domain representing the tenant network to qrouter using a tap -interface. +Tenant as well as public networking leverages FD.io/VPP. Neutron ML2 plugin is +configured to use networking-vpp as the mechanism driver for VPP. +Networking-vpp also provides the VPP management agent used to setup and manage +layer 2 networking for the scenario. Tenant networking can either leverage +VLANs or plain interfaces. Layer 3 connectivity for a tenant network is +provided by the networking-vpp L3 plugin. The networking-vpp agent, which also +acts as the L3 agent, configures the necessary artifacts in VPP for providing +layer 3 connectivity. Public IP network connectivity for a tenant network is +provided by interconnecting the VPP-based bridge domain representing the +tenant network to a high-performance VPP tapv2 interface which in turn is +bridged to a linux bridge, br-ex, on the network node. The setup is depicted below: + .. image:: FDS-nosdn-overview.png Features of the scenario @@ -70,11 +69,10 @@ Main features of the "os-nosdn-fdio-noha" scenario: * Automated installation using the APEX installer * Fast and scalable tenant networking using FD.io/VPP as forwarder * Layer 2 networking using VLANs, managed and controlled - through the VPP ML2 plugin - * Layer 3 connectivitiy for tenant networks supplied centrally - on the Control node through standard OpenStack mechanisms. - All layer 3 features apply, including floating IPs (i.e. NAT) - and security groups + through the VPP ML2 plugin and the agent + * Layer 3 connectivitiy for tenant networks is provided through the + networking-vpp L3 plugin and agent on the Control/network node. All layer 3 + features apply, including floating IPs (i.e. NAT) and security groups * DHCP server for tenant instances provided using the standard OpenStack dnsmasq server @@ -88,7 +86,7 @@ light-weight control plane agent for VPP forwarder has been created. For details see also https://github.com/openstack/networking-vpp. Networking-vpp provides a Neutron ML2 mechanism driver to bring the advantages -of VPP to OpenStack deployments.It uses an etcd cluster on the control node to +of VPP to OpenStack deployments. It uses an etcd cluster on the control node to keep track of the compute nodes, agent state and port bindings/unbindings. It's been written to be as simple and readable as possible, which means it's -- cgit 1.2.3-korg