Add an interfaces list view #2925

@candlerb commented on GitHub (Oct 28, 2019):

Adding an explicit 'interfaces' view opens the door to importing interfaces as CSV, which was requested as #822 (and #1492 for virtual machines)

@candlerb commented on GitHub (Oct 28, 2019): Adding an explicit 'interfaces' view opens the door to importing interfaces as CSV, which was requested as #822 (and #1492 for virtual machines)

adam commented

@candlerb commented on GitHub (Nov 7, 2019):

Just found another use case for this: I wanted to view which MAC addresses I have stored in Netbox.

@candlerb commented on GitHub (Nov 7, 2019): Just found another use case for this: I wanted to view which MAC addresses I have stored in Netbox.

adam commented

@candlerb commented on GitHub (Nov 7, 2019):

The example export above doesn't work with virtualmachines.

The admin interface does let you create an export template for dcim > interfaces, so I made this:

name,device,virtual_machine,type,enabled,mac_address,mtu,mgmt_only
{%- for i in queryset %}
{{i.name}},{{i.device}},{{i.virtual_machine}},{{i.type}},{{i.enabled}},{{i.mac_address}},{{i.mtu}},{{i.mgmt_only}}
{%- endfor %}

However, the GUI doesn't appear to have anywhere to run it :-(

If I manually create the URL /dcim/interfaces/?export=foo I get a 404. As was recently mentioned elsewhere, I don't think the API allows you to run an export either.

Workaround is to use nbshell:

>>> print(ExportTemplate.objects.get(name="foo").render(Interface.objects.all()))

@candlerb commented on GitHub (Nov 7, 2019): The example export above doesn't work with virtualmachines. The admin interface _does_ let you create an export template for `dcim > interfaces`, so I made this: ``` name,device,virtual_machine,type,enabled,mac_address,mtu,mgmt_only {%- for i in queryset %} {{i.name}},{{i.device}},{{i.virtual_machine}},{{i.type}},{{i.enabled}},{{i.mac_address}},{{i.mtu}},{{i.mgmt_only}} {%- endfor %} ``` However, the GUI doesn't appear to have anywhere to run it :-( If I manually create the URL `/dcim/interfaces/?export=foo` I get a 404. As was recently mentioned elsewhere, I don't think the API allows you to *run* an export either. Workaround is to use nbshell: ``` >>> print(ExportTemplate.objects.get(name="foo").render(Interface.objects.all())) ```

adam commented

@darcynz commented on GitHub (Nov 7, 2019):

Thanks Brian! Forgot about VM's, That export will be handy!

@darcynz commented on GitHub (Nov 7, 2019): Thanks Brian! Forgot about VM's, That export will be handy!

adam commented

@hellerve commented on GitHub (Nov 15, 2019):

We have a working version of interface lists (including filters and so on) in our fork of NetBox.

Did we agree on only doing this for interfaces for now instead of other device components? If so, I’d happily provide the code that we have. If not this should also not be a big problem for us to implement!

EDIT: Oh, I see @DanSheps already volunteered to work on this. Sorry about that!

@hellerve commented on GitHub (Nov 15, 2019): We have a working version of interface lists (including filters and so on) in our fork of NetBox. Did we agree on only doing this for interfaces for now instead of other device components? If so, I’d happily provide the code that we have. If not this should also not be a big problem for us to implement! EDIT: Oh, I see @DanSheps already volunteered to work on this. Sorry about that!

adam commented

@DanSheps commented on GitHub (Nov 15, 2019):

I think we should definitely do all views.

@DanSheps commented on GitHub (Nov 15, 2019): I think we should definitely do all views.

adam commented

@TheRealBecks commented on GitHub (Nov 15, 2019):

@hellerve @DanSheps Maybe working together could lead into a faster result?

@TheRealBecks commented on GitHub (Nov 15, 2019): @hellerve @DanSheps Maybe working together could lead into a faster result?

adam commented

@steffann commented on GitHub (Nov 21, 2019):

Looks good! I did notice that for interfaces the "Device" column is empty when an interface belongs to a VM. Might be useful to change that column to "Device/VM".

@steffann commented on GitHub (Nov 21, 2019): Looks good! I did notice that for interfaces the "Device" column is empty when an interface belongs to a VM. Might be useful to change that column to "Device/VM".

adam commented

@steffann commented on GitHub (Nov 21, 2019):

Also: while playing with it I found the order of the columns a bit confusing. I would suggest the following order (basically moving Device to the front):

Device/VM
Name
Type
Connection status
Cable

@steffann commented on GitHub (Nov 21, 2019): Also: while playing with it I found the order of the columns a bit confusing. I would suggest the following order (basically moving Device to the front): - Device/VM - Name - Type - Connection status - Cable

adam commented

@candlerb commented on GitHub (Nov 21, 2019):

I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded.

(Aside: it seems that connection status as an attribute of the interface is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?)

@candlerb commented on GitHub (Nov 21, 2019): I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded. (Aside: it seems that connection status as an attribute of the *interface* is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?)

adam commented

@darcynz commented on GitHub (Nov 21, 2019):

My initial thought was that the interface list would be similar to what you see on a device (name, description, mtu, mode, cable, connection etc) but that would be too verbose.

Could interface description fit? At a glance this could be quite important as often it shows purpose of the interface.

Also perhaps showing interface 'enabled' could quite helpful.

@darcynz commented on GitHub (Nov 21, 2019): My initial thought was that the interface list would be similar to what you see on a device (name, description, mtu, mode, cable, connection etc) but that would be too verbose. Could interface description fit? At a glance this could be quite important as often it shows purpose of the interface. Also perhaps showing interface 'enabled' could quite helpful.

adam commented

@steffann commented on GitHub (Nov 21, 2019):

(Aside: it seems that connection status as an attribute of the interface is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?)

The attribute on the interface is basically a cache. It's set when any cable in the path is changed, and its value is based on the status of all the cables on the path. It will only show as connected if all cables are connected and there is a remote endpoint. So not as useless as it seems :)

@steffann commented on GitHub (Nov 21, 2019): > (Aside: it seems that connection status as an attribute of the _interface_ is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?) The attribute on the interface is basically a cache. It's set when any cable in the path is changed, and its value is based on the status of all the cables on the path. It will only show as connected if all cables are connected and there is a remote endpoint. So not as useless as it seems :)

adam commented

@candlerb commented on GitHub (Nov 21, 2019):

I think description should be included. This would be consistent with /ipam/ipaddresses and /ipam/prefixes which also include description. /dcim/devices doesn't - but devices and VMs have "comments" rather than "description".

If screen estate is a problem, then one option would be switchable views:

a regular view with Device/VM, Name, Type, Description (Enabled?) (Mgmt Only?) (Cable?)
a technical view, with Device/VM, Name, Type, MTU, MAC address, VLAN mode, VLANs

@candlerb commented on GitHub (Nov 21, 2019): I think description should be included. This would be consistent with `/ipam/ipaddresses` and `/ipam/prefixes` which also include description. `/dcim/devices` doesn't - but devices and VMs have "comments" rather than "description". If screen estate is a problem, then one option would be switchable views: - a regular view with Device/VM, Name, Type, Description (Enabled?) (Mgmt Only?) (Cable?) - a technical view, with Device/VM, Name, Type, MTU, MAC address, VLAN mode, VLANs

adam commented

@candlerb commented on GitHub (Nov 21, 2019):

Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-(

@candlerb commented on GitHub (Nov 21, 2019): Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-(

adam commented

@DanSheps commented on GitHub (Nov 25, 2019):

I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded.

I am trying to keep the view very generic at this point in time. In the future we can look at expanding the columns.

If screen estate is a problem, then one option would be switchable views:

This is going to be beyond the scope of the current issue. This would have to wait, most likely for a major UI revamp.

Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-(

This is going to maintain consistency with other list views more or less.

@DanSheps commented on GitHub (Nov 25, 2019): > I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded. I am trying to keep the view very generic at this point in time. In the future we can look at expanding the columns. > If screen estate is a problem, then one option would be switchable views: This is going to be beyond the scope of the current issue. This would have to wait, most likely for a major UI revamp. > Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-( This is going to maintain consistency with other list views more or less.

adam commented

@jeremystretch commented on GitHub (Nov 25, 2019):

Regarding tags: I agree that it would nice to include them, but right now we're constrained by the use of HTML tables for most object lists. Ideally, tags should appear below the standard fields to ensure they don't force excessive wrapping of other fields. This would be best approached by converting to a more flexible rendering mechanism, but obviously that won't be trivial as it likely entails ditching django-tables2.

@jeremystretch commented on GitHub (Nov 25, 2019): Regarding tags: I agree that it would nice to include them, but right now we're constrained by the use of HTML tables for most object lists. Ideally, tags should appear below the standard fields to ensure they don't force excessive wrapping of other fields. This would be best approached by converting to a more flexible rendering mechanism, but obviously that won't be trivial as it likely entails ditching django-tables2.

adam commented