Open Stack

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