Similar, though I am looking for a list of strings, and only think I need
them on ports.
(I would not object to something similar on other objects of that was
helpful to folks).

Happy to have you tweet wording, feel free :)

Ed

On Friday, May 29, 2015, Armando Migliaccio <email address hidden>
wrote:

> I'll try to tweak the title wording/examples a bit, but I gather that
> all you need is to ability to qualify a port based on a list of
> attributes or metadata that do not necessarily need to be understood or
> processed by the Neutron platform. A bit like proposal [1], where all we
> wanted to do is to tag resources in a way that's meaningful to an
> external party, human or otherwise. Am I on the right track?
>
> [1] https://review.openstack.org/#/c/134069
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1460222
>
> Title:
>   Add 'labels', a list of opaque strings, to the neutron 'port' object
>
> Status in OpenStack Neutron (virtual network service):
>   Confirmed
>
> Bug description:
>   *What is being requested*
>
>   This request is to add an attribute 'labels' to the neutron 'port'
>   object.  The type of 'labels' is a list of strings.
>
>   *Why is it being requested*
>
>   There are many use cases in which you wish to provide hint-by-
>   reference to downstream providers of neutron services (like
>   controllers) for which you would like to allow the user to provide
>   hint-by-reference about the nature of the port and the service it
>   should receive.
>
>   In the parlance of the Neutron API Documentation:
>
>   Object: ports
>   Parameter: labels
>   Style: plain
>   Type: xsd:list
>   Description: A list of opaque strings to be interpreted as
>                hints-by-reference by the neutron provider
>
>
>   *Examples*
>
>   1)  Indicate the Network Policy that should be applied to the port.
> Most network policy systems resolve policy based upon the
>   'Endpoint Group(s)' (abbreviated EPGs) and Endpoint (think port)
> (abbreviated EP) is placed in.  'labels' could be used to indicate EPG
> membership for a port.  For example:
>
>   {
>     "port": {
>         "labels": [ "epg:blue", "epg:green" ],
>          ...
>      }
>   }
>
>   2)  Indicate the type of Virtual Network Function (VNF) of the VM
>   being deployed on the port.  This would be important for a controller
>   rendering Service Function Chains (SFCs) to know so that it knew it
>   had additional VNFs of that type to use in the SFCs it was
>   constructing.  For example:
>
>   {
>     "port": {
>         "labels": [ "vnf-type:firewall-3" ],
>          ...
>      }
>   }
>
>   *Who needs it*
>
>   This is needed to assist the OpenDaylight Controller in being able to
>   better provide the Policy and SFC services.  However, this mechanism
>   is agnostic as to the underlying controller, and also can be used for
>   a variety of other useful purposes.  Anywhere that it would be useful
>   to pass on hints-by-reference to downstream providers could take
>   advantage of it.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1460222/+subscriptions
>