API to change the name of Link, Switch and Interface

[italovalcy]

Hello guys,

I trying to change the name of the switches, links and interfaces. I didnt find the API endpoints for that (at least not for switch and link). The names of the switches seems to be auto-filled from the DPID, the interfaces are filled with data coming from OF PortDesc message and the Links does not have “name” attribute.

From our discussion on Slack, it looks like the API does not have endpoints for that. Furthermore, the Link data structure does not include a name attribute.

Having the name for Switches, Links and Interfaces is very useful in many situations, such as: monitoring, where you can easily associate those items with others in your monitoring system sharing the same name; troubleshooting, the operator/admin usually choose names meaningful, which in case of a problem we easily and fast recognize where it is supposed to mean; documentation, since during the operation of the network the dpid may change, the link endpoints may change, an UNI may be moved to another interface, having the Name helps identify which context is associate with a particular item.

In summary, I would like to request a feature to:

1. Include a name attribute to the Link data structure
2. Create API endpoints to change the name for Link, Interface and Switch

Thanks in advance!

[beraldoleal]

Hi @italovalcy, thanks for bringing this up.

AFAICT, switches don't have a .name property in the class.

If my memory is correct, name is just an alias for id (dpid). Users could have custom names or custom properties via metadata. metadata field was designed to store any key,value by users.

metadata was enabled on all 3 main classes that we have: switch, link, and interface for that reason: to avoid adding many attributes to those main classes.

@cmagnobarbosa, @rmotitsuki:

Can you guys, please double-check if today we allow metadata update via REST?

[italovalcy]

Hi guys, Hi @beraldoleal,

Thanks for the explanation and ideas! I was aware of the metadata, however I thought that the name is something more important and as so deserves to be defined as a specific field. By defining the name in a specific field, the napps and ui can benefit from it to refer to the same object (without having to worry about naming conventions to the name property).

Two use cases would be: 1) the UI displaying objects by name (switch, link, interface, etc) and even allowing to create EVC based on a name of the switch instead of typing the whole datapath-id; 2) tools that might use Kytos later (e.g. evc_manager - https://pypi.org/project/evc-manager/) allowing the network operator to define the path based on the name of the links instead of the ID or the endpoints.

If you guys think the name property should go into the metadata, maybe it would be a good idea to have a standard field for that (name? displayName? alias?).

Thanks, Italo

[beraldoleal]

Hi @italovalcy I still think that metadata is the best place for it. Each protocol/application has its own "more important" properties. And if we keeping adding those properties there, then we will end up with a huge number of attributes.

UIs can search on metadata as well.

name (no camel case) is my vote.

[italovalcy]

Hi @beraldoleal, thank you for the feedback! I agree with the proposed solution. I also vote for name. I will check the ui then to see how can we start using metadata/name if present. Thank you!