Rack Types #137

New Issue

adam · 2025-12-29T15:34:48+01:00

adam commented

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

Originally created by @peelman on GitHub (Jul 1, 2016).

Might it be beneficial to add a RackType to define if a rack is 2-post, 4-post, enclosed, wall-mounted, etc?

Originally created by @peelman on GitHub (Jul 1, 2016). Might it be beneficial to add a RackType to define if a rack is 2-post, 4-post, enclosed, wall-mounted, etc?

adam closed this issue

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

adam commented

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

@systo commented on GitHub (Jul 1, 2016):

Also, for 2 post racks, would you want to disable the "back" view of the rack in the UI, seems a good way to intuitively know that a rack is 2 or 4 post visually.

@systo commented on GitHub (Jul 1, 2016): Also, for 2 post racks, would you want to disable the "back" view of the rack in the UI, seems a good way to intuitively know that a rack is 2 or 4 post visually.

adam commented

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

@jeremystretch commented on GitHub (Jul 6, 2016):

So, would something like this work as an additional field on the Rack model?

RACK_TYPES = (
    (RACK_TYPE_2POST, "2-post frame"),
    (RACK_TYPE_4POST, "4-post frame"),
    (RACK_TYPE_CABINET, "4-post cabinet"),
    (RACK_TYPE_WALLFRAME, "Wall-mounted frame"),
    (RACK_TYPE_WALLCABINET, "Wall-mounted cabinet"),
)

Are there other types we want to include?

@jeremystretch commented on GitHub (Jul 6, 2016): So, would something like this work as an additional field on the `Rack` model? ``` RACK_TYPES = ( (RACK_TYPE_2POST, "2-post frame"), (RACK_TYPE_4POST, "4-post frame"), (RACK_TYPE_CABINET, "4-post cabinet"), (RACK_TYPE_WALLFRAME, "Wall-mounted frame"), (RACK_TYPE_WALLCABINET, "Wall-mounted cabinet"), ) ``` Are there other types we want to include?

adam commented

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

@ryanmerolle commented on GitHub (Jul 6, 2016):

Yea this looks fine. I think other things like lock type, shared access and other rack attributes/characteristics people might want to track would be handled by custom fields.

@ryanmerolle commented on GitHub (Jul 6, 2016): Yea this looks fine. I think other things like lock type, shared access and other rack attributes/characteristics people might want to track would be handled by custom fields.

adam commented

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

@peelman commented on GitHub (Jul 6, 2016):

Might matter more to telco guys than anybody else, but rack width? unfortunately 19" isn't the only game in town in the two-post game. We also have 24" and 30" wide cabinets.

@peelman commented on GitHub (Jul 6, 2016): Might matter more to telco guys than anybody else, but rack width? unfortunately 19" isn't the only game in town in the two-post game. We also have 24" and 30" wide cabinets.

adam commented

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

@ryanmerolle commented on GitHub (Jul 6, 2016):

Yea but is that just a rack width field prompted & associated only to 2 posts?

@ryanmerolle commented on GitHub (Jul 6, 2016): Yea but is that just a rack width field prompted & associated only to 2 posts?

adam commented

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

@peelman commented on GitHub (Jul 6, 2016):

sorry, that was two distinct thoughts. We have 19" and 23" telco racks on site (though the only 23's belong to a carrier).

We also have 24" and 30" 4-post cabinets.

@peelman commented on GitHub (Jul 6, 2016): sorry, that was two distinct thoughts. We have 19" and 23" telco racks on site (though the only 23's belong to a carrier). We also have 24" and 30" 4-post cabinets.

adam commented

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

@ryanmerolle commented on GitHub (Jul 6, 2016):

I would imagine rack owners would be handled by Multinenancy #16 (not that you were bringing that point up specifically). With that all said, I think you just defined a new rack attribute for rack width.

@ryanmerolle commented on GitHub (Jul 6, 2016): I would imagine rack owners would be handled by Multinenancy #16 (not that you were bringing that point up specifically). With that all said, I think you just defined a new rack attribute for rack width.

adam commented

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

@jeremystretch commented on GitHub (Jul 6, 2016):

I have no problem with adding two fields: width and type. What are the "standard" widths we want to include? I know of 19" and 23" but have never heard of others.

@jeremystretch commented on GitHub (Jul 6, 2016): I have no problem with adding two fields: `width` and `type`. What are the "standard" widths we want to include? I know of 19" and 23" but have never heard of others.

adam commented

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

@peelman commented on GitHub (Jul 6, 2016):

For two-posters and open-four-posters, 19" and 23" is probably 99% of them. For cabinets 24" and 30" are the only widths I've ever seen in the past 15 years.

Last peccadillo: depth of cabinets? Not rail-depth (which is a yet another variable that may or may not be important), but the actual cabinet depth. 36", 42", 48" are the standards on floor cabinets, but wall cabinets are typically 12"-20".

None of that really matters until you show up on site to install something too long to fit.

@peelman commented on GitHub (Jul 6, 2016): For two-posters and open-four-posters, 19" and 23" is probably 99% of them. For cabinets 24" and 30" are the only widths I've ever seen in the past 15 years. Last peccadillo: depth of cabinets? Not rail-depth (which is a yet another variable that may or may not be important), but the actual cabinet depth. 36", 42", 48" are the standards on floor cabinets, but wall cabinets are typically 12"-20". None of that really matters until you show up on site to install something too long to fit.

adam commented

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

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

I think we first need to define are we talking about using the width between the rails or the outer dimensions of the physical cabinet?

Most people concerned with physical equipment want rail-to-rail (19/23)

Most people concerned with facility equipment want outer dimensions (24/30)

There may be some purpose built sized stuff.

As stated there are also many types and styles:
-open, closed, sealed
-2 post, 4 post, wall mounted, cart

@bellwood commented on GitHub (Jul 13, 2016): I think we first need to define are we talking about using the width between the rails or the outer dimensions of the physical cabinet? Most people concerned with physical equipment want rail-to-rail (19/23) Most people concerned with facility equipment want outer dimensions (24/30) There may be some purpose built sized stuff. As stated there are also many types and styles: -open, closed, sealed -2 post, 4 post, wall mounted, cart

adam commented

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

@jeremystretch commented on GitHub (Jul 13, 2016):

I think rail-to-rail width should be treated as separate from the rack type. We could implement it as a PositiveSmallIntegerField (with choices limited to 19 or 23) on Rack and DeviceType to enforce compatibility. Then we could add a separate field only on Rack to denote its type (cabinet vs frame, etc.).

@jeremystretch commented on GitHub (Jul 13, 2016): I think rail-to-rail width should be treated as separate from the rack type. We could implement it as a PositiveSmallIntegerField (with choices limited to 19 or 23) on Rack and DeviceType to enforce compatibility. Then we could add a separate field only on Rack to denote its type (cabinet vs frame, etc.).

adam commented

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

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

As a side note, if we could set the default options for type, width in the config file that would be handy (depending on what the defaults may be)

We are a 19" (24" OD) 4-post cabinet shop so that works for us, but, certainly others will want defaults that work for them.

Storing depth may not be a bad thing either, along with make and model.

We have both Liebert DCF and DCM racks but they are both 1100x600

@bellwood commented on GitHub (Jul 13, 2016): As a side note, if we could set the default options for type, width in the config file that would be handy (depending on what the defaults may be) We are a 19" (24" OD) 4-post cabinet shop so that works for us, but, certainly others will want defaults that work for them. Storing depth may not be a bad thing either, along with make and model. We have both Liebert DCF and DCM racks but they are both 1100x600

adam commented

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

@Gelob commented on GitHub (Aug 4, 2016):

With this coming in 1.5, is there going to be an interface to add our own rack types without having to go into the backend? I see lots of issues where its been brought up that they want to be able to distinguish a rack as virtual or maybe its not really a rack but a shelf in an office, etc.

I think we could curb a lot of extra work around the virtualization and those issues of not legit racks by doing types and just have people get over the fact that Racks represent a container for devices and devices are not just physical.

@Gelob commented on GitHub (Aug 4, 2016): With this coming in 1.5, is there going to be an interface to add our own rack types without having to go into the backend? I see lots of issues where its been brought up that they want to be able to distinguish a rack as virtual or maybe its not really a rack but a shelf in an office, etc. I think we could curb a lot of extra work around the virtualization and those issues of not legit racks by doing types and just have people get over the fact that Racks represent a container for devices and devices are not just physical.

adam commented

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

@iamdadmin commented on GitHub (Aug 8, 2016):

Can I recommend that the width and depth be allowed to be millimetres as well as inches? Here in the UK even though roads are still in miles, width and depth is pretty standard to be metric first.

@iamdadmin commented on GitHub (Aug 8, 2016): Can I recommend that the width and depth be allowed to be millimetres as well as inches? Here in the UK even though roads are still in miles, width and depth is pretty standard to be metric first.

adam commented

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

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

Is there going to be an interface to add our own rack types without having to go into the backend?

No. Realistically, there are only a handful of rack types, discussed above.

I see lots of issues where its been brought up that they want to be able to distinguish a rack as virtual or maybe its not really a rack but a shelf in an office, etc.

There is no such thing a "virtual rack." A rack in NetBox equates to a physical equipment rack. Attempting to represent anything else using the rack model will lead to pain and sorrow. #198 discusses this at length.

Can I recommend that the width and depth be allowed to be millimetres as well as inches?

We can probably store the values for cabinet width and depth in mm but display both mm and inches on the user-facing form. I think it makes sense to store the rail-to-rail width as simply 19 or 23.

@jeremystretch commented on GitHub (Aug 8, 2016): > Is there going to be an interface to add our own rack types without having to go into the backend? No. Realistically, there are only a handful of rack types, discussed above. > I see lots of issues where its been brought up that they want to be able to distinguish a rack as virtual or maybe its not really a rack but a shelf in an office, etc. There is no such thing a "virtual rack." A rack in NetBox equates to a physical equipment rack. Attempting to represent anything else using the rack model will lead to pain and sorrow. #198 discusses this at length. > Can I recommend that the width and depth be allowed to be millimetres as well as inches? We can probably store the values for cabinet width and depth in mm but display both mm and inches on the user-facing form. I think it makes sense to store the rail-to-rail width as simply 19 or 23.

adam commented

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

@iamdadmin commented on GitHub (Aug 8, 2016):

Bear in mind that you can have 600mm or 800mm wide 19" cabinets - that's more where I'm coming from. I do agree that there's no advantage to convert 19" to mm/cm though.

@iamdadmin commented on GitHub (Aug 8, 2016): Bear in mind that you can have 600mm or 800mm wide 19" cabinets - that's more where I'm coming from. I do agree that there's no advantage to convert 19" to mm/cm though.

adam commented

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

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

e7116b8 took care of adding type and width fields to the Rack model. What do people think about recording the outer (cabinet) width and depth? The only I see is that some manufacturers give dimensions in inches and others in millimeters. I assume that a 24" (~610mm) rack is the same physically as a 600mm rack but maybe not.

One option would be to add three fields:

outer_width
outer_depth
outer_unit

where outer_unit can equal either mm or in. This might be overcomplicating the issue though.

@jeremystretch commented on GitHub (Aug 9, 2016): e7116b8 took care of adding `type` and `width` fields to the Rack model. What do people think about recording the outer (cabinet) width and depth? The only I see is that some manufacturers give dimensions in inches and others in millimeters. I assume that a 24" (~610mm) rack is the same physically as a 600mm rack but maybe not. One option would be to add three fields: - outer_width - outer_depth - outer_unit where `outer_unit` can equal either `mm` or `in`. This might be overcomplicating the issue though.

adam commented

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

@iamdadmin commented on GitHub (Aug 9, 2016):

I think in terms of the database data type, any value from 600 to 1200 should cover w and d, so int(4) in nearest postgresql data type perhaps?

Unit could be site specific possibly. Having rack granularity could be handy at times, however for most cases, a single location is likely to have the same common standard.

Possibly you would have it set on the site with an toggle check for override on a single rack? I know that means extra fields but it might offer the best balance of less admin per individual rack while still allowing the flexibility? If it can be made to work? I am no python/django dev, I only program in LAMP so far :)

@iamdadmin commented on GitHub (Aug 9, 2016): I think in terms of the database data type, any value from 600 to 1200 should cover w and d, so int(4) in nearest postgresql data type perhaps? Unit could be site specific possibly. Having rack granularity could be handy at times, however for most cases, a single location is likely to have the same common standard. Possibly you would have it set on the site with an toggle check for override on a single rack? I know that means extra fields but it might offer the best balance of less admin per individual rack while still allowing the flexibility? If it can be made to work? I am no python/django dev, I only program in LAMP so far :)

adam commented

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

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

Since the initial feature requested has been implemented, I'm going to close this issue. #450 has been created to address the inclusion of outer rack/cabinet dimensions.

@jeremystretch commented on GitHub (Aug 10, 2016): Since the initial feature requested has been implemented, I'm going to close this issue. #450 has been created to address the inclusion of outer rack/cabinet dimensions.

adam referenced this issue

2025-12-29 21:21:03 +01:00

Multi-termination no longer working in web UI since 4.0 #9695

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#137