Display a floorplan of all racks in a site #81

New Issue

adam · 2025-12-29T15:31:45+01:00

adam commented

2025-12-29 15:31:45 +01:00

Originally created by @fourg on GitHub (Jun 29, 2016).

Ability to drag and drop existing racks within a site to create their physical topology. Bonus points for displaying how many free U's each rack has.

Originally created by @fourg on GitHub (Jun 29, 2016). Ability to drag and drop existing racks within a site to create their physical topology. Bonus points for displaying how many free U's each rack has.

adam added the plugin candidate label 2025-12-29 15:31:45 +01:00

adam closed this issue

2025-12-29 15:31:45 +01:00

adam commented

2025-12-29 15:31:46 +01:00

@bellwood commented on GitHub (Jun 29, 2016):

I've already have this setup in a customeware application I wrote.

I make use of pgSQL's point coordinates for storing the location of racks, CRV's, UPS's on a grid and then displaying racks, birds eye with:

rack temp color adjusted by chromatic scale with a hover graph to show the last 10 temp points for trending
clickable icons for switches in the racks that modal to show interfaces, toggle control, port descriptions, vlan information
pdu's in the rack and the power they are consuming
crv's showing input and output temps and humidity
UPS input and output + battery state and runtime

its all realtime with AJAX and SNMP

Get ahold me in the IRC channel if anyone wants to discuss this further as it's something I've thought about adding to netbox since I saw the reddit thread.

@bellwood commented on GitHub (Jun 29, 2016): I've already have this setup in a customeware application I wrote. I make use of pgSQL's point coordinates for storing the location of racks, CRV's, UPS's on a grid and then displaying racks, birds eye with: 1) rack temp color adjusted by chromatic scale with a hover graph to show the last 10 temp points for trending 2) clickable icons for switches in the racks that modal to show interfaces, toggle control, port descriptions, vlan information 3) pdu's in the rack and the power they are consuming 4) crv's showing input and output temps and humidity 5) UPS input and output + battery state and runtime its all realtime with AJAX and SNMP Get ahold me in the IRC channel if anyone wants to discuss this further as it's something I've thought about adding to netbox since I saw the reddit thread.

adam commented

2025-12-29 15:31:47 +01:00

@ryanmerolle commented on GitHub (Jun 30, 2016):

A room / bird's eye view makes sense. We may need to first address how to relate rooms, private cages, or floors in the same site. You may want to only take a birds eye view by these sub-units/groups.

@ryanmerolle commented on GitHub (Jun 30, 2016): A room / bird's eye view makes sense. We may need to first address how to relate rooms, private cages, or floors in the same site. You may want to only take a birds eye view by these sub-units/groups.

adam commented

2025-12-29 15:31:47 +01:00

@bellwood commented on GitHub (Jul 15, 2016):

Yes, you'd ideally want to limit the display to each "rack group" - which for us is a single containment pod but could be anything.

Realistically you are only limited to screen real-estate for what you want to show however there are other considerations if you want live data:

-will the data come live or from a stored system that is polling (like rrdtool)

-if its coming live, how many devices are you calling live and what impact that may have on your network

My implementation does everything live via ajax (we are relatively small) but at scale that simply doesn't work.

My thought for my next version was to use cacti to collect all the data and pull it to the interface with command line calls to rra's, however that means adding devices in two places and also doing all graph templating with cacti and a slew of other things.

It certainly would be an advanced implementation to add live/delayed data to the overview but not impossible.

Simply displaying the visual layout though is real easy, involving some CSS and placement decisions based on grid.

Each rackUnit (yeah bad name) in my pgsql table (which consists of 'types' e.g rack, gap, ups, battery, bypass, transformer, cooler, etc) has a "coord" field that is (x,y) (field type is point) and I display my rackUnits out where:

0,0 is top left -> 0,n
1,0 is bottom left -> 1,n

...this is per rackGroup.

Based on the type and facility ID for those items I have CSS classes setup to handle the display for that item.

@bellwood commented on GitHub (Jul 15, 2016): Yes, you'd ideally want to limit the display to each "rack group" - which for us is a single containment pod but could be anything. Realistically you are only limited to screen real-estate for what you want to show however there are other considerations if you want live data: -will the data come live or from a stored system that is polling (like rrdtool) -if its coming live, how many devices are you calling live and what impact that may have on your network My implementation does everything live via ajax (we are relatively small) but at scale that simply doesn't work. My thought for my next version was to use cacti to collect all the data and pull it to the interface with command line calls to rra's, however that means adding devices in two places and also doing all graph templating with cacti and a slew of other things. It certainly would be an advanced implementation to add live/delayed data to the overview but not impossible. Simply displaying the visual layout though is real easy, involving some CSS and placement decisions based on grid. Each rackUnit (yeah bad name) in my pgsql table (which consists of 'types' e.g rack, gap, ups, battery, bypass, transformer, cooler, etc) has a "coord" field that is (x,y) (field type is `point`) and I display my rackUnits out where: 0,0 is top left -> 0,n 1,0 is bottom left -> 1,n ...this is per rackGroup. Based on the type and facility ID for those items I have CSS classes setup to handle the display for that item.

adam commented

2025-12-29 15:31:47 +01:00

@ollyg commented on GitHub (Jul 18, 2016):

I thought the idea of netbox is not to have live or polled data but to be an authoritative source of truth curated by a human. I would really like to see this feature but it need only be the room view exactly as @ryanmerolle said. Then we could browse down from the org level to each data centre space or room and then down to the rack level.

@ollyg commented on GitHub (Jul 18, 2016): I thought the idea of netbox is not to have live or polled data but to be an authoritative source of truth curated by a human. I would really like to see this feature but it need only be the room view exactly as @ryanmerolle said. Then we could browse down from the org level to each data centre space or room and then down to the rack level.

adam commented

2025-12-29 15:31:48 +01:00

@bellwood commented on GitHub (Jul 18, 2016):

One of the tenets of netbox is to document things as they exist in the real world.

So auto-polling interfaces, assuming connections, etc is not done.

The temperature of a rack, of the runtime of a UPS battery string, are real world items and critical to DCIM. These are also things that change external to human interaction unlike adding a physical server, wiring a switch, etc so the only way to provide that data (if netbox wanted) would be the aforementioned.

My previous reply was simply shared to provide insight as to how I accomplished my needs for our software.

@bellwood commented on GitHub (Jul 18, 2016): One of the tenets of netbox is to document things as they exist in the real world. So auto-polling interfaces, assuming connections, etc is not done. The temperature of a rack, of the runtime of a UPS battery string, are real world items and critical to DCIM. These are also things that change external to human interaction unlike adding a physical server, wiring a switch, etc so the only way to provide that data (if netbox wanted) would be the aforementioned. My previous reply was simply shared to provide insight as to how I accomplished my needs for our software.

adam commented

2025-12-29 15:31:48 +01:00

@Armadill0 commented on GitHub (Nov 10, 2016):

Awesome, searching for "map" instead of "overview" was to easy to find this issue, sorry. 😄

@Armadill0 commented on GitHub (Nov 10, 2016): Awesome, searching for "map" instead of "overview" was to easy to find this issue, sorry. :smile:

adam commented

2025-12-29 15:31:49 +01:00

@candlerb commented on GitHub (Feb 7, 2017):

As well as "bird eye view" I'd also like a front and back view of all the racks in a site or rack group. At the moment you can only get this one rack at a time.

@candlerb commented on GitHub (Feb 7, 2017): As well as "bird eye view" I'd also like a front and back view of all the racks in a site or rack group. At the moment you can only get this one rack at a time.

adam commented

2025-12-29 15:31:50 +01:00

@snowie-swe commented on GitHub (Aug 4, 2018):

Would be very nice to see a basic layout picture next to the rack

@snowie-swe commented on GitHub (Aug 4, 2018): Would be very nice to see a basic layout picture next to the rack ![image](https://user-images.githubusercontent.com/41901413/43674221-a870bb6a-97d0-11e8-9298-acbf6c04da7a.png)

adam commented

2025-12-29 15:31:51 +01:00

@Ricaz commented on GitHub (Sep 20, 2018):

@bellwood, have you made any further progress on this? Any work you would like to share? I'm looking at implementing this in our setup in the coming week.

@Ricaz commented on GitHub (Sep 20, 2018): @bellwood, have you made any further progress on this? Any work you would like to share? I'm looking at implementing this in our setup in the coming week.

adam commented

2025-12-29 15:31:52 +01:00

@bellwood commented on GitHub (Oct 1, 2018):

I have it working based on some static data, however, until FR #20 and #1044 are completed and we can move away from 6connect entirely Netbox remains a backwater project in my org.

<.02>Netbox really needs a version(s) dedicated to catching up on the legacy requests. </.02>

@bellwood commented on GitHub (Oct 1, 2018): I have it working based on some static data, however, until FR #20 and #1044 are completed and we can move away from 6connect entirely Netbox remains a backwater project in my org. <.02>Netbox really needs a version(s) dedicated to catching up on the legacy requests. </.02>

adam commented

2025-12-29 15:31:53 +01:00

@ndom91 commented on GitHub (Nov 16, 2018):

Yeah I'd really like something like this as well - Im somewhat handy with front end web dev stuff as well so I am more than happy to help!

@ndom91 commented on GitHub (Nov 16, 2018): Yeah I'd really like something like this as well - Im somewhat handy with front end web dev stuff as well so I am more than happy to help!

adam commented

2025-12-29 15:31:53 +01:00

@tb-killa commented on GitHub (Jan 10, 2019):

@jeremystretch: Question: Is this extension really implemented in Netbox (Core) or should it appear as an extension ?
I'm asking because the JS based site topology map was rejected back then (#1827) and this is ultimately a similar extension.

We would be happy if the floorplans would actually come.

@tb-killa commented on GitHub (Jan 10, 2019): @jeremystretch: Question: Is this extension really implemented in Netbox (Core) or should it appear as an extension ? I'm asking because the JS based site topology map was rejected back then (#1827) and this is ultimately a similar extension. We would be happy if the floorplans would actually come.

adam commented

2025-12-29 15:31:53 +01:00

@DanSheps commented on GitHub (Jan 10, 2019):

@tb-killa #1827 is an extension to the topology map, this is more of a site rack/rack group layout, which is slightly different and more similar to the current front-view rack layout.

@DanSheps commented on GitHub (Jan 10, 2019): @tb-killa #1827 is an extension to the topology map, this is more of a site rack/rack group layout, which is slightly different and more similar to the current front-view rack layout.

adam commented

2025-12-29 15:31:54 +01:00

@tb-killa commented on GitHub (Jan 10, 2019):

@DanSheps thanks for your answer.
This sounds nice.

@tb-killa commented on GitHub (Jan 10, 2019): @DanSheps thanks for your answer. This sounds nice.

adam commented

2025-12-29 15:31:54 +01:00

@tb-killa commented on GitHub (Feb 9, 2019):

Hi @jeremystretch:
I´m thinking about a simple solution to get this feature implemented:

First of all.. what is the exactly need of a "floorplan" ?
Normaly as we want to document "DataCenter" we doesn´t use the Term of "Floorplan" as we use the Term of DataCenterGrid.

How to build DataCenterGrid ?
I would use as simple as possible the function from bootstrap themselve to draw the "grid".
Maybe extension with allow upload of big background graphic?

But first .. on which point we could build our DataCenterGrid ?
We need a starting point with a input field who you could define number of rows and columns who define the "Size" of your DataCenter.
Does we use this on the "Site" or should we define a new Implementation with Django and call the App "DataCenter-Visualisation" ?
This need some Linkings too from Site and Rackgroup and Racks.

@tb-killa commented on GitHub (Feb 9, 2019): Hi @jeremystretch: I´m thinking about a simple solution to get this feature implemented: First of all.. what is the exactly need of a "floorplan" ? Normaly as we want to document "DataCenter" we doesn´t use the Term of "Floorplan" as we use the Term of DataCenterGrid. How to build DataCenterGrid ? I would use as simple as possible the function from bootstrap themselve to draw the "grid". Maybe extension with allow upload of big background graphic? But first .. on which point we could build our DataCenterGrid ? We need a starting point with a input field who you could define number of rows and columns who define the "Size" of your DataCenter. Does we use this on the "Site" or should we define a new Implementation with Django and call the App "DataCenter-Visualisation" ? This need some Linkings too from Site and Rackgroup and Racks.

adam commented

2025-12-29 15:31:55 +01:00

@Xelinor commented on GitHub (Feb 9, 2019):

So, one of the major problems I think with this is that Sites & Rack Groups mean very different things to different implementations. For my implementation for example, we use sites to be various campuses and Rack Groups to denote the floor and building. Then the rack Facility ID tells us where the physical rack is located, such as 145.36 meaning room 1, row 45, rack 36.

It's more then likely that we will need entirely new fields to track location, and ALSO will need to track Hot/Cold aisles since that isn't always standard either, and then there are POD based cooling systems as well as more I'm sure I'm not aware of...implementing this probably represents some fairly major changes. Not necessarily bad ones, but ones that should definitely be thought through carefully.

@Xelinor commented on GitHub (Feb 9, 2019): So, one of the major problems I think with this is that Sites & Rack Groups mean very different things to different implementations. For my implementation for example, we use sites to be various campuses and Rack Groups to denote the floor and building. Then the rack Facility ID tells us where the physical rack is located, such as 145.36 meaning room 1, row 45, rack 36. It's more then likely that we will need entirely new fields to track location, and ALSO will need to track Hot/Cold aisles since that isn't always standard either, and then there are POD based cooling systems as well as more I'm sure I'm not aware of...implementing this probably represents some fairly major changes. Not necessarily bad ones, but ones that should definitely be thought through carefully.

adam commented

2025-12-29 15:31:55 +01:00

@DanSheps commented on GitHub (Jul 3, 2019):

Please do not ask for updates to feature requests. They will be released when they are released.

@DanSheps commented on GitHub (Jul 3, 2019): Please do not ask for updates to feature requests. They will be released when they are released.

adam commented

2025-12-29 15:31:56 +01:00

@jeremystretch commented on GitHub (May 8, 2020):

This is one of our oldest feature requests, and to be honest I just don't see it ever becoming a priority.

I'm going to close this out as a core feature request, however I do think it would make an excellent plugin. Hopefully someone in the community will take interest in building it.

@jeremystretch commented on GitHub (May 8, 2020): This is one of our oldest feature requests, and to be honest I just don't see it ever becoming a priority. I'm going to close this out as a core feature request, however I do think it would make an excellent [plugin](https://netbox.readthedocs.io/en/stable/plugins/development/). Hopefully someone in the community will take interest in building it.

adam referenced this issue

2025-12-29 15:35:29 +01:00

Implement pluggable extensions #155

adam referenced this issue

2025-12-29 16:26:03 +01:00

Email notification with change summary #815

adam referenced this issue

2025-12-29 16:26:04 +01:00

Email notification with change summary #815

adam referenced this issue

2025-12-29 16:26:52 +01:00

Convert UserAction logging to use signals #905