Open Stack

On 08/24/2015 07:33 AM, Kevin Benton wrote:
>  >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. :)

As Russell mentions, my idea of simple string tagging is that it is 
entirely user-driven (ala Launchpad's tagging of bugs -- there is no 
systemic collation or curation of tags).

If you need system-defined and protected attributes, you should use a 
separate resource on the network or port, ala the port binding profile, 
which to date has been (ab)used for the purpose of communicating 
backend-specific metadata.

Best,
-jay

> On Mon, Aug 24, 2015 at 6:35 AM, Russell Bryant <rbryant at redhat.com
> <mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Kevin Benton
>
>
> __________________________________________________________________________
> 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
>