|
|
(218 intermediate revisions by 3 users not shown) |
Line 1: |
Line 1: |
| The following page summarizes the meeting minutes from the weekly Octavia meetings. | | The following page summarizes the meeting minutes from the weekly Octavia meetings. |
| | | |
− | == 2014-10-22 Weekly meeting: == | + | ''' Previous meeting logs ''' |
| + | * Previous meetings, with their notes and logs, can be found [http://eavesdrop.openstack.org/meetings/octavia/ here]. |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2020/?C=M;O=D octavia-2020] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2019/?C=M;O=D octavia-2019] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2018/?C=M;O=D octavia-2018] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2017/?C=M;O=D octavia-2017] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2016/?C=M;O=D octavia-2016] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2015/?C=M;O=D octavia-2015] |
| + | ** [http://eavesdrop.openstack.org/meetings/octavia/2014/?C=M;O=D octavia-2014] |
| + | |
| + | == 2020-02-12 Weekly meeting: == |
| This meeting was held via IRC | | 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 | + | * The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-02-12-16.00.txt |
− | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-22-20.01.log.html | + | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-02-12-16.00.log.html |
| | | |
− | == 2014-10-15 Weekly meeting: == | + | == 2020-02-05 Weekly meeting: == |
| This meeting was held via IRC | | 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 | + | * The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-02-05-16.02.txt |
− | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-15-20.00.log.html | + | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-02-05-16.02.log.html |
| | | |
− | == 2014-10-08 Weekly meeting: == | + | == 2020-01-22 Weekly meeting: == |
| This meeting was held via IRC | | 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 | + | * The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-22-16.00.txt |
− | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-08-19.59.log.html | + | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-22-16.00.log.html |
| | | |
− | == 2014-10-01 Weekly meeting: == | + | == 2020-01-15 Weekly meeting: == |
| This meeting was held via IRC | | 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 | + | * The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-15-16.00.txt |
− | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-10-01-20.00.log.html | + | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-15-16.00.log.html |
| | | |
− | == 2014-09-24 Weekly meeting: == | + | == 2020-01-08 Weekly meeting: == |
| This meeting was held via IRC | | 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 | + | * The meeting minutes can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-08-16.01.txt |
− | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2014/octavia.2014-09-24-19.55.log.html
| + | * Full transcripts of the meeting can be found here: http://eavesdrop.openstack.org/meetings/octavia/2020/octavia.2020-01-08-16.01.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)
| |
− | ## 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
| |
− | # 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
| |
− | # 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
| |
− | | |
− | === 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 [https://review.openstack.org/#/c/113458/]
| |
− | ## 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
| |
− | # 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
| |
− | | |
− | '''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:'''
| + | == 2020-01-01 Weekly meeting: == |
− | * We need to pressure the Neutron core reviewers to review the Neutron LBaaS changes to get merges.
| + | Cancelled due to the holidays. |
− | * Version 2 front-end topology is different than the Version 1. Please review them individually, and thoroughly
| |
The following page summarizes the meeting minutes from the weekly Octavia meetings.
Cancelled due to the holidays.