Comment 2 for bug 1460222

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
>