Bug 927958 - [RFE][neutron]: High Availability Neutron Network Scaling
Summary: [RFE][neutron]: High Availability Neutron Network Scaling
Keywords:
Status: CLOSED DUPLICATE of bug 1042396
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: 2.0 (Folsom)
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 5.0 (RHEL 7)
Assignee: RHOS Maint
QA Contact: yeylon@redhat.com
URL: https://blueprints.launchpad.net/quan...
Whiteboard:
: 986503 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-26 14:53 UTC by Josh Carter
Modified: 2018-12-01 16:00 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-29 13:46:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Josh Carter 2013-03-26 14:53:35 UTC
1. Proposed title of this feature request

High Availability Quantum Network Scaling

2. Who is the customer behind the request?
Account: name (acct #) 1403700
TAM customer: no/yes yes
SRM customer: no/yes yes
Strategic: no/yes yes

3. What is the nature and description of the request?

As per redhat documentation Quantum, routes all traffic through a single node, which is resulting a single point of failure. Currently this is the only supported method of quantum right now.

4. Why does the customer need this? (List the business requirements here)

Quantum presents a single point of failure for the entire RHOS environment.  

5. How would the customer like to achieve this? (List the functional requirements here) 

Is it possible to setup Quantum on top of a cluster ?

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla? NO

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? NO

9. Is the sales team involved in this request and do they have any additional input? No

10. List any affected packages or components.

openstack-quantum-2012.2.3-5.el6ost.noarch

Comment 2 Perry Myers 2013-05-20 17:16:53 UTC
gkotton/mnewby/rkukura:
This should be addressed in RHOS 3.0 partially after we include netns support, correct?  Can one of you outline what the current state of HA for RHOS 3.0/Quantum will be in this bug?

Comment 3 Gary Kotton 2013-05-21 08:15:19 UTC
Hi,
I am not sure that this will be something that will be ready for RHOS 3.0.
There are 2 parts:
1. Scale
 - RHOS 3.0 has support for this for the DHCP and the L3 agents
 - DHCP agents can be assigned networks
 - Routers can be assigned to l3 agents
2. HA
 - The DHCP agents have HA. Tis requires manual configuration by the user. An upstream patch has been added to automate this (https://review.openstack.org/#/c/27907/). This is still in review. An additional patch needs to be added that will automatically select another DHCP agent if an existing agent goes down. This will be done in te near future. This is certainly something that can be added to RHOS 3.0.
 - There is no HA fo the l3 agents. There is work being done upstream on this at the moment. I hope that it may be in by the middle or end of the Havana cycle. We need to follow this and see how it can be addressed in RHOS. (https://blueprints.launchpad.net/quantum/+spec/quantum-multihost)
Thanks
Gary

Comment 4 Perry Myers 2013-05-21 11:30:53 UTC
Based on the explanation in Comment #3, it seems that OpenStack Networking HA really needs to be reassessed following the Havana release cycle upstream, so this bug needs to be moved to RHOS 4.0 to be reevaluated following the Havana release cycle.

Comment 8 lpeer 2014-01-02 09:40:37 UTC
*** Bug 986503 has been marked as a duplicate of this bug. ***

Comment 10 Nir Yechiel 2014-01-29 13:46:50 UTC

*** This bug has been marked as a duplicate of bug 1042396 ***


Note You need to log in before you can comment on or make changes to this bug.