Request cable tag field for all connection types #734

@quentindavid commented on GitHub (Feb 28, 2017):

look at #20

@quentindavid commented on GitHub (Feb 28, 2017): look at #20

adam commented

@jeremystretch commented on GitHub (Feb 28, 2017):

This is indeed covered by the mega-feature request of #20, but I'll comment:

The reason we don't include a cable label field on a connection is that a connection will likely comprise more than one physical cable. For example, an interface might connect to a patch panel, which connects to another patch panel, and finally to the peer interface. We want to ensure that we can support this model in the future, so we omit the concept of labeling for now to avoid future confusion.

@jeremystretch commented on GitHub (Feb 28, 2017): This is indeed covered by the mega-feature request of #20, but I'll comment: The reason we don't include a cable label field on a connection is that a connection will likely comprise more than one physical cable. For example, an interface might connect to a patch panel, which connects to another patch panel, and finally to the peer interface. We want to ensure that we can support this model in the future, so we omit the concept of labeling for now to avoid future confusion.

adam commented

@quentindavid commented on GitHub (Feb 28, 2017):

Hi @jeremystretch, I understand, but a first "simple" solution would be to allow the naming of connections, without consideration for "patch panels".
By the way, could we just imagine patch panels like any other device, with connections from and to it ?

@quentindavid commented on GitHub (Feb 28, 2017): Hi @jeremystretch, I understand, but a first "simple" solution would be to allow the naming of connections, without consideration for "patch panels". By the way, could we just imagine patch panels like any other device, with connections from and to it ?

adam commented

@jeremystretch commented on GitHub (Feb 28, 2017):

but a first "simple" solution would be to allow the naming of connections, without consideration for "patch panels".

Unfortunately, today's "simple" solution inevitably becomes tomorrow's technical debt. If cable labeling is a must-have feature for you, NetBox simply isn't the right solution (yet).

could we just imagine patch panels like any other device, with connections from and to it?

There are two concepts in which we consider links: logically and physically. The logical concept entails the end-to-end connection as an atomic unit; e.g. eth0 on device A connected to ge-0/0/12 on device B. This is what NetBox models today.

The physical concept exists in parallel as a sort of underlay. In this model, we'd track individual cables, patch panels, etc. It would be extremely inefficient to have to parse the physical model only to determine the two logical endpoints of a connection, so we want to model it separately. Additionally, we need a model capable of expressing the many nuances of a cabling plant. For example, we should be able to define a patch panel which has LC fiber connections on the front, and MPO trunks on the back, and still be able to trace a single pair through it.

@jeremystretch commented on GitHub (Feb 28, 2017): > but a first "simple" solution would be to allow the naming of connections, without consideration for "patch panels". Unfortunately, today's "simple" solution inevitably becomes tomorrow's technical debt. If cable labeling is a must-have feature for you, NetBox simply isn't the right solution (yet). > could we just imagine patch panels like any other device, with connections from and to it? There are two concepts in which we consider links: logically and physically. The logical concept entails the end-to-end connection as an atomic unit; e.g. eth0 on device A connected to ge-0/0/12 on device B. This is what NetBox models today. The physical concept exists in parallel as a sort of underlay. In this model, we'd track individual cables, patch panels, etc. It would be extremely inefficient to have to parse the physical model only to determine the two logical endpoints of a connection, so we want to model it separately. Additionally, we need a model capable of expressing the many nuances of a cabling plant. For example, we should be able to define a patch panel which has LC fiber connections on the front, and MPO trunks on the back, and still be able to trace a single pair through it.

adam commented

@quentindavid commented on GitHub (Feb 28, 2017):

I understand, then would it be possible to give an ID to each connection, in a logical point of view ?
Because as I understand, another model to create and to implement is not really easy and quickly possible ^^

Thanks a lot for your work ;)

@quentindavid commented on GitHub (Feb 28, 2017): I understand, then would it be possible to give an ID to each connection, in a logical point of view ? Because as I understand, another model to create and to implement is not really easy and quickly possible ^^ Thanks a lot for your work ;)

adam commented

@flyingrhinonz commented on GitHub (Feb 28, 2017):

Thanks for the responses.

How about the option of adding a custom field to the connection? In this way it is not directly tied to netbox development, yet allows us to manage cable tags.
It's possible to add a custom field to many other tables in netbox, and I assume that every custom field is treated as external data. Therefore, if you allowed us to add a text field to connections (searchable please), then it would serve our purpose, and at the same time not impede any future netbox roadmap.

BTW, in our company, if a cable connects from a server to a switch to another switch to a server, these are counted as 3 separate cables , each cable with a unique tag (identical at it's own two ends).

In any case, netbox is awesome, and without it - we'd be using xls and txt files. Great work !

@flyingrhinonz commented on GitHub (Feb 28, 2017): Thanks for the responses. How about the option of adding a custom field to the connection? In this way it is not directly tied to netbox development, yet allows us to manage cable tags. It's possible to add a custom field to many other tables in netbox, and I assume that every custom field is treated as external data. Therefore, if you allowed us to add a text field to connections (searchable please), then it would serve our purpose, and at the same time not impede any future netbox roadmap. BTW, in our company, if a cable connects from a server to a switch to another switch to a server, these are counted as 3 separate cables , each cable with a unique tag (identical at it's own two ends). In any case, netbox is awesome, and without it - we'd be using xls and txt files. Great work !

adam commented

@quentindavid commented on GitHub (Mar 1, 2017):

indeed, a custom field would be enough :)

@quentindavid commented on GitHub (Mar 1, 2017): indeed, a custom field would be enough :)

adam commented

@flyingrhinonz commented on GitHub (Mar 2, 2017):

I'm liking the idea of a custom field.
This should not in any way interfere with netbox roadmap.

What's better - Should I open a new issue for this request, or should this thread be reopened ?

Thanks.

Together we'll make a good thing even better !

@flyingrhinonz commented on GitHub (Mar 2, 2017): I'm liking the idea of a custom field. This should not in any way interfere with netbox roadmap. What's better - Should I open a new issue for this request, or should this thread be reopened ? Thanks. Together we'll make a good thing even better !

adam commented

@jeremystretch commented on GitHub (Mar 2, 2017):

We will not be adding custom fields to interface connections. As discussed, support for labels will be added as part of #20.

@jeremystretch commented on GitHub (Mar 2, 2017): We will not be adding custom fields to interface connections. As discussed, support for labels will be added as part of #20.

adam commented

@MeisiCB commented on GitHub (Mar 4, 2018):

@quentindavid If your really want the Cable ID (now), just fork this project and change this files:

Made with Version 2.3.1

Change the Database:
ALTER TABLE public.dcim_interfaceconnection ADD COLUMN connection_comments text;
Change File netbox/netbox/dcim/forms.py
Before Line 2052 (class Meta: model = InterfaceConnection ) insert
connection_comments = forms.CharField(max_length=100, required=False, label='Cable ID')

some lines below change
fields = ['interface_a', 'site_b', 'rack_b', 'device_b', 'interface_b', 'livesearch', 'connection_status']
to
fields = ['interface_a', 'site_b', 'rack_b', 'device_b', 'interface_b', 'livesearch', 'connection_status','connection_comments']

Change File netbox/netbox/dcim/models.py
After Line 1518 (connection_status = models.Boolean ...) insert

connection_comments = models.TextField(blank=True)

Change File netbox/netbox/templates/dcim/inc/interface.html
On Line 50 change
{{ connected_iface }}
to

                 <span title="{{ connected_iface.get_form_factor_display }}">{{ connected_iface }}
               {% if iface.connection.connection_comments %}
                   Cable ID: {{ iface.connection.connection_comments }}
               {% endif %}
               </span>

Change File netbox/netbox/templates/dcim/interfaceconnection_edit.html
After Line 82 ( {% render_field form.connection_status ...) insert

{% render_field form.connection_comments %}

Restart Python:
service supervisor restart

You will get this:

@MeisiCB commented on GitHub (Mar 4, 2018): @quentindavid If your really want the Cable ID (now), just fork this project and change this files: Made with Version 2.3.1 1. Change the Database: ALTER TABLE public.dcim_interfaceconnection ADD COLUMN connection_comments text; 2. Change File netbox/netbox/dcim/forms.py Before Line 2052 (class Meta: model = InterfaceConnection ) insert `connection_comments = forms.CharField(max_length=100, required=False, label='Cable ID') ` some lines below change fields = ['interface_a', 'site_b', 'rack_b', 'device_b', 'interface_b', 'livesearch', 'connection_status'] to `fields = ['interface_a', 'site_b', 'rack_b', 'device_b', 'interface_b', 'livesearch', 'connection_status','connection_comments']` 3. Change File netbox/netbox/dcim/models.py After Line 1518 (connection_status = models.Boolean ...) insert `connection_comments = models.TextField(blank=True) ` 4. Change File netbox/netbox/templates/dcim/inc/interface.html On Line 50 change ` {{ connected_iface }}` to ``` {{ connected_iface }} {% if iface.connection.connection_comments %} Cable ID: {{ iface.connection.connection_comments }} {% endif %} ``` 5. Change File netbox/netbox/templates/dcim/interfaceconnection_edit.html After Line 82 ( {% render_field form.connection_status ...) insert ` {% render_field form.connection_comments %} ` 6. Restart Python: service supervisor restart You will get this: ![netbox-1](https://user-images.githubusercontent.com/34491421/36951104-b9790b90-1fff-11e8-8f85-c030f4e4a635.png) ![netbox-2](https://user-images.githubusercontent.com/34491421/36951107-bdd055cc-1fff-11e8-8bcf-030c2d64b2aa.png)

adam commented

@flyingrhinonz commented on GitHub (Mar 5, 2018):

Thanks for the tip. I'll try that out.
Meanwhile I already did my own workaround last year by putting the cable IDs into the interface name. It doesn't search, but it does give visibility. At present I have many machines in netbox commented this way.

@flyingrhinonz commented on GitHub (Mar 5, 2018): Thanks for the tip. I'll try that out. Meanwhile I already did my own workaround last year by putting the cable IDs into the interface name. It doesn't search, but it does give visibility. At present I have many machines in netbox commented this way.

adam commented

@martin8883 commented on GitHub (Apr 18, 2018):

Thank you for the workaround, works great.
Until #20 is done here an addition to show the Cable ID in the interface connection table:
In file netbox/netbox/dcim/tables.py add after line 594 (in v2.3.2) (interface_b = tables.Column(verbose_name='Interface B'))
connection_comments = tables.Column(verbose_name='Cable ID')
and change following
fields = ('device_a', 'interface_a', 'device_b', 'interface_b')
to
fields = ('device_a', 'interface_a', 'device_b', 'interface_b', 'connection_comments')

@martin8883 commented on GitHub (Apr 18, 2018): Thank you for the workaround, works great. Until #20 is done here an addition to show the Cable ID in the interface connection table: In file netbox/netbox/dcim/tables.py add after line 594 (in v2.3.2) (interface_b = tables.Column(verbose_name='Interface B')) `connection_comments = tables.Column(verbose_name='Cable ID')` and change following `fields = ('device_a', 'interface_a', 'device_b', 'interface_b')` to `fields = ('device_a', 'interface_a', 'device_b', 'interface_b', 'connection_comments')`

adam commented

@Atoms commented on GitHub (Jul 4, 2018):

our use case would be mark connections created by script so script does not delete manually created connections, manually created connections in our case is cause not all our devices provide LLDP

@Atoms commented on GitHub (Jul 4, 2018): our use case would be mark connections created by script so script does not delete manually created connections, manually created connections in our case is cause not all our devices provide LLDP

adam commented