Open Stack

Hi,

I have added a reference to the document in http://summit.openstack.org/cfp/edit/194
So that we will also have the subjects logged there.

Regards,
                -Sam.

From: Ilya Shakhat [mailto:ishakhat at mirantis.com]
Sent: Friday, March 01, 2013 3:29 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum][LBaaS] Agenda for the summit

Hi Sam, Dan,

We've discussed the agenda between Eugene, Oleg and me - besides topics mentioned by Sam the following are also important:
 * Device management - this can be implemented via config files per driver or via Quantum extension that suits all types of services
 * Stats collecting - just store latest data in Pool or provide more sophisticated API?
 * HTTPS support
 * Monitoring - how to inform user that member is put out of the traffic by LB's healthmon

I've put the whole list to etherpad https://etherpad.openstack.org/havana-quantum-lbaas.
Let's write out every single topic that improves our LBaaS :)


Thanks,
Ilya
2013/2/28 balaji patnala <patnala003 at gmail.com<mailto:patnala003 at gmail.com>>
Hi Sam and Dan,

I think there are two different approaches we are seeing on Service implementation like having 'Generic Service Agent', which will cater all the network needs like the one given in below link:

https://review.openstack.org/#/c/20985/

and the other which was recently shared by Dan as below:

https://review.openstack.org/#/c/22794/3

We may have to follow modular approach, where these services can be extended to other applications as well in next releases.

As Dan rightly stated that we have to make sure that Service Architecture must support both VM+HW appliances.

Regards,
Balaji.P



On Thu, Feb 28, 2013 at 7:39 AM, Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>> wrote:
Hi Sam,

That sounds like a great starting list of LBaaS discussion topics.  Once we're closer to the summit, we'll probably use an etherpad to help organize our discussion and this seems like a good outline to start from.  Pushing on more advanced plugin/driver models aimed at VM + HW load balancers is certainly something that a lot of folks are interested in.

Dan

On Wed, Feb 27, 2013 at 4:46 PM, Samuel Bercovici <SamuelB at radware.com<mailto:SamuelB at radware.com>> wrote:
Hi Everyone,

The deliveries of LBaaS for Grizzly looks like it will be focused on using HAProxy.

The following items might  come to mind for discussion in the Havana summit:

1.       Review the Grizzly tenant API proposal and discuss what should be done for Havana

2.       Review the Driver implementation and discuss next step to enable additional solutions and vendors to be added

a.       Driver API

b.      Driver selection

c.       Where should the scheduler be if at all?

d.      Solution models

                                                               i.      Network service (as for Grizzly)

                                                             ii.      Service VM

                                                            iii.      Physical appliances - decide if/how to connect physical appliances (revisit the Edge Gateway semantics proposed in the Grizzly summit?)

3.       Address additional network topologies and capabilities:

a.       LB between two networks

b.      Adding SNAT and DSR on top of the current NAT implementation

What do you think?

Regards,
                -Sam.


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130324/1d8b5ca9/attachment.html>