Difference between revisions of "Network/LBaaS"
(→Meeting 22.05.2014) |
(→Meeting 22.05.2014) |
||
Line 6: | Line 6: | ||
** https://review.openstack.org/#/c/89903/ | ** https://review.openstack.org/#/c/89903/ | ||
* The new API will require a different creation workflow | * The new API will require a different creation workflow | ||
− | + | ||
We should also discuss that the new API is going to require a | We should also discuss that the new API is going to require a | ||
different workflow to get a load balancer up and running. How is this | different workflow to get a load balancer up and running. How is this | ||
going to look and if it makes sense. I think the creation workflow | going to look and if it makes sense. I think the creation workflow | ||
would be this: | would be this: | ||
− | + | # Create Pool | |
− | + | # Create Pool Member(s) and associate to Pool | |
− | + | # Create Listener and add pool to this listener. | |
− | + | # Create Load Balancer and add listener to this load balancer. | |
− | |||
This might have some issues as I think there might be an expectation | This might have some issues as I think there might be an expectation | ||
Line 21: | Line 20: | ||
balancer is the root object and is created last. So Another option is: | balancer is the root object and is created last. So Another option is: | ||
− | + | # Create Load Balancer | |
− | + | # Create Listener and associate it with the load balancer | |
− | + | # Create Pool and associate with Listener | |
− | + | # Create pool member and associate with pool | |
Problem with this is when does the actual load balancer process get spun | Problem with this is when does the actual load balancer process get spun | ||
Line 30: | Line 29: | ||
and listeners? A load balancer should be able to add an existing | and listeners? A load balancer should be able to add an existing | ||
listener. | listener. | ||
− | + | ||
* Should subnet_id live on the pool, pool members, or somewhere else? | * Should subnet_id live on the pool, pool members, or somewhere else? | ||
* Driver abstract class changes needed to support new API | * Driver abstract class changes needed to support new API | ||
− | |||
Current methods are: | Current methods are: | ||
− | + | * create_vip, update_vip, delete_vip | |
− | + | * create_pool, update_pool, delete_pool | |
− | + | * create_member, update_member, delete_member | |
− | + | * create_pool_health_monitor, update_pool_health_monitor, | |
− | + | * delete_pool_health_monitor | |
− | + | * stats | |
We may only need to change vip to loadbalancer and thats it. | We may only need to change vip to loadbalancer and thats it. | ||
− | |||
== Meeting 01.05.2014 == | == Meeting 01.05.2014 == |
Revision as of 12:46, 22 May 2014
This page tracks Neutron Loadbalancer as a Service (LBaaS) meeting information. The OpenStack Networking Team (Neutron) holds public meetings in #openstack-meeting
on Thursday at 1400 UTC. Everyone is encouraged to attend.
Contents
Meeting 22.05.2014
Agenda
- Go over updated object model blueprint
- The new API will require a different creation workflow
We should also discuss that the new API is going to require a different workflow to get a load balancer up and running. How is this going to look and if it makes sense. I think the creation workflow would be this:
- Create Pool
- Create Pool Member(s) and associate to Pool
- Create Listener and add pool to this listener.
- Create Load Balancer and add listener to this load balancer.
This might have some issues as I think there might be an expectation that the root object should be created first. In this case the load balancer is the root object and is created last. So Another option is:
# Create Load Balancer # Create Listener and associate it with the load balancer # Create Pool and associate with Listener # Create pool member and associate with pool
Problem with this is when does the actual load balancer process get spun up? And does this solve for the M:N relationship between load balancers and listeners? A load balancer should be able to add an existing listener.
- Should subnet_id live on the pool, pool members, or somewhere else?
- Driver abstract class changes needed to support new API
Current methods are:
- create_vip, update_vip, delete_vip
- create_pool, update_pool, delete_pool
- create_member, update_member, delete_member
- create_pool_health_monitor, update_pool_health_monitor,
- delete_pool_health_monitor
- stats
We may only need to change vip to loadbalancer and thats it.
Meeting 01.05.2014
Agenda
- Stephen's API proposal
- https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit#heading=h.hgpfh6kl7j7a
- The document proposes the API that covers pretty much of the features that we've identified on the requirements page. The use cases are being addressed also. We need to converge on general approach proposed there.
- Summit Agenda
- We have two sessions at the neutron track. It makes sense to focus on the topics that will benefit most from face-to-face discussion.
Meeting 10.04.2014
Agenda
- Networking functions vs Virtualized appliances
- need to discuss basic concepts beyond lbaas API. Particular objects only vs the notion of Loadbalancer.
- Update on API discussion
- Status fields: admin, operational, deployment
- member status
Action Items
- Jorge to engage in "Single API" discussion on ML
- outline issues of existing LBaaS API
- Jorge to create API proposal based off of Atlas API spec.
- Add "least common denominator" requirements to wiki
Minutes/Log
Minutes: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-04-10-14.01.html
Log: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-04-10-14.01.log.html
Meeting 03.04.2014
Agenda
- Discuss API proposals
Action Items
- Fill use case statistics: https://docs.google.com/a/mirantis.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc
- Propose options for 'single-call API' for certain cases: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit
Minutes
Minutes: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-04-03-14.00.html
Log: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-04-03-14.00.log.html
Agenda for Meeting 27.03.2014
- Glossary
https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary
- Object model discussion
Most of key points have been already discussed.
- Collaboration
One of the items - integration with existing libra features
- HA
- Open discussion
Links: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
Agenda for Meeting 13.02.2014
Blueprint Tracking
- Loadbalancer instance
We'll revisit the rationale and the design of the feature.
- L7 rules
We'll discuss current progress and recent proposals from Stephen Balukoff
- SSL
Discussion Topics
- Downstream version of lbaas (?)
- Service Type Framework (providers)
We have a patch on review https://review.openstack.org/#/c/64139/ that introduces the ability to configure different providers with the same vendor driver and different configuration parameters. That looks like something that is better addressed with flavors.
Open discussion
any other topics you would like to bring up for discussion during the summit.
Icehouse LBaaS Etherpad: https://etherpad.openstack.org/p/icehouse-neutron-lbaas
Agenda for Meeting 06.02.2014
Announcements/General Information
- Gates are stable, we're good to go with reviews
Bugs
Blueprint Tracking
- Loadbalancer instance
- SSL
- L7 rules
- HA support for HAProxy
Vendor Blueprints
Discussion Topics
- Downstream version of lbaas (?)
Open discussion
any other topics you would like to bring up for discussion during the summit.
Icehouse LBaaS Etherpad: https://etherpad.openstack.org/p/icehouse-neutron-lbaas