Traceback when accessing dcim/racks caused by racks with 0RU height

[amuckart]

I've just upgraded from 2.11.12 to 3.1.8 and was getting a traceback when I go to dcim/racks.

The server is Ubuntu 20.04.
Python version: 3.8.10
NetBox version: 3.1.8

The error was:

Internal Server Error: /dcim/racks/

TypeError at /dcim/racks/
'>=' not supported between instances of 'NoneType' and 'int'

Looking at the traceback it seems to be an issue with the rack utilisation graph:

  File "/opt/netbox-3.1.8/venv/lib/python3.8/site-packages/django/template/library.py", line 214, in render
    _dict = self.func(*resolved_args, **resolved_kwargs)
  File "/opt/netbox/netbox/utilities/templatetags/helpers.py", line 392, in utilization_graph
    if danger_threshold and utilization >= danger_threshold:

Exception Type: TypeError at /dcim/racks/
Exception Value: '>=' not supported between instances of 'NoneType' and 'int'

I narrowed the issue down to one site's racks. There are other sites with empty racks that properly show 0% utilisation. I could hit api/dcim/racks for the impacted site and they listed correctly.

Looking at the API output, there were two racks with height set to 0RU¹ which caused a div0 error when trying to view the rack in the UI.

I fixed this in the database but it seems like a thing that might be worth adding a constraint for since at some point it was obviously a technically valid (if dumb) thing to do.

1. This is thanks to old data from previous people's attempts to model things that are mounted on a wall not a rack by creating a "rack" for them. Lartings will be applied in due course.

[candlerb]

This is thanks to old data from previous people's attempts to model things that are mounted on a wall not a rack by creating a "rack" for them

Until fairly recently, that was the only way you locate a device at some position more specific than just "in this site".

Now you can create a "Location" within a site and associate a device with that, without having to associate it with a rack.

[jhammond-git]

I've run into issues similar to that when finding very old objects that were racked in a position but set to 0U. Ideally these are one-and-done issues for those of us with really old data and shouldn't be seen often enough to make code that manages it (knock-on-wood).