Jump to: navigation, search


Revision as of 22:16, 26 June 2014 by Jorge (talk | contribs) (Update for this weeks agenda)

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.

Meeting 26.06.2014


  • Updates
  • Node pools vs pools naming.
    • Moving discussion to ML
  • Mark McClain's flavor blueprint
    • Everyone please review. Meeting tomorrow on this item.
  • TLS blueprint update (evgenyf)
    • We agreed to move dev effort to v2 only.
  • L7 switching blueprint (avishavb)
    • Everyone please review bp.

Meeting 12.06.2014


Meeting 05.06.2014


  • Hackathon logistics
    • Plan for hackathon in 2 weeks
    • Possible scope of hackathon
      • API Revision in Neutron LBaaS
        • By the time the Juno freeze occurs what functionality will be exposed via the Neutron LBaaS API (SSL? L7? etc.)
      • Cleaning up Neutron LBaaS plugin interface points
      • Getting reference implementation up to date with API revision
    • Choose direction for barbican integration
      • Using eventing model
      • Pushing orchestration decisions to GUI & power API users
  • BP refactor review

Meeting 29.05.2014


  • Finalize first object model refactor blueprint
    • https://review.openstack.org/#/c/89903/
    • N:M vs 1:M LoadBalancer to Listener relationship
      • 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


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


Meeting 10.04.2014


  • 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: 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


  • Discuss API proposals

Action Items


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


  • 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


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