Octavia/Meeting Minutes
< Octavia
Revision as of 21:01, 28 January 2015 by Trevor Vardeman (talk | contribs)
The following page summarizes the meeting minutes from the weekly Octavia meetings.
Contents
- 1 2015-01-28 Weekly meeting:
- 2 2015-01-21 Weekly meeting:
- 3 2015-01-14 Weekly meeting:
- 4 2015-01-07 Weekly meeting:
- 5 2014-12-10 Weekly meeting:
- 6 2014-12-03 Weekly meeting:
- 7 2014-11-19 Weekly meeting:
- 8 2014-11-12 Weekly meeting:
- 9 2014-10-29 Weekly meeting:
- 10 2014-10-22 Weekly meeting:
- 11 2014-10-15 Weekly meeting:
- 12 2014-10-08 Weekly meeting:
- 13 2014-10-01 Weekly meeting:
- 14 2014-09-24 Weekly meeting:
- 15 2014-09-17 Weekly meeting:
- 16 2014-09-10 Weekly meeting:
- 17 2014-09-03 Weekly meeting:
- 18 2014-08-27 Weekly meeting:
- 19 2014-08-20 Weekly meeting:
- 20 2014-08-13 Weekly meeting:
- 21 2014-08-06 Weekly meeting:
2015-01-28 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-28-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-28-20.00.log.html
2015-01-21 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-21-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-21-20.00.log.html
2015-01-14 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-14-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-14-20.00.log.html
2015-01-07 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-07-20.03.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-01-07-20.03.log.html
2014-12-10 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-12-10-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-12-10-20.00.log.html
2014-12-03 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-12-03-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-12-03-20.00.log.html
2014-11-19 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-11-19-19.59.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-11-19-19.59.log.html
2014-11-12 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-11-12-20.15.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-11-12-20.15.log.html
2014-10-29 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-29-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-29-20.00.log.html
2014-10-22 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-22-20.01.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-22-20.01.log.html
2014-10-15 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-15-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-15-20.00.log.html
2014-10-08 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-08-19.59.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-08-19.59.log.html
2014-10-01 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-01-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-01-20.00.log.html
2014-09-24 Weekly meeting:
This meeting was held via IRC
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-24-19.55.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-24-19.55.log.html
2014-09-17 Weekly meeting:
This meeting was held via IRC.
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-17-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-17-20.00.log.html
2014-09-10 Weekly meeting:
This meeting was held via IRC.
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-10-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-10-20.00.log.html
2014-09-03 Weekly meeting:
This meeting was held via IRC.
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-03-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-03-20.00.log.html
2014-08-27 Weekly meeting:
This meeting was held via IRC.
- The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-08-27-20.00.html
- Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-08-27-20.00.log.html
2014-08-20 Weekly meeting:
- Revisit some basic features of loadbalancing as a service's object model and api.
- Brandon advocated Loadbalancer as only root object
- The reason for root objects was for sharing.
- Will we allow sharing of pools in a listener?
- Stephen suggests providing sharing to the customer for benefits
- provides simplicity to the user
- Example: L7 rules all referencing the same pool: simpler for the user to handle it.
- Without sharing there may also be a series of extra health checks that are unnecessary
- German wants placement of the pool to be on the load balancer
- This allows sharing pools between different listeners.
- Counter argument by Stephen: Sharing pools between HTTP/HTTPS load balancers would be really rare, where normally people would use a different port. Adding another health check wouldn't be a big deal. Proposed L7 policies where you have a complicated rule set causing duplication for a "or" set, would increase the health check requirement. (Refer to email in list)
- Stephen suggests providing sharing to the customer for benefits
- If we desire many to many, there will be more root objects than just load balancer.
- Moving to many-to-many after establishing one root object would be difficult
- Brandon advocated Loadbalancer as only root object
- Get consensus on initial project direction and implementation details
- One HA proxy instance per load balancer or one HA proxy instance per listener?
- Per ML discussion: Keeping listener on one HA Proxy instance increases performance on one Octavia VM
- Desires benchmarks for this to support (German has this included in his next sprint)
- Suggested shelving this until benchmarks are researched.
- Future discussions on the ML for this decision
- A concern from Vijay: with one HA Proxy instance per listener, would that affect scalability?
- This was suggested to move to the mailing list
- Per ML discussion: Keeping listener on one HA Proxy instance increases performance on one Octavia VM
- One HA proxy instance per load balancer or one HA proxy instance per listener?
- When decisions (like #2) have been made, where should this be stored, wiki or in code?
- Bad thing about wiki is if Openstack makes a documentation overhaul the decision information might get lost.
- Bad thing about code is its harder to find and read.
- Decision was to keep it in the Wiki.
- Whose responsibility is it to update the wiki with these decisions?
- For now, Stephen has been updating the wiki
- In the future, people involved in the decision will decide someone to update the wiki at the time
- What else is needed to change in the 0.5 design before it can be approved and implementation can begin?
- Action item for everyone: Review this design before next week's meeting. Keep in mind the document is supposed to be somewhat general.
- Start going over action items (https://etherpad.openstack.org/p/Octavia_Action_Items)
- Action Item for everyone: Review the migration information proposed by Brandon.
- Per link above, start from 1 and move the way down the list.
- How can we decide who is working on what?
- Get launchpad set up for octavia to allow for blueprint additions and thus allow people to contribute to a specific effort
- We need a list of things that are required to do and what needs hooked up how (the glue between the different pieces)
- What kind of communication between different components?
- XMLRPC?
- A REST interface?
- Something different?
- Brandon working on Data Models and SQL Alchemy Models.
- Stephen working on Octavia VM API interface, including what technology to use
- Doug working on Skeleton Structure
- Brandon working on launchpad and blueprints issue as well
- Stephen will also prioritize this list
- Topics that need discussed should be expressed and discussed in the mailing list
- Michael Johnson working on the base image scripts
- Would we use an image we've built or set it up after creation of a VM
- Start with a base image with pre-packaging of Octavia scripts and such instead of Cloud init doing all the work downloading and such. Saves time/resources.
- Ideally we would have a place in the Octavia repo with a script or something that when run would create an image.
- The images will potentially change based on flavoring options.
- This includes custom images via customer requirements
- Would we use an image we've built or set it up after creation of a VM
After meeting
- Q: Are we going to be incubated?
- A: Yes, we are basically destined for incubation, period. Note: we will assuredly not be in Juno.
- Q: Why be part of Neutron? Why not just be our own program?
- A: We want to distance ourselves from Neutron to some extent. We will formalize this via a networking driver in Octavia. Note: we do not want to burn any bridges here, so we want to be appropriate in our spin-out process.
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