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

Russell Bryant rbryant at redhat.com
Mon Aug 24 13:35:48 UTC 2015


On 08/24/2015 09:25 AM, Kevin Benton wrote:
> Hi everybody!
> 
> In Neutron the idea of adding tags to resources has come up several
> times this cycle alone.[1][2][3]
> 
> The general concern that has led to them being rejected is that backends
> will leverage these tags to leak implementation details or
> backend-specific features (e.g. tags that control QoS features, security
> isolation, or other network behaviors).
> 
> However, there are many use cases that make these nice for the users of
> the API to help organize resources (e.g. external DNS names on floating
> IPs, PCI compliance status of security groups, an emoticon describing
> the seriousness of the things on that network, etc).
> 
> I'm beginning to think that it might be worth it for the usefulness it
> brings to the end users. But with all of the third-party plugins
> out-of-tree, we essentially have no way to stop them from using the tags
> to control the networking backend as well.
> 
> So I'm looking for feedback from the API working group as well as other
> projects that have gone down this path. Should we just take the pythonic
> "we're all adults" approach and try to encourage backends not to use
> them for network behavior? Or does this carry too much risk of being
> abused as a shortcut to avoid developing proper API enhancements by
> backend devs?
> 
> 1. https://bugs.launchpad.net/neutron/+bug/1460222
> 2. https://bugs.launchpad.net/neutron/+bug/1483480
> 3. https://review.openstack.org/#/c/216021/

If this is clearly documented as being a API consumer thing only, then
I'm OK with it.  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.

The plugins may be out of tree, but the ones officially a part of
Neutron still are under oversight of the Neutron PTL/team.  Using this
in a way it's explicitly documented as not to be used would be an
example of a case where they should be asked to change.

We can't control what backends not a part of Neutron do, but that's not new.

One example of another project doing something similar is this:

http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html

Note this important line:

"The tag is an opaque string and is not intended to be interpreted or
even read by the virt drivers."

-- 
Russell Bryant



More information about the OpenStack-dev mailing list