Jump to: navigation, search

Difference between revisions of "Network/LBaaS"

(Meeting 10.03.2015)
 
(71 intermediate revisions by 10 users not shown)
Line 1: Line 1:
This page tracks Neutron Loadbalancer as a Service (LBaaS) meeting information. The OpenStack Networking Team ([[Neutron]]) holds public meetings in <code><nowiki>#openstack-meeting</nowiki></code> on Thursday at 1400 UTC. Everyone is encouraged to attend.
+
This page tracks Neutron Loadbalancer as a Service (LBaaS) meeting information. The OpenStack Networking Team ([[Neutron]]) holds public meetings in <code><nowiki>#openstack-meeting-4</nowiki></code> on Tuesday at 1600 UTC. Everyone is encouraged to attend.
  
== Meeting 05.06.2014 ==
+
== Meeting 24.03.2015 ==
 
=== Agenda ===
 
=== Agenda ===
* BP refactor review
+
* Announcements
** https://review.openstack.org/#/c/89903/
+
* Horizon work
* Hackathon logistics
+
** https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases - etherpad to collect use cases
** Plan for hackathon in 2 weeks
+
* Open Discussion
  
== Meeting 29.05.2014 ==
+
== Meeting 10.03.2015 ==
 
=== Agenda ===
 
=== Agenda ===
* Finalize first object model refactor blueprint
+
* Announcements
** https://review.openstack.org/#/c/89903/
+
** Today is effectively the last day to merge for Kilo!
** N:M vs 1:M LoadBalancer to Listener relationship
+
* Open Discussion
*** IPv4 and IPv6 addresses on LoadBalancer
 
** N:M vs 1:M Pool to HealthMonitor relationship
 
*** Should deprecation be left to another blueprint?
 
** M:1 vs 1:1 Listener to Pool
 
** Pool status
 
* Epic/Umbrella blueprint for tasks needed complete object model and API refactor
 
 
 
== Meeting 22.05.2014 ==
 
=== Agenda ===
 
* Go over updated object model blueprint
 
** https://review.openstack.org/#/c/89903/
 
* 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<br/>
 
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 <br/>
 
Log: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-04-03-14.00.log.html <br/>
 
== 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
 

Latest revision as of 19:01, 18 March 2015

This page tracks Neutron Loadbalancer as a Service (LBaaS) meeting information. The OpenStack Networking Team (Neutron) holds public meetings in #openstack-meeting-4 on Tuesday at 1600 UTC. Everyone is encouraged to attend.

Meeting 24.03.2015

Agenda

Meeting 10.03.2015

Agenda

  • Announcements
    • Today is effectively the last day to merge for Kilo!
  • Open Discussion