Octavia/Meeting Minutes
< Octavia
Revision as of 18:45, 21 August 2014 by Stephen Balukoff (talk | contribs)
The following page summarizes the meeting minutes from the weekly Octavia meetings.
2014-08-20 Weekly meeting:
(To be filled out)
2014-08-13 Weekly meeting:
- Discuss future of Octavia in light of Neutron-incubator project proposal.
- There are many problems with Neutron-Incubator as currently described
- The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno
- The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper
- With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia.
- Discuss operator networking requirements (carry-over from last week)
- Both HP and Rackspace seem to agree that as long as Octavia uses Neutron-like floating IPs, their networks should be able to work with proposed Octavia topologies
- (Blue Box) also wanted to meet with Rackspace's networking team during the operator summit a few weeks from now to thoroughly discuss network concerns
- Discuss v0.5 component design proposal [1]
- Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later
- Notification of LB health (HA Proxy, etc) is definitely a requirement in 0.5
- Still looking for more feedback on the proposal itself
- Discuss timeline on moving these meetings to IRC.
- Most members in favor of keeping the webex meetings for the time being
- One major point was other openstack/stackforge use video meetings as their "primary" source as well
2014-08-06 Weekly meeting:
- Octavia Constitution and Project Direction Documents (Road map)
- Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information
- Octavia Design Proposals
- Difference between version 0.5 and 1.0 isn't huge
- Version 2 has many network topology changes and Layer 4 routing
- This includes N node Active-Active
- Would like to avoid Layer 2 connectivity with Load Balancers (included in version 1 however)
- Layer router driver
- Layer router controller
- Long term solution
- After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document
- Version 0.5 is unpublished
- All control layer, anything connected to the intermediate message bus in version 1, will be collapsed down to 1 daemon.
- No scale-able control, but scale-able service delivery
- Version 1 will be the first large operator compatible version, that will have both scale-able control and scale-able service delivery
- 0.5 will be a good start
- laying out ground work
- rough topology for the end users
- must be approved by the networking teams for each contributing company
- The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas)
- If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver
- Potentially including a REST API on top of Octavia
- Octavia is initially just a vendor driver, no real desire for another API in front of Octavia
- If someone wants it, the work is "trivial" and can be done in another project at another time
- Octavia should have a loose coupling with Neutron; use a shim for network connectivity (one specifically for Neutron communication in the start)
- This is going to hold any "dirty hacks" that would be required to get something done, keeping Octavia clean
- Example: changing the mac address on a port
- This is going to hold any "dirty hacks" that would be required to get something done, keeping Octavia clean
- Operator Network Topology Requirements
- One requirement is floating IPs.
- IPv6 is in demand, but is currently not supported reliably on Neutron
- IPv6 would be represented as a different load balancer entity, and possibly include co-location with another Load Balancer
- Network interface plug-ability (potentially)
- Sections concerning front-end connectivity should be forwarded to each company's network specialists for review
- Share findings in the mailing list, and dissect the proposals with the information and comment what requirements are needing added etc.
- HA/Failover Options/Solutions
- Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least)
- Will gather more information from another member in Rackspace to provide to the ML for initial discussions
- One option for HA: Spare pool option (similar to Libra)
- Poor recovery time is a big problem
- Another option for HA: Active/Passive
- Bluebox uses one active and one passive configuration, and has sub-second fail over. However is not resource-sufficient
- Rackspace may have a solution to this, but the conversation will be pushed off to the next meeting (at least)
Questions:
- Q: What is the expectation for a release time-frame
- A: Wishful thinking; Octavia version 0.5 beta for Juno (probably not, but would be awesome to push for that)
Notes:
- We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges.
- Version 2 front-end topology is different than the Version 1. Please review them individually, and thoroughly