On May 9, 2014, at 3:26 AM, Eugene Nikanorov
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> wrote:
On May 8, 2014, at 2:45 PM, Eugene Nikanorov
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
