Open Stack

>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.


Right, but vendor API extensions are the way that backend-specific features
are supposed to be done. With an extension, it's explicit in the API via
the extensions list that something non-standard is enabled.

Patching code is currently pretty brittle and puts a lot of technical debt
on a driver author's part so it's pretty obvious to the author that it's
not the right way to go. Once we add these tags, they will be part of the
API so they should be stable and will be tempting to use for lots of stuff.
:)


On Mon, Aug 24, 2015 at 6:35 AM, 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/23fa0ef1/attachment.html>