[openstack-dev] [Neutron][LBaaS] API proposal review thoughts

Carlos Garza carlos.garza at rackspace.com
Fri May 9 18:10:02 UTC 2014


On May 9, 2014, at 3:26 AM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>
 wrote:

Carlos,

The general objection is that if we don't need multiple VIPs (different ip, not just tcp ports) per single logical loadbalancer, then we don't need loadbalancer because everything else is addressed by VIP playing a role of loadbalancer.

    Thats pretty much our objection. You seem to be masquerading vips as if they were loadbalancers. APIs that don't model reality are not a good fit as far as were concerned.

    We do not recognize the logical connection between "we will use a loadbalancer top level object if and only if it will contain multiple ports or vips". We view this as a straw man attempt to get those in favor of a loadbalancer top level object to some how reform an argument that we now need multiple ports, vips etc which isn't what we are arguing at all.

I have no doubt that even if we ever did have a use case for this you'll just reject the use case or come up with another bizarre constraint as to why we "Don't need a loadbalancer top level object".
That was never the argument we were trying to make in the first place.

Regarding conclusions - I think we've heard enough negative opinions on the idea of 'container' to at least postpone this discussion to the point when we'll get some important use cases that could not be addressed by 'VIP as loadbalancer'

    We haven't really heard any "Negative opinions" other that what is coming from you and Sam. And it looks like Sam's objection is that he has predefined physical loadbalancers already sitting on a rack. For example if he has a rack of 8 physical loadbalancers then he only has 8 loadbalancer_ids and that are shared by many users and for some reason this is locking him into the belief that he shouldn't expose loadbalancer objects directly to the customer. This is some what alien to us as we also have physicals in our CLB1.0 product but we still use the notion of loadbalancer objects that are shared across a single sting ray host. We don't equate a loadbalancer with an actual sting ray host.

    If same needs help wrapping a virtual loadbalancer object in his API let us know we would like to help with that as we firmly know its awkward to take something such as neutron/lbaas and interpret it to be "Virtual Ips as a service.  We've done that with our API in CLB1.0.

    Carlos.

Eugene.

On Fri, May 9, 2014 at 8:33 AM, Carlos Garza <carlos.garza at rackspace.com<mailto:carlos.garza at rackspace.com>> wrote:

On May 8, 2014, at 2:45 PM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:

Hi Carlos,

    Are you saying that we should only have a loadbalancer resource only in the case where we want it to span multiple L2 networks as if it were a router? I don't see how you arrived at that conclusion. Can you explain further.
No, I mean that loadbalancer instance is needed if we need several *different* L2 endpoints for several front ends.
That's basically 'virtual appliance' functionality that we've discussed on today's meeting.

   From looking at the irc log it looks like nothing conclusive came out of the meeting. I don't understand a lot of the conclusions you arrive at. For example your rejecting the notion of a loadbalancer concrete object unless its needed to include multi l2 network support. Will you make an honest effort to describe your objections here in the ML cause if we can't resolve it here its going to spill over into the summit. I certainly don't want this to dominate the summit.



Eugene.
_______________________________________________
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<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/20140509/6da7e618/attachment.html>


More information about the OpenStack-dev mailing list