On 08/24/2015 09:35 AM, Russell Bryant wrote: > 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." >
There's an updated version of that nova spec here: http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/tag-instances.html -- Russell Bryant __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
