I did miss his comment on the call. Do you remember?
Thx
Uri (“Oo-Ree”)
C: 949-378-7568
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Ed Warnicke
Sent: Friday, June 19, 2015 12:39 PM
To: Elzur, Uri
Subject: [Bug 1460222] Re: Add 'labels', a list of opaque strings, to the neutron 'port' object
@Peter: I would tend to agree... you probably see a first (semi-naive) poke at that in my examples (epg:<foo>) etc.
Could you say more about a mechanism you think might be useful for this?
Title:
Add 'labels', a list of opaque strings, to the neutron 'port' object
Status in OpenStack Neutron (virtual network service):
Triaged
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:
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:
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.
Watching the bug page like a hawk now....
I did miss his comment on the call. Do you remember?
Thx
Uri (“Oo-Ree”)
C: 949-378-7568
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Ed Warnicke
Sent: Friday, June 19, 2015 12:39 PM
To: Elzur, Uri
Subject: [Bug 1460222] Re: Add 'labels', a list of opaque strings, to the neutron 'port' object
@Peter: I would tend to agree... you probably see a first (semi-naive) poke at that in my examples (epg:<foo>) etc.
Could you say more about a mechanism you think might be useful for this?
-- /bugs.launchpad .net/bugs/ 1460222
You received this bug notification because you are subscribed to the bug report.
https:/
Title:
Add 'labels', a list of opaque strings, to the neutron 'port' object
Status in OpenStack Neutron (virtual network service):
Triaged
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
hints- by-reference by the neutron provider
Parameter: labels
Style: plain
Type: xsd:list
Description: A list of opaque strings to be interpreted as
*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:
{ firewall- 3" ],
"port": {
"labels": [ "vnf-type:
...
}
}
*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: /bugs.launchpad .net/neutron/ +bug/1460222/ +subscriptions
https:/