Rack Types

[peelman]

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

[systo]

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.

[jeremystretch]

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?

[ryanmerolle]

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.

[peelman]

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.

[ryanmerolle]

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

[peelman]

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.

[ryanmerolle]

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.

[jeremystretch]

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.

[peelman]

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.

[bellwood]

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

[jeremystretch]

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.).

[bellwood]

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

[Gelob]

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.

[iamdadmin]

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.

[jeremystretch]

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.

[iamdadmin]

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.

[jeremystretch]

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.

[iamdadmin]

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 :)

[jeremystretch]

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.