Open Stack

Hi Brandon,


I, too, have not heard clear and concise reasons why the core team
> members would not like a logical load balancer object, or a load
> balancer object that maps to many vips, which in turn maps to many
> listeners.  I've been to every LBaaS meeting for months now I think, and
> I just remember that you and others have said the core team members
> object to it, but not any clear reasons.  Would it be possible for you
> to point us to an IRC chat log or a ML thread that does discuss that?
>
Well, It seems to me that I understood that reason.
The reason was formulated as 'networking functions, not virtualized
appliances'.
Loadbalancer object as a concept of virtual appliance (which Stephen and
Carlos seem to be advocating)
is not a kind of concept neutron tries to expose via its API. To me it
looks like a valid argument.
Yes, some users may expect that API will give them control of their
super-dedicated LB appliance.
Also, having API that looks like API of *typical* appliance may look more
familiar to users who moved from
operating physical lb appliance. But that's not the kind of ability neutron
tries to allow, letting user to work with
more abstracted concepts instead.

>
> A lot of operators have come into this project lately and most (if not
> all) would prefer an API construct like the one BBG and Rackspace have
> agreed on.  This reason alone should be enough to revisit the topic with
> the core team members so we operators can fully understand their
> objections.  I believe operators should play a large role in Openstack
> and their opinions and reasons why should be heard.
>
I agree that operator's concerns need  to be addressed, but the argument
above just suggest that it can be done
by other means rather then providing 'virtual appliance' functionality.
I think it will be more constructive to think and work in this direction.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140511/d4b3a772/attachment.html>