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