Add ability to assign (non racked) devices to rack groups (aka rooms)

[dreng]

Environment

• Python version: 3.7.3
• NetBox version: 2.8.9

Proposed Functionality

If I understand #1779 correctly you are not planning to implement rooms (which is extremely sad imo) and it is suggested to abuse rack groups to act as a room. If this is the case one should have the ability to assign any (non racked) device to such a group. Currently it is only possible to add racks to rack groups. Unfortunately the real world does not only consist of racks.

Use Case

Dozens. E.g. UPS or emergency power generator in a different fire section, non racked and seperated from all other rooms.

For a datacenter admin (and every other admin as well) it should be clear at first sight where a device is located. I do not just need to have a list of all devices but a list of where the devices can be found. Imagine a broken device that needs physical access to be repaired. Where should one start to search if there are plenty of rooms equipped with non racked devices? Sure, you can write a room number into a comment field but that totally breaks the intention of connecting data with parent/child relations. There wouldn't be any chance to use that data in a reasonable way.

[mskalecki]

Rack Groups can't have devices assigned directly to them. However, Racks can have 0U devices assigned to them (just leave the Rack Face and Position fields blank).

If you don't want unracked devices associated with "real" racks. Add additional virtual racks that describe the location of the unracked devices (like "BLDG-ROOM-WALL-1"), and assign the unracked devices to those "racks". You can even create a Rack Role called "Non-racked" if you want to be able to formally distinguish these virtual racks. This works great.

[dreng]

@mskalecki
Thank you for your contribution. Generally speaking, it is a very bad idea to abuse database fields or functions for things they were not invented for. In your example you can see directly, where such ideas end. Just click "Organisation -> Elevations" and find a bunch of physically not existing Racks in a graphical overview. Things will definately become worse with future developments.

Another (very bad) idea would be to allow 0U-Racks, which is currently not possible. Funny enough it is possible to choose a value of "0" at "Height (U)" which ends in an error message "Ensure that value is greater than or equal to 1."

Don't get me wrong as I do not intend to be harsh. I just don't get the point why there is no room concept as it is essential imo. Instead the official way is to break a great design with a poor workaround. And if that workaround does not work the solution is to use an even worse workaround. Furthermore it should be very easy to implement another layer between sites and racks. Racks should belong to a site XOR room. If one thinks that this is out of scope of a DCIM, have a look at this whitepaper from Schneider Electric.

[mskalecki]

@dreng
I agree with your premise of not abusing database fields, but my reasoning comes to a completely different conclusion.

In Netbox, "Racks" are a model of a physical location where devices physically reside. Typically, this will be a traditional network or server rack (hence the name), but a wall or section of flooring where devices reside is logically identical to traditional rack, except that the concept of an elevation or strict size limit may not make sense (Netbox already accomodates this by providing a section for "nonracked" devices on the elevation page). While one could separate out racks with elevations and nonracked areas for devices into distinct models, there is no real gain here, and you over-complicated the case where a tradional rack has associated device that don't fit in rack slots (such as a vertical PDU).

If you mentally imagine the Netbox "Rack" model as "Device Group", and then create Rack Roles for each type of device group you want to model ("network rack", "server rack", "wall", "cabinet", etc). The logic is sound.

Meanwhile, Rack Groups, are simply a groupings of Racks and other Rack Groups. Assigning devices directly to a Rack Group would be a pretty big logical change that only removes information.

[proudbro]

@mskalecki , why don't you create rooms as sites rather than rack groups? We've made global regions as Regions and buildings as Nested Regions. So you can attach devices (UPS, CRAC and so on) to sites and use rack groups to represent the rows

[dreng]

Ok, I got #1779 completely wrong then. Maybe there's a language barrier to blame.

So, you suggest to use racks with non racked devices for grouping purposes and let them act as a room. Although that doesn't seem to be ideal nor logical, i could live with it. Problem is, there seems to be no way of not showing such "rooms" as empty racks at the elevations overview, or am I missing something? And that might be not the only side effect. A rack (device group, room) still has a width of 19" and a height of x rack units. That's what I meant when i wrote about abusing database fields. There will always be one day such workarounds break your neck. As a compromise, maybe a boolean rack attribute llike "this is a virtual rack" could work around the issue? You could show all non-virtual racks in the elevations overview then.

I don't completely agree to your logic of racks, device groups and rack roles. I understand that you can imagine racks as logical groups. What I'd really like to see some day (maybe as a plugin) is a ground view with all your IT stuff (as seen in some commercial DCIM solutions). How should such a plugin know if a rack should be drawn as a rack, a room or maybe not at all? @proudbro found another solution to work around that problem which makes things even more complicated. There's just no best practice or an intuitive way of doing it. Furthermore I don't get the point of rack groups then. If it's just a matter of sound, it should be ok to nest one or more racks in a rack (aka room or rack group). No need for rack groups anymore here. Just imagine a rack as a rack group.
What I'm trying to say: Of course you can imagine everything as everything else, but that is not what a software makes a good solution. It's not just a matter of sound but a matter of logic, usability and intuitive operation.

Long story short: We're just tinkering around at the moment and I have to discuss with my team if we've got a show stopper here. As asked before, would it be a solution to add the ability to make a rack "virtual"?

[minitriga]

We use Netbox to manage our "Lab", which are racks of gear used to test customer networks. However, we have an issue whereby we have more gear than racks available due to customers wanting to test their own hardware in our facility with Ixia etc so we needed to be able to assign a device to our storage room. To do this we had to create a rack group "Storage Room" and then assign racks to said group in which I can put spares and unused devices. Bit of a pain to be honest. I have created a few plugins so might tackle this myself.

[jeremystretch]

In the interest of summarizing the discussion above, I've sketched the diagram below. The solid lines indicate existing relationships, and the dashed line represents my understanding of the proposed new relationship.

The assignment of a device to a site is required; association with a particular rack (with or without a specific face/position) is optional. While I don't see any obvious blockers to accommodating the additional relationship, we would need to take care to ensure proper validation is implemented (e.g. to make the appropriate updates when a RackGroup is assigned to a new Site). However we should be able to handle that in a manner similar to the current validation for racks.

My assumption is that any device assigned to a rack would be automatically associated with that rack's group (as opposed to making the Rack and RackGroup assignments mutually exclusive).

[dreng]

@jeremystretch
Thank you for contributing. Your drawing summarizes the original topic while the discussion above leads to the conclusion that it would be an ugly workaround.

What's really needed in order to localize racks and non racked devices seems to be the ability to divide a site into sections (rooms, maybe floors). I discussed the issue with my team today and it was generally agreed that the ability to assign devices to a room / building section is a must have. We'd really like to use netbox though because of it's good overall design. In conclusion we decided to use sites as rooms which is far away from being perfect because it leads to other issues. On the other hand it's not as misleading as rack groups.

If you'd like to do us a favour we'd really appreciate a concept sketched in the following drawing.

Orange arrows are mutually exclusive because it wouldn't make sense to assign devices to a site and a rack while the rack does not belong to that site. Same with sites and sections or sections and racks.

You may have a look at (unfortunately closed source) pathfinder to get a clue of what's possible with a room concept: https://english.tripunkt.de/network-documentation-showroom/

[jeremystretch]

We definitely won't be adding a separate room model as that would be redundant. (Keep in mind that rack groups can be recursively nested.) I see no reason why the RackGroup model would not suffice for this purpose.

[dreng]

I don't agree with you but unfortunately I see that we have to accept your opinion. The reason why the RackGroup model won't suffice this purpose has been stressed in this topic and it won't make sense to recap all arguments. I've had a look at some professional DCIMs and found out that they all work with rooms for a good reason.

Back to original topic: If you insist on using rack groups as rooms we end up in a situation that you showed in your diagram. Otherwise it wouldn't be possible to add devices to rooms (aka rack groups). Assuming it to be implemented: Would it be imaginable for you to rename RackGroup into something that is more general and less misleading? Something like (organizational) unit, section, object group or something? RackGroup sounds like a group of racks. Putting a group of racks (or a device) into a group of racks sounds somewhat weird.

[jeremystretch]

What's really needed in order to localize racks and non racked devices seems to be the ability to divide a site into sections (rooms, maybe floors)

This is exactly what RackGroups do. I feel like you're hung up solely on the term "rack group" without understanding the model's function.

Would it be imaginable for you to rename RackGroup into something that is more general and less misleading?

Possibly, but it's probably not going to be worth the disruption and effort to address a semantic flaw.

[dreng]

This is exactly what RackGroups do. I feel like you're hung up solely on the term "rack group" without understanding the model's function.

Sorry for being such a nag, but I'm afraid we're running in circles. I understood that RackGroups are intended to be a room or any other organizational unit as it is documented here. But if that is exactly what RackGroups do, how do I assign a device to a rack group without assigning it to a rack? As stated before, the current situation forces you to assign a device to a rack instead of a rack group. I did that before and it turned out to be an ugly workaround. If you have a look at the elevations view you'll find a bunch of empty, physically not existing Racks in a graphical overview. That's not logical nor consistent at all and has got nothing to do with the term "rack group". Nervertheless, the term is not ideal imo.

If you feel I don't understand the model's function I'd be happy to be enlightened. Why am I forced to put a rack into a RackGroup before I'm able to put a non racked device into the RackGroup? All I'd like to do is to represent the real situation but that doesn't seem to be possible with the current model.

[jeremystretch]

how do I assign a device to a rack group without assigning it to a rack?

That is the change my sketch above illustrates. No new models are needed.