Open Stack

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