Representation of cable managers, blanks, etc. in racks #319

@aaronpetak commented on GitHub (Aug 3, 2016):

I agree, having the ability to add different sized cable managers to the rack will be a huge help (or other objects that don't need to be devices). Right now, some of my racks looks very empty and the percentage of rack space free reflects that. In reality, I have put cable managers above/below equipment so my usage is much higher.

@aaronpetak commented on GitHub (Aug 3, 2016): I agree, having the ability to add different sized cable managers to the rack will be a huge help (or other objects that don't need to be devices). Right now, some of my racks looks very empty and the percentage of rack space free reflects that. In reality, I have put cable managers above/below equipment so my usage is much higher.

adam commented

@jeremystretch commented on GitHub (Aug 3, 2016):

As I see it we have two options. One option is to extend the Device model so that it can represent a "dumb" device without any console, power, or network components. This means suppressing every instance of several built-in fields (tenant, platform, serial, etc.).

The other option is to introduce a new model to represent rack "furniture." Like devices, instances of this model would consume rack space, but they would have only a type field indicating their basic function (cable manager, blank panel, etc.).

The second option seems more appealing to me, but it does complicate the logic needed to determine rack utilization and to validate the installation of a device within a rack.

@jeremystretch commented on GitHub (Aug 3, 2016): As I see it we have two options. One option is to extend the Device model so that it can represent a "dumb" device without any console, power, or network components. This means suppressing every instance of several built-in fields (tenant, platform, serial, etc.). The other option is to introduce a new model to represent rack "furniture." Like devices, instances of this model would consume rack space, but they would have only a `type` field indicating their basic function (cable manager, blank panel, etc.). The second option seems more appealing to me, but it does complicate the logic needed to determine rack utilization and to validate the installation of a device within a rack.

adam commented

@NetBod commented on GitHub (Aug 3, 2016):

Option 2 sounds good to me, in the DC's I work in they fill any space U with blanking plates to improve air flow and cooling.

@NetBod commented on GitHub (Aug 3, 2016): Option 2 sounds good to me, in the DC's I work in they fill any space U with blanking plates to improve air flow and cooling.

adam commented

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

@bsakdol commented on GitHub (Aug 3, 2016):

I agree with option 2 as well. The blanking plates for airflow/cooling brings up an interesting point, though. Some of these physical objects should be factored into the rack utilization logic, while other objects should not. In the instance of a cable manager, this should be factored in because it is a permanent object (in a sense). In the instance of a blank panel, it should not be factored into utilization because it is merely a temporary object to be removed in place of a "device" or more permanent object.

Since I imagine this would complicate the rack utilization logic even further and defeating the purpose of being able to visualize an accurate count of free space in a rack, I would see two options:
1. We all blame me for bringing more complexity into this topic and agree it would be on the user to not insert objects that don't actually factor into rack utilization (i.e. don't create an object for a blank panel).
2. A checkbox or category (i.e. 'permanent' or 'temporary') is implemented and the rack utilization logic takes that into account on whether to factor the object in or not.

Personally, I am in favor of just leaving it up to the user (which begs the question of why I tempt fate by bringing up the other option as viable).

@bsakdol commented on GitHub (Aug 3, 2016): I agree with option 2 as well. The blanking plates for airflow/cooling brings up an interesting point, though. Some of these physical objects should be factored into the rack utilization logic, while other objects should not. In the instance of a cable manager, this should be factored in because it is a permanent object (in a sense). In the instance of a blank panel, it should not be factored into utilization because it is merely a temporary object to be removed in place of a "device" or more permanent object. Since I imagine this would complicate the rack utilization logic even further and defeating the purpose of being able to visualize an accurate count of free space in a rack, I would see two options: 1. We all blame me for bringing more complexity into this topic and agree it would be on the user to not insert objects that don't actually factor into rack utilization (i.e. don't create an object for a blank panel). 2. A checkbox or category (i.e. 'permanent' or 'temporary') is implemented and the rack utilization logic takes that into account on whether to factor the object in or not. Personally, I am in favor of just leaving it up to the user (which begs the question of why I tempt fate by bringing up the other option as viable).

adam commented

@csfreak commented on GitHub (Aug 3, 2016):

The concern I have with option two is that it might complicate #20. Certainly this needs to be considered in that light as it is not a far stretch in my mind from cable management to patch panel.

A second thought on that matter is making sure that such furniture can occupy zero u space, or any other subset of U that is supported in the future based on #51. If I am tracking all my cable management arms, would be nice to track my zero u ones for inventory purposes. (I. E. I bought 30 of product X, where did they all go?)

@csfreak commented on GitHub (Aug 3, 2016): The concern I have with option two is that it might complicate [#20](https://github.com/digitalocean/netbox/issues/20). Certainly this needs to be considered in that light as it is not a far stretch in my mind from cable management to patch panel. A second thought on that matter is making sure that such furniture can occupy zero u space, or any other subset of U that is supported in the future based on [#51](https://github.com/digitalocean/netbox/issues/51). If I am tracking all my cable management arms, would be nice to track my zero u ones for inventory purposes. (I. E. I bought 30 of product X, where did they all go?)

adam commented

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

@bsakdol commented on GitHub (Aug 3, 2016):

While I see your argument for zero RU objects and knowing where something ends up, that would be a different topic, in my eyes, maybe in the form of an inventory management tracking feature that goes deeper than serialized gear. What I had hoped to accomplish by adding rack objects/rack furniture is a more accurate rack utilization metric, as seen on the Racks page, as well as a reflection on the visual display. These objects would not constitute free space in a rack, so they should not be calculated as such.

@bsakdol commented on GitHub (Aug 3, 2016): While I see your argument for zero RU objects and knowing where something ends up, that would be a different topic, in my eyes, maybe in the form of an inventory management tracking feature that goes deeper than serialized gear. What I had hoped to accomplish by adding rack objects/rack furniture is a more accurate _rack utilization_ metric, as seen on the _Racks_ page, as well as a reflection on the visual display. These objects would not constitute free space in a rack, so they should not be calculated as such.

adam commented

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

@Oorweeg commented on GitHub (Sep 28, 2016):

I think this feature is important for something was going to raise separately when I came across this thread, and that is rack-space reservations.

We need a way of showing rack-space as utilised and unavailable without actually having equipment installed and this seems to essentially be the same issue as the one raised for things like cable blanks in this thread.

So +1 on this feature being added :)

@Oorweeg commented on GitHub (Sep 28, 2016): I think this feature is important for something was going to raise separately when I came across this thread, and that is rack-space reservations. We need a way of showing rack-space as utilised and unavailable without actually having equipment installed and this seems to essentially be the same issue as the one raised for things like cable blanks in this thread. So +1 on this feature being added :)

adam commented

@puck commented on GitHub (Sep 28, 2016):

On the suggestion of having a simplified DeviceType that suppresses most of the fields, if that goes a head, please keep Tenant. If my tenants decide to have cable management rails, blanks or whatever else, I'll still charge them for the U's occupied.

@puck commented on GitHub (Sep 28, 2016): On the suggestion of having a simplified DeviceType that suppresses most of the fields, if that goes a head, please keep Tenant. If my tenants decide to have cable management rails, blanks or whatever else, I'll still charge them for the U's occupied.

adam commented

@0racle commented on GitHub (Mar 31, 2017):

I came here to also request this feature. These 'furniture' items should be non-unique, ie. I want to be able to place multiple shelf or cable mgmt items in a single rack without having to define unique names.

With regards with rack utilisation, I'd be happy with these items counting towards utilisation, but if that is untenable for others, perhaps utilisation could show green bar for devices, and an additional bit of yellow (or grey or whatever) bar for the dumb/furniture items?

@0racle commented on GitHub (Mar 31, 2017): I came here to also request this feature. These 'furniture' items should be non-unique, ie. I want to be able to place multiple `shelf` or `cable mgmt` items in a single rack without having to define unique names. With regards with rack utilisation, I'd be happy with these items counting towards utilisation, but if that is untenable for others, perhaps utilisation could show green bar for devices, and an additional bit of yellow (or grey or whatever) bar for the dumb/furniture items?

adam commented

@ghost commented on GitHub (Aug 23, 2017):

In order to get some visual representation of structured cabling I'm currently using a unique reference (DC code - rack # - RU#) and tacking the destination on the end. I'd quite like a Cabling type of device that doesn't need a dedicated unique name (I'm already using unnamed devices for things like cable managed) but that can reference some connectivity details in the rack view - perhaps even if unnamed devices showed the Notes field in rack view instead of the device type?

(orange is fiber, yellow is copper)

@ghost commented on GitHub (Aug 23, 2017): In order to get some visual representation of structured cabling I'm currently using a unique reference (DC code - rack # - RU#) and tacking the destination on the end. I'd quite like a Cabling type of device that doesn't need a dedicated unique name (I'm already using unnamed devices for things like cable managed) but that can reference some connectivity details in the rack view - perhaps even if unnamed devices showed the Notes field in rack view instead of the device type? (orange is fiber, yellow is copper) ![screenshot from 2017-08-23 14-48-36](https://user-images.githubusercontent.com/10701177/29596645-2dbfb1f6-8812-11e7-88e2-284d48eea33d.png)

adam commented

@AnythingOverIP commented on GitHub (Oct 18, 2017):

As @bradical987 mentionned, It would be useful to have the notion of "usable v/s unusable" when dealing with accessories. Blank plates used for improving airflow are not represented currently in our rack elevations as they are technically not used, but when it's used for blocking access to a (or many) specific RU, or cannot be removed without some redesign (like Cable Management unit), we add it. In the current form, we had to create a generic device without connectivity, and label device uniquely although they are generic. The last part is what bugs us most...

@AnythingOverIP commented on GitHub (Oct 18, 2017): As @bradical987 mentionned, It would be useful to have the notion of "usable v/s unusable" when dealing with accessories. Blank plates used for improving airflow are not represented currently in our rack elevations as they are technically not used, but when it's used for blocking access to a (or many) specific RU, or cannot be removed without some redesign (like Cable Management unit), we add it. In the current form, we had to create a generic device without connectivity, and label device uniquely although they are generic. The last part is what bugs us most...

adam commented

@lampwins commented on GitHub (Oct 28, 2017):

I have started to work on this. Following with what @jeremystretch has said, the scope of this feature has been limited to rack furniture. Patch panels and the like will be covered in #20.

@lampwins commented on GitHub (Oct 28, 2017): I have started to work on this. Following with what @jeremystretch has said, the scope of this feature has been limited to rack furniture. Patch panels and the like will be covered in #20.

adam commented

@paravoid commented on GitHub (Dec 15, 2017):

Any news here? Is #1657 something that has serious chances of getting merged? We're contemplating migrating a bunch of data to Netbox very soon now, and I was wondering if we could avoid doing a Device->Furniture migration later :)

@paravoid commented on GitHub (Dec 15, 2017): Any news here? Is #1657 something that has serious chances of getting merged? We're contemplating migrating a bunch of data to Netbox very soon now, and I was wondering if we could avoid doing a Device->Furniture migration later :)

adam commented

@iDemonix commented on GitHub (Jan 22, 2018):

As above, any news on the PR? I'm currently migrating 5 data centres worth of rack diagrams in to NetBox and would love to be adding furniture rather than leaving gaps to do later? Thanks :)

@iDemonix commented on GitHub (Jan 22, 2018): As above, any news on the PR? I'm currently migrating 5 data centres worth of rack diagrams in to NetBox and would love to be adding furniture rather than leaving gaps to do later? Thanks :)

adam commented

@collin-clark commented on GitHub (Jan 22, 2018):

For patch panels, cable mgt, etc I created a generic device, e.g Panduit WMPH2E. I then add it to a rack, but I do not give it a name. I can then re-use the device over and over again (as long as you don't give it a name).

@collin-clark commented on GitHub (Jan 22, 2018): For patch panels, cable mgt, etc I created a generic device, e.g Panduit WMPH2E. I then add it to a rack, but I do not give it a name. I can then re-use the device over and over again (as long as you don't give it a name). ![image](https://user-images.githubusercontent.com/13089867/35230948-136dbbdc-ff5d-11e7-8787-909a2e2515e7.png)

adam commented

@lampwins commented on GitHub (Jan 22, 2018):

@paravoid @iDemonix #1657 is still open at this point, but @jeremystretch has indicated that may not be the way we want to go with this. Essentially #1657 implements a new model for Furniture, thus duplicating some of the rack logic. At this point, the only other viable solution I can think of is to suppress fields and logic on the existing Device model. IMHO I want to avoid this, but ultimately not my call. If anyone else any any ideas for a data model, I am willing to try implementing it.

ATM, @collin-clark's method is the method most people are using, including myself (short of just leaving furniture out). Whatever the implementation for this feature winds up being, that should allow for a straightforward (albeit manual) migration.

@lampwins commented on GitHub (Jan 22, 2018): @paravoid @iDemonix #1657 is still open at this point, but @jeremystretch has indicated that may not be the way we want to go with this. Essentially #1657 implements a new model for Furniture, thus duplicating some of the rack logic. At this point, the only other viable solution I can think of is to suppress fields and logic on the existing Device model. IMHO I want to avoid this, but ultimately not my call. If anyone else any any ideas for a data model, I am willing to try implementing it. ATM, @collin-clark's method is the method most people are using, including myself (short of just leaving furniture out). Whatever the implementation for this feature winds up being, that should allow for a straightforward (albeit manual) migration.

adam commented

@lampwins commented on GitHub (Jan 22, 2018):

IMHO we just need to make the validation logic for rack installation abstract, as #20 is surly to also introduce at lease some of the same rack requirements as this feature.

@lampwins commented on GitHub (Jan 22, 2018): IMHO we just need to make the validation logic for rack installation abstract, as #20 is surly to also introduce at lease some of the same rack requirements as this feature.

adam commented

@iDemonix commented on GitHub (Jan 22, 2018):

Ahh that's a shame, this one looked like it had promise. What is the method @CorinneLSmith is using?

@iDemonix commented on GitHub (Jan 22, 2018): Ahh that's a shame, this one looked like it had promise. What is the method @CorinneLSmith is using?

adam commented

@lampwins commented on GitHub (Jan 22, 2018):

Sorry, the name selector got me, that was @collin-clark

@lampwins commented on GitHub (Jan 22, 2018): Sorry, the name selector got me, that was @collin-clark

adam commented

@lampwins commented on GitHub (May 24, 2018):

I was thinking about this some on a plane ride and believe we would greatly benefit from re-engineering the relationship between Device and Rack. Today, Device directly stores a foreign key to Rack and contains a U position within the rack. This leads to some fairly obtuse logic for calculating rack usage, and provisioning Rack Reservations to use a different flow than assigning a Device to a rack position.

The point is, the flow is tailored to Devices. The problem is, in order to accommodate this issue as well as #20, we (probably) need new models beyond Device. For this reason, I propose an intermediary model between a rack (position) and a rackable item (Device, Reservation, this FR, and any models needed for #20).

I propose a so-called RackUnit model. This model will contain the FK to the Rack, bottom-most rack unit of that rack, and the U height of the item this RackUnit represents within the rack. A rackable model (e.g. Device) will contain a FK (probably OneToOne in this case) to the RackUnit.

This will allow us to move the utilization logic out of the Rack model while at the same time abstracting that logic from its dependence on specific models (Device). So we can do all of the caluculation based on the Rack Unit without caring what is actually racked.

/--------\
| Device | <------------------
\--------/                   |          /----------\            /------\
                             ---------> | RackUnit |----------> | Rack |
/--------------------\       |          \----------/            \------/
| RackReservation    | <------
\--------------------/       |
                             |
/---------------\            |
| RackFurniture | <-----------
\---------------/

I strongly feel re-engineering this relationship and the underlying logic will set us up for success down the road.

@lampwins commented on GitHub (May 24, 2018): I was thinking about this some on a plane ride and believe we would greatly benefit from re-engineering the relationship between Device and Rack. Today, Device directly stores a foreign key to Rack and contains a U position within the rack. This leads to some fairly obtuse logic for calculating rack usage, and provisioning Rack Reservations to use a different flow than assigning a Device to a rack position. The point is, the flow is tailored to Devices. The problem is, in order to accommodate this issue as well as #20, we (probably) need new models beyond Device. For this reason, I propose an intermediary model between a rack (position) and a rackable item (Device, Reservation, this FR, and any models needed for #20). I propose a so-called `RackUnit` model. This model will contain the FK to the Rack, bottom-most rack unit of that rack, and the U height of the item this `RackUnit` represents within the rack. A rackable model (e.g. Device) will contain a FK (probably OneToOne in this case) to the RackUnit. This will allow us to move the utilization logic out of the Rack model while at the same time abstracting that logic from its dependence on specific models (Device). So we can do all of the caluculation based on the Rack Unit without caring what is actually racked. ``` /--------\ | Device | <------------------ \--------/ | /----------\ /------\ ---------> | RackUnit |----------> | Rack | /--------------------\ | \----------/ \------/ | RackReservation | <------ \--------------------/ | | /---------------\ | | RackFurniture | <----------- \---------------/ ``` I strongly feel re-engineering this relationship and the underlying logic will set us up for success down the road.

adam commented

@deadflanders commented on GitHub (Jun 30, 2018):

I would like to see a "RackFurniture" option as well! Right now I'm just adding them as devices, but one problem I have is if I add two 1RU Cable Organizers, I can't give them both a name of "1RU Cable Organzier" because the name has to be unique in NetBox. AND if I don't enter a name, then NetBox shows the Device Role in the rack view. This isn't that great because I have a category called Furniture that I use for things like Cable Brush Strips, and Cable Organizers, etc.. But then in the rack view I just see Furniture listed for various items. Would be better if Device Type showed in rack view, instead of Device Role, or even better, if I could for Furniture the Device Name didn't need to be unique so that I could put in a name like Brush Strip.

@deadflanders commented on GitHub (Jun 30, 2018): I would like to see a "RackFurniture" option as well! Right now I'm just adding them as devices, but one problem I have is if I add two 1RU Cable Organizers, I can't give them both a name of "1RU Cable Organzier" because the name has to be unique in NetBox. AND if I don't enter a name, then NetBox shows the Device Role in the rack view. This isn't that great because I have a category called Furniture that I use for things like Cable Brush Strips, and Cable Organizers, etc.. But then in the rack view I just see Furniture listed for various items. Would be better if Device Type showed in rack view, instead of Device Role, or even better, if I could for Furniture the Device Name didn't need to be unique so that I could put in a name like Brush Strip.

adam commented

@mrintegrity commented on GitHub (Sep 19, 2018):

Ability to mark a unit as unusable would be great, some of our racks have been so badly cabled that units are unavailable due to power / copper cables running inside the rail

@mrintegrity commented on GitHub (Sep 19, 2018): Ability to mark a unit as unusable would be great, some of our racks have been so badly cabled that units are unavailable due to power / copper cables running inside the rail

adam commented

@lampwins commented on GitHub (Nov 13, 2018):

NetBox v2.5.0 has made a significant change to the DeviceType model in that the boolean fields is_network_device, is_console_server, and is_pdu have been removed. With this change, when a new DeviceType is created, it is instantiated with no expectation of what, if any components will be added to it. This means it is now possible to create true "empty" device types. This is semantically what we are trying to achieve with this FR. I argue that as of v.2.5.0, this FR has been fulfilled.

I am open to ideas about UI enhancements related to furniture, but I feel those should be opened as new issues.

The open PR for this issue (#1657) would require totally rewriting at this point, but as I have just stated, I don't see much point in this.

cc: @jeremystretch

@lampwins commented on GitHub (Nov 13, 2018): NetBox v2.5.0 has made a significant change to the DeviceType model in that the boolean fields `is_network_device`, `is_console_server`, and `is_pdu` have been removed. With this change, when a new DeviceType is created, it is instantiated with no expectation of what, if any components will be added to it. This means it is now possible to create true "empty" device types. This is semantically what we are trying to achieve with this FR. I argue that as of v.2.5.0, this FR has been fulfilled. I am open to ideas about UI enhancements related to furniture, but I feel those should be opened as new issues. The open PR for this issue (#1657) would require totally rewriting at this point, but as I have just stated, I don't see much point in this. cc: @jeremystretch

adam commented