Open Stack

> 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.

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.

Thanks,
doug



> On Aug 24, 2015, at 12:26 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 
> On 08/24/2015 01:58 PM, Jay Pipes wrote:
>> On 08/24/2015 07:33 AM, Kevin Benton wrote:
>>>> Obviously it'll still be possible to be used by a backend, but it's
>>> also possible to patch the code or provide arbitrary API extensions, too.
>>> 
>>> 
>>> Right, but vendor API extensions are the way that backend-specific
>>> features are supposed to be done. With an extension, it's explicit in
>>> the API via the extensions list that something non-standard is enabled.
>>> 
>>> Patching code is currently pretty brittle and puts a lot of technical
>>> debt on a driver author's part so it's pretty obvious to the author that
>>> it's not the right way to go. Once we add these tags, they will be part
>>> of the API so they should be stable and will be tempting to use for lots
>>> of stuff. :)
>> 
>> As Russell mentions, my idea of simple string tagging is that it is
>> entirely user-driven (ala Launchpad's tagging of bugs -- there is no
>> systemic collation or curation of tags).
>> 
>> If you need system-defined and protected attributes, you should use a
>> separate resource on the network or port, ala the port binding profile,
>> which to date has been (ab)used for the purpose of communicating
>> backend-specific metadata.
> 
> Yeah, I think the port binding profile is a good example of something
> not to repeat.
> 
> I took advantage of it to prototype a feature here:
> 
> http://docs.openstack.org/developer/networking-ovn/containers.html
> 
> It let me implement a backend specific feature quickly and expose it
> through the Neutron API.  It would be very easy to just call it done and
> move on.  However, the right thing to do is to define a proper Neutron
> API to express what is needed, so that other backends can implement the
> same thing.
> 
> Luckily, it's being covered by the following effort and once it's in
> place, I can remove this prototype hack.
> 
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
> 
> -- 
> Russell Bryant
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev