Open Stack

For Grizzly, the core LBaaS service should support a well-defined set of protocols. Let's say HTTP, HTTPS and TCP. All drivers are expected to support these three, which I think is a reasonable assumption to make for all open source and vendor LB solutions we are contemplating.

Beyond that (post Grizzly), we should look at a framework for how drivers can extend the core API with extra capabilities, whether it is support for new protocols, new LB algorithms, new types of health monitors, etc. 

Youcef

 

> -----Original Message-----
> From: Roman Prykhodchenko [mailto:rprikhodchenko at mirantis.com]
> Sent: Wednesday, January 23, 2013 7:27 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Quantum] [LBaaS]Issues with supported
> protocols for VIPs and Pools
> 
> I agree with Eugene that the reasonable and fixed set of supported protocols
> will do the job for grizzly. The question then is which of the protocols should
> be there? My proposal is to include TCP, UDP, HTTP and HTTPS for now.
> 
> On Wed 23 Jan 2013 05:14:28 PM EET, Eugene Nikanorov wrote:
> > Roman,
> >
> > In the best case we should allow choosing all protocols that are
> > supported by drivers.
> > So this field should not be constrained at DB scheme level.
> > However I see an issue with that: currently LBaaS plugin is unaware of
> > list of drivers and only operates with logical model.
> > It's service agent which knows and loads drivers. So in order to
> > validate protocols based on drivers, plugin should load driver
> > classes, which implies that drivers are configured not only for
> > service agent, but for plugin as well.
> > That seems to be not very elegant solution.
> >
> > I'd suggest to make plugin poll agent for the list of supported
> > protocols (that may be not only protocols, but some other capabilities
> > as well) and then create a validation constraints based on that.
> > However it is too much to be implemented in grizzly, so i guess we may
> > just leave some reasonable fixed set of protocols.
> >
> > Thanks,
> > Eugene.
> >
> > On Wed, Jan 23, 2013 at 6:53 PM, Avishay Balderman
> > <AvishayB at radware.com <mailto:AvishayB at radware.com>> wrote:
> >
> >     I think the protocols should be an open set and each lbass driver
> >     will have to declare the members of this set.
> >     However when you create a VIP you do not know yet which driver
> >     will be selected by the lbass "engine", so maybe the protocol
> >     passed by the client can be used as another hint for driver selection.
> >     Avishay
> >
> >     -----Original Message-----
> >     From: Roman Prykhodchenko [mailto:rprikhodchenko at mirantis.com
> >     <mailto:rprikhodchenko at mirantis.com>]
> >     Sent: Wednesday, January 23, 2013 4:31 PM
> >     To: OpenStack Development Mailing List
> >     Subject: [openstack-dev] [Quantum] [LBaaS]Issues with supported
> >     protocols for VIPs and Pools
> >
> >     Hi folks,
> >
> >     Recently I discovered that it's impossible to specify TCP protocol
> >     when creating a VIP. After I started fixing that issue I found out
> >     that the problem is a little bit deeper and requires some
> >     assistance of the community to solve it.
> >     Currently it's impossible to specify TCP protocol when creating a
> >     VIP because only HTTP and HTTPS values are supported. However, you
> >     can create a Pool and supply any string value for it's protocol.
> >
> >     It's not too hard to add some constraints to the DB schema and to
> >     the REST API. The problem is that we do not know what protocols
> >     will be supported by the drivers and also we cannot predict that.
> >     I can see 3 possible solutions:
> >     1. Get rid of validation to allow specifying any value. This is
> >     not foolproof at all but provides the biggest flexibility.
> >     2. Modify the schema  and the API to support all basic protocols
> >     (HTTP, HTTPS, TCP, UDP, IP). This is foolproof but may cause a
> >     problem in the case when someone needs something extraordinary.
> >     3. Poll all configured drivers and add all supported protocols to
> >     the API. This will allow to have something extraordinary
> >     configured but we can only add constraints to the API but not to
> >     the database schema.
> >
> >     So, what do you think about this issue?
> >
> >
> >     - Roman Prykhodchenko
> >
> >
> >     _______________________________________________
> >     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
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev