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 <[email protected]
<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
