Open Stack

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