Open Stack

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>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]
> 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
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/0aa8be28/attachment.html>