Open Stack

+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 <rbryant at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/3929e53e/attachment.html>