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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev