+1 I will alter the proposed spec to indicate that this shouldn't be consumed/used with backends specific data (similar to the way Nova tags indicate it)
I see value (and described some use cases in the spec) for using this from the API level Gal. On Mon, Aug 24, 2015 at 4:35 PM, Russell Bryant <[email protected]> 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." > > -- > 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 > -- Best Regards , The G.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
