Octavia/Meeting Minutes

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:

1. Discuss future of Octavia in light of Neutron-incubator project proposal.
   1. There are many problems with Neutron-Incubator as currently described
   2. The political happenings in Neutron leave our LBaaS patches under review unlikely to land in Juno
   3. The Incubator proposal doesn't affect Octavia development direction, with inclination to distance ourselves from Neutron proper
   4. With the Neutron Incubator proposal in current scope, efforts of people pushing forward Neutron LBaaS patches should be re-focused into Octavia.
2. Discuss operator networking requirements (carry-over from last week)
   1. 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
   2. (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
3. Discuss v0.5 component design proposal [1]
   1. Notification for back-end node health (aka being offline) isn't required for 0.5, but is a must have later
   2. Notification of LB health (HA Proxy, etc) is definitely a requirement in 0.5
   3. Still looking for more feedback on the proposal itself
4. Discuss timeline on moving these meetings to IRC.
   1. Most members in favor of keeping the webex meetings for the time being
   2. One major point was other openstack/stackforge use video meetings as their "primary" source as well

2014-08-06 Weekly meeting:

1. Octavia Constitution and Project Direction Documents (Road map)
   1. Constitution and Road map will potentially be adopted after another couple days; providing those who were busy more time to review the information
2. Octavia Design Proposals
   1. Difference between version 0.5 and 1.0 isn't huge
   2. 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
   3. After refining Version 1 document (with some scrutiny) all changes will be propagated to the Version 2 document
   4. Version 0.5 is unpublished
   5. 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
   6. The portions under control of neutron lbaas is the User API and the driver (for neutron lbaas)
   7. If neutron LBaaS is a sufficient front-end (user API doesn't suck), then Octavia will be kept as a vendor driver
   8. 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
   9. 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
3. Operator Network Topology Requirements
   1. One requirement is floating IPs.
   2. 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
   3. Network interface plug-ability (potentially)
   4. 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.
4. HA/Failover Options/Solutions
   1. 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
   2. One option for HA: Spare pool option (similar to Libra)
      • Poor recovery time is a big problem
   3. 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

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