<div dir="ltr">Hi everybody!<div><br></div><div>In Neutron the idea of adding tags to resources has come up several times this cycle alone.[1][2][3]</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>1. <a href="https://bugs.launchpad.net/neutron/+bug/1460222">https://bugs.launchpad.net/neutron/+bug/1460222</a></div><div>2. <a href="https://bugs.launchpad.net/neutron/+bug/1483480">https://bugs.launchpad.net/neutron/+bug/1483480</a></div><div>3. <a href="https://review.openstack.org/#/c/216021/">https://review.openstack.org/#/c/216021/</a><br clear="all"><div><br></div><div><br></div><div>Cheers</div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div></div>