<div dir="ltr">Hi Brandon,<div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I, too, have not heard clear and concise reasons why the core team<br>

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

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