On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant <rbry...@redhat.com> wrote:
> 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. > > I couldn't have summed it up better than your last paragraph Russell. :) > -- > 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 >
__________________________________________________________________________ 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
