<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/24/2015 05:25 PM, Doug Wiegley wrote:<br>
>> I took advantage of it to prototype a feature her<br>
><br>
> That right there is the crux of the objections so far. Don’t get me<br>
> wrong, I’d love this, and would abuse it within an inch of its life<br>
> regularly.<br>
><br>
> The alternative is sometimes even worse than a vendor extension or<br>
> plugin.  Take for example, wanting to add a new load balancing<br>
> algorithm, like LEAST_MURDERED_KITTENS. The current list is<br>
> hard-coded all over the dang place, so you end up shipping neutron<br>
> patches or monkey patches. Opaque pass-through to the driver is evil<br>
> from an interoperability standpoint, but in terms of extending code<br>
> at the operators choosing, there are MUCH worse sins that are<br>
> actively being committed.<br>
<br>
</span>I don't think even worse code makes this what's proposed here seem any<br>
better.  I'm not really sure what you're saying.<br>
<span class=""><br>
> Flavors covers this use case, but in a way that’s up to the operators<br>
> to setup, and not as easy for devs to deal with.<br>
><br>
> Whether the above sounds like it’s a bonus or a massive reason not to<br>
> do this will entirely lie in the eye of the beholder, but the vendor<br>
> extension use case WILL BE USED, no matter what we say.<br>
<br>
</span>Interop really is a key part of this.  If we look at this particular<br>
case, yes, I get that there are lots of LB algorithms out there and that<br>
it makes sense to expose that choice to users.  However, I do think<br>
what's best for users is to define and document each of them very<br>
explicitly.  The end user should know that if they choose algorithm<br>
BEST_LB_EVER, that it means the same thing on cloud A vs cloud B.  The<br>
way to do that is to have it defined explicitly by Neutron and not punt.<br>
<br>
Maybe in practice the Neutron defined set is a subset of what's<br>
available overall, and the custom (vendor) ones can be clearly marked as<br>
such.  In any case, I'm just trying to express what goal I think we<br>
should be striving for.<br>
<br>
In general, the fight in Neutron *has* to be about common definitions of<br>
networking primitives that can be potentially implemented by multiple<br>
backends whenever possible.  That's the entire point of Neutron.  I get<br>
that it's hard, but that's the value Neutron brings to the table.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I couldn't have summed it up better than your last paragraph Russell. :)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
--<br>
Russell Bryant<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>