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

New Issue

adam · 2025-12-29T18:32:17+01:00

adam commented

2025-12-29 18:32:17 +01:00

Originally created by @dreng on GitHub (Aug 7, 2020).

Originally assigned to: @jeremystretch on GitHub.

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.

Originally created by @dreng on GitHub (Aug 7, 2020). Originally assigned to: @jeremystretch on GitHub.  ### 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.

adam added the status: accepted type: feature labels 2025-12-29 18:32:17 +01:00

adam closed this issue

2025-12-29 18:32:17 +01:00

adam commented

2025-12-29 18:32:17 +01:00

@mskalecki commented on GitHub (Aug 7, 2020):

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.

@mskalecki commented on GitHub (Aug 7, 2020): 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.

adam commented

2025-12-29 18:32:17 +01:00

@dreng commented on GitHub (Aug 8, 2020):

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

@dreng commented on GitHub (Aug 8, 2020): @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](https://it-resource.schneider-electric.com/small-medium-data-centers/wp-104-classification-of-data-center-infrastructure-management-dcim-tools) from Schneider Electric.

adam commented

2025-12-29 18:32:17 +01:00

@mskalecki commented on GitHub (Aug 10, 2020):

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

@mskalecki commented on GitHub (Aug 10, 2020): @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.

adam commented

2025-12-29 18:32:17 +01:00

@proudbro commented on GitHub (Aug 11, 2020):

@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

@proudbro commented on GitHub (Aug 11, 2020): @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

adam commented

2025-12-29 18:32:17 +01:00

@dreng commented on GitHub (Aug 11, 2020):

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"?

@dreng commented on GitHub (Aug 11, 2020): 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"?

adam commented

2025-12-29 18:32:18 +01:00

@minitriga commented on GitHub (Aug 12, 2020):

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.

@minitriga commented on GitHub (Aug 12, 2020): 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.

adam commented

2025-12-29 18:32:18 +01:00

@jeremystretch commented on GitHub (Aug 19, 2020):

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

@jeremystretch commented on GitHub (Aug 19, 2020): 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. ![device_hierarchy](https://user-images.githubusercontent.com/13487278/90677888-fd568b80-e22b-11ea-8673-846970fb66fb.png) 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).

adam commented

2025-12-29 18:32:18 +01:00

@dreng commented on GitHub (Aug 21, 2020):

@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/

@dreng commented on GitHub (Aug 21, 2020): @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. ![devices_rooms](https://user-images.githubusercontent.com/20901110/90896023-3f660580-e3c3-11ea-9efa-724ab7b03c4c.png) 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/

adam commented

2025-12-29 18:32:18 +01:00

@jeremystretch commented on GitHub (Aug 21, 2020):

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.

@jeremystretch commented on GitHub (Aug 21, 2020): 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.

adam commented

2025-12-29 18:32:18 +01:00

@dreng commented on GitHub (Aug 21, 2020):

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.

@dreng commented on GitHub (Aug 21, 2020): 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.

adam commented

2025-12-29 18:32:18 +01:00

@jeremystretch commented on GitHub (Aug 21, 2020):

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.

@jeremystretch commented on GitHub (Aug 21, 2020): > 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.

adam commented

2025-12-29 18:32:18 +01:00

@dreng commented on GitHub (Aug 21, 2020):

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.

@dreng commented on GitHub (Aug 21, 2020): > 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](https://netbox.readthedocs.io/en/stable/core-functionality/sites-and-racks/#rack-groups). 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.

adam commented

2025-12-29 18:32:18 +01:00

@jeremystretch commented on GitHub (Aug 21, 2020):

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.

@jeremystretch commented on GitHub (Aug 21, 2020): > 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.

adam commented

2025-12-29 18:32:18 +01:00

@cpmills1975 commented on GitHub (Aug 22, 2020):

In my environment, I use rack groups as rooms. I haven’t yet updated my live version to a recent enough version to use nested rack groups, but when I do I will probably use these to break down my sites down to floors, rooms, rows and or aisles. Some sites will need this level of abstraction, some will not so maintaining a generic model that can be nested (or not) to any level is a better way forward than defining strict rooms, rows, aisles etc.

Having the ability to add devices directly to a rack group would be useful. Within some rooms, I could use the same rack group model to define a cupboard that contains devices. Probably not stacked in any sort of U order, probably not connected to anything, certainly not needing to be rendered in any sort of elevation and the ‘cupboard’ probably won’t be bound by a number of U positions etc.

FWIW, it seems @jeremystretch’s drawing above adequately models what I would need to achieve this.

@cpmills1975 commented on GitHub (Aug 22, 2020): In my environment, I use rack groups as rooms. I haven’t yet updated my live version to a recent enough version to use nested rack groups, but when I do I will probably use these to break down my sites down to floors, rooms, rows and or aisles. Some sites will need this level of abstraction, some will not so maintaining a generic model that can be nested (or not) to any level is a better way forward than defining strict rooms, rows, aisles etc. Having the ability to add devices directly to a rack group would be useful. Within some rooms, I could use the same rack group model to define a cupboard that contains devices. Probably not stacked in any sort of U order, probably not connected to anything, certainly not needing to be rendered in any sort of elevation and the ‘cupboard’ probably won’t be bound by a number of U positions etc. FWIW, it seems @jeremystretch’s drawing above adequately models what I would need to achieve this.

adam commented

2025-12-29 18:32:18 +01:00

@dreng commented on GitHub (Aug 22, 2020):

@cpmills1975
You boiled it down to an essence.

Sorry for having made this discussion a bit exhausting. I apologize for being not a native speaker as I might have gotten some things wrong.

@dreng commented on GitHub (Aug 22, 2020): @cpmills1975 You boiled it down to an essence. Sorry for having made this discussion a bit exhausting. I apologize for being not a native speaker as I might have gotten some things wrong.

adam commented

2025-12-29 18:32:18 +01:00

@jeremystretch commented on GitHub (Sep 16, 2020):

Moving this to needs milestone with the understanding that the goal is to add a relation from Device to RackGroup.

@jeremystretch commented on GitHub (Sep 16, 2020): Moving this to `needs milestone` with the understanding that the goal is to add a relation from Device to RackGroup.

adam commented

2025-12-29 18:32:18 +01:00

@candlerb commented on GitHub (Nov 5, 2020):

@jeremystretch wrote:

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.

I think that diagram is incomplete, as:

There is also a direct link from Rack to Site, which is not shown
It doesn't show the recursive parent relationship of RackGroup (that would just be a loopback arrow)

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

I think those issues already exist, namely:

if a RackGroup is assigned to a Site, then this may or may not be consistent with the Racks contained within it
if a RackGroup is assigned to a Site, then this may or may not be consistent with its child and/or parent RackGroups

Checking the existing validation rules, I find the following:

Rack.clean checks that if you change the Site of a Rack, it's consistent with the Site of its immediate parent RackGroup (if any).
RackGroup.clean checks that if you change the Site of a RackGroup, it's consistent with the Site of its immediate parent RackGroup (if any).

However I don't see any checks in the reverse direction: e.g. if you change the Site of a RackGroup it doesn't check that its child and descendant RackGroups and Racks are in the same Site [^1]. Indeed, testing (v2.9.8) shows this check is missing:

Create two sites, A and B
Create rack X in site A
Create rackgroup G in site A
Assign rack X to rackgroup G
Change site of rackgroup G to B

This change is accepted: rack X now belongs to site A but a rackgroup in site B. [^2]

Therefore: I don't think being able to assign a device directly to a Rackgroup adds any more requirements to validate the Rackgroup tree, beyond the (missing) functionality already required.

There is also validation around the Device's Site versus the Device's Rack's Site. Again this is missing when you change the Site of a Rack, which can be demonstrated as follows:

Create two sites, A and B
Create rack X in site A
Create devices D1, D2, D3... in rack X
Change rack X's site to B

Now those devices exist in site A, but in a rack which is in site B.

So in summary: if a device->rackgroup link is added, then device->rackgroup->site will also need to be validated, but this is no more than the already-required (but missing) device->rack->site validation. [^3]

(EDIT: validation problems above factored out as #5311)

[^1] Also, without a cascading downward change it becomes very difficult to change the assigned site of a tree of rackgroups. I think you'd have to replicate the entire rackgroup tree in a new site, reassign the racks to new site and rackgroup simultaneously, and then delete the original rackgroup tree. If there are already Devices in those Racks, then the problem is worse. However this will be required very rarely, if ever.

[^2] From this point onwards, it also becomes impossible to make an unrelated change to rack X: e.g. if you try to add a comment on rack X, it's rejected with "Rack group must be from the same site".

[^3] There is a possibly stronger argument here for a cascading change. Otherwise, moving a rack from site X to Y would require creating a new rack in Y, changing all the devices to the new rack, and then deleting the old rack. However again this really shouldn't happen much in practice.

@candlerb commented on GitHub (Nov 5, 2020): @jeremystretch wrote: > 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. I think that diagram is incomplete, as: 1. There is also a direct link from Rack to Site, which is not shown 2. It doesn't show the recursive parent relationship of RackGroup (that would just be a loopback arrow) > 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). I think those issues already exist, namely: - if a RackGroup is assigned to a Site, then this may or may not be consistent with the Racks contained within it - if a RackGroup is assigned to a Site, then this may or may not be consistent with its child and/or parent RackGroups Checking the existing validation rules, I find the following: - `Rack.clean` checks that if you change the Site of a Rack, it's consistent with the Site of its immediate parent RackGroup (if any). - `RackGroup.clean` checks that if you change the Site of a RackGroup, it's consistent with the Site of its immediate parent RackGroup (if any). However I don't see any checks in the reverse direction: e.g. if you change the Site of a RackGroup it doesn't check that its child and descendant RackGroups and Racks are in the same Site [^1]. Indeed, testing (v2.9.8) shows this check is missing: * Create two sites, A and B * Create rack X in site A * Create rackgroup G in site A * Assign rack X to rackgroup G * Change site of rackgroup G to B This change is accepted: rack X now belongs to site A but a rackgroup in site B. [^2] Therefore: I don't think being able to assign a device directly to a Rackgroup adds any more requirements to validate the Rackgroup tree, beyond the (missing) functionality already required. There is also validation around the Device's Site versus the Device's Rack's Site. Again this is missing when you change the Site of a Rack, which can be demonstrated as follows: * Create two sites, A and B * Create rack X in site A * Create devices D1, D2, D3... in rack X * Change rack X's site to B Now those devices exist in site A, but in a rack which is in site B. So in summary: if a `device->rackgroup` link is added, then `device->rackgroup->site` will also need to be validated, but this is no more than the already-required (but missing) `device->rack->site` validation. [^3] (EDIT: validation problems above factored out as #5311) ------- [^1] Also, without a cascading downward change it becomes very difficult to change the assigned site of a tree of rackgroups. I think you'd have to replicate the entire rackgroup tree in a new site, reassign the racks to new site and rackgroup simultaneously, and then delete the original rackgroup tree. If there are already Devices in those Racks, then the problem is worse. However this will be required very rarely, if ever. [^2] From this point onwards, it also becomes impossible to make an unrelated change to rack X: e.g. if you try to add a comment on rack X, it's rejected with "Rack group must be from the same site". [^3] There is a possibly stronger argument here for a cascading change. Otherwise, moving a rack from site X to Y would require creating a new rack in Y, changing all the devices to the new rack, and then deleting the old rack. However again this really shouldn't happen much in practice.

adam commented

2025-12-29 18:32:19 +01:00

@candlerb commented on GitHub (Nov 5, 2020):

I support linking Device directly to RackGroup (representing "room" or "area" within Site).

There is a precedent: PowerPanel is linked to Site and optionally RackGroup, but not to Rack.

@candlerb commented on GitHub (Nov 5, 2020): I support linking Device directly to RackGroup (representing "room" or "area" within Site). There is a precedent: PowerPanel is linked to Site and optionally RackGroup, but not to Rack.

adam commented

2025-12-29 18:32:19 +01:00

@silvanet123 commented on GitHub (Nov 16, 2020):

I agree about having some setup to represent a room or area. I understand that NetBox is primarily for DCIM; however, having rooms or areas where devices and data drops could go into would be EXTREMELY valuable. I am migrating from a similar tool I have used for years, Netdot (https://github.com/cvicente/Netdot), to NetBox. Netdot has similar features; however, I like the direction and activity of NetBox. The feature of cable plants in Netdot what initially appealing for me, particularly to rooms.

@silvanet123 commented on GitHub (Nov 16, 2020): I agree about having some setup to represent a room or area. I understand that NetBox is primarily for DCIM; however, having rooms or areas where devices and data drops could go into would be EXTREMELY valuable. I am migrating from a similar tool I have used for years, Netdot (https://github.com/cvicente/Netdot), to NetBox. Netdot has similar features; however, I like the direction and activity of NetBox. The feature of cable plants in Netdot what initially appealing for me, particularly to rooms.

adam commented

2025-12-29 18:32:19 +01:00

@jeremystretch commented on GitHub (Feb 27, 2021):

Blocked by #5895 (renaming RackGroup)

@jeremystretch commented on GitHub (Feb 27, 2021): Blocked by #5895 (renaming RackGroup)

adam referenced this issue

2025-12-29 22:23:12 +01:00

[PR #3969] [MERGED] Fixes: #3960 legacy device status #12711

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#3960