[openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

Russell Bryant rbryant at redhat.com
Mon Aug 24 21:43:26 UTC 2015


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



More information about the OpenStack-dev mailing list