Comment 10 for bug 1460222

So, this kind of arbitrary metadata on objects has been rejected in the past, and the solution that is currently in the works is neutron flavors. They are defined here:
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/neutron-flavor-framework.rst

... with a further enhancement here:
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/neutron-flavor-framework-templates.rst

The short-form is that it allows attaching meta-data to any neutron object, if the operator configures it, and then the backend plugins/drivers can access it as described above. So you'd end up having an operator defining an "ODL firewall-3" port flavor, or an "ODL policy:blue" port flavor, and if that flavor is used for the port, it'd include that metadata.

In this scheme, operators must pre-define the flavors they want. I expect vendors will provide pre-canned flavors or templates, but this was the compromise that was acceptable in the last release in terms of letting operators be the ones to choose if they want to break object interoperability.