[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