starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support for nested rack groups #1439

New Issue
Closed
opened 2025-12-29 16:32:12 +01:00 by adam · 9 comments
adam commented 2025-12-29 16:32:12 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Dec 6, 2017).

Originally assigned to: @jeremystretch on GitHub.

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: 2.2.6

Description

Currently, a rack must be assigned to a site and may optionally be assigned to a rack group. Each rack group must be assigned to a site. This allows e.g. to represent cages within a site. However, this model is limited to a single level of grouping. It would be beneficial to support nested rack groups (similar to regions) so that we could model subgroups of racks within a cage, for example. Additional research is needed to determine how feasible this is.

Originally created by @jeremystretch on GitHub (Dec 6, 2017). Originally assigned to: @jeremystretch on GitHub. ### Issue type [x] Feature request <!-- An enhancement of existing functionality --> [ ] Bug report <!-- Unexpected or erroneous behavior --> [ ] Documentation <!-- A modification to the documentation --> ### Environment * Python version: 3.5.2 * NetBox version: 2.2.6 ### Description Currently, a rack must be assigned to a site and may optionally be assigned to a rack group. Each rack group must be assigned to a site. This allows e.g. to represent cages within a site. However, this model is limited to a single level of grouping. It would be beneficial to support nested rack groups (similar to regions) so that we could model subgroups of racks within a cage, for example. Additional research is needed to determine how feasible this is.
adam added the status: acceptedtype: feature labels 2025-12-29 16:32:12 +01:00
adam closed this issue 2025-12-29 16:32:12 +01:00
adam commented 2025-12-29 16:32:12 +01:00
Author
Owner
Copy Link

@jasonguy commented on GitHub (Dec 7, 2017):

@jeremystretch I thought the Tenancy aspect, from the Data Center viewpoint, was equivalent to the "cage". Perhaps I misunderstood the purpose of the Tenancy feature, (which is typically a term used for VRFs or VLANs) but the description says "Customers or departments", which seems to me like the cage in the DC. Then within the cage, you have Racks and optionally Rack Groups.

@jasonguy commented on GitHub (Dec 7, 2017): @jeremystretch I thought the Tenancy aspect, from the Data Center viewpoint, was equivalent to the "cage". Perhaps I misunderstood the purpose of the Tenancy feature, (which is typically a term used for VRFs or VLANs) but the description says "Customers or departments", which seems to me like the cage in the DC. Then within the cage, you have Racks and optionally Rack Groups.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 7, 2017):

@jasonguy The concept of tenancy covers many objects in NetBox (sites, racks, VRFs, circuits, etc.). It might make sense to assign a tenant for a specific device, or a whole rack, or a whole cage, depending on your use case.

@jeremystretch commented on GitHub (Dec 7, 2017): @jasonguy The concept of tenancy covers many objects in NetBox (sites, racks, VRFs, circuits, etc.). It might make sense to assign a tenant for a specific device, or a whole rack, or a whole cage, depending on your use case.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2018):

@Maxkaha Please keep comments pertinent to the issue. If you have other questions or suggestions, please open a separate issue if it seems appropriate to do so after consulting the contributing policy.

@jeremystretch commented on GitHub (Jan 10, 2018): @Maxkaha Please keep comments pertinent to the issue. If you have other questions or suggestions, please open a separate issue if it seems appropriate to do so after consulting [the contributing policy](https://github.com/digitalocean/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 6, 2018):

It will be interesting to see if we can implement both this and #238.

@jeremystretch commented on GitHub (Feb 6, 2018): It will be interesting to see if we can implement both this _and_ #238.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@puck commented on GitHub (Feb 19, 2018):

How about carving up racks for multi-tenancy within a rack? This can become a bit more interesting with #554 . I'd like to be able to say that a customer can manage the space they've been allocated within the rack, and that's it.

@puck commented on GitHub (Feb 19, 2018): How about carving up racks for multi-tenancy within a rack? This can become a bit more interesting with #554 . I'd like to be able to say that a customer can manage the space they've been allocated within the rack, and that's it.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 19, 2018):

With this feature, you may want to enable support for more details about a rack group. IE for tracking cages, a colocation provider (or the users of the netbox deployment) may have specific details tied to a cage like descriptions, tenant(s), tenant group(s), tags, or status. You could also argue that rack groups should track available power, rack space (may not be a good name, but track how many racks in that group could be provisioned), and other "datatypes" not currently found in netbox.

This could be a separate feature request, but I think its pertinent to the overall vision of nested rack groups for depicting cages. Let me know and I can split this out if needed.

@ryanmerolle commented on GitHub (Jul 19, 2018): With this feature, you may want to enable support for more details about a rack group. IE for tracking cages, a colocation provider (or the users of the netbox deployment) may have specific details tied to a cage like descriptions, tenant(s), tenant group(s), tags, or status. You could also argue that rack groups should track available power, rack space (may not be a good name, but track how many racks in that group could be provisioned), and other "datatypes" not currently found in netbox. This could be a separate feature request, but I think its pertinent to the overall vision of nested rack groups for depicting cages. Let me know and I can split this out if needed.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 15, 2018):

@jeremystretch Along the same vein as this, would it be possible to look at sites being recursive in addition?

The reason I ask, is I can see a site being more akin to:

  • Building
  • Building Area
  • Room

And Rack groups being more in line with groupings within a room, ex:

  • Cage
  • Rack Row
  • Rack "group"

If it makes sense, I can open an enhancement issue for it as well so that it can be tracked.

This would allow the ability to do things like have vlans/vlan groups assigned to a master site, and then have rooms under that site which could have a single vlan assigned to that room.

That said, I could see this causing a lot of checking needing to be done all over as it would potentially touch a large number of areas. For instance, in the vlan example, you would need to not only populate the immediate site vlans but also the parent vlans for a device in a room.

@DanSheps commented on GitHub (Oct 15, 2018): @jeremystretch Along the same vein as this, would it be possible to look at sites being recursive in addition? The reason I ask, is I can see a site being more akin to: * Building * Building Area * Room And Rack groups being more in line with groupings within a room, ex: * Cage * Rack Row * Rack "group" If it makes sense, I can open an enhancement issue for it as well so that it can be tracked. This would allow the ability to do things like have vlans/vlan groups assigned to a master site, and then have rooms under that site which could have a single vlan assigned to that room. That said, I could see this causing a lot of checking needing to be done all over as it would potentially touch a large number of areas. For instance, in the vlan example, you would need to not only populate the immediate site vlans but also the parent vlans for a device in a room.
adam commented 2025-12-29 16:32:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 2, 2020):

I've been digging into this a bit and updating an existing model to sublcass MPTTModel is a bit tricky. This introduces four new database fields (lft, rght, level, and tree_id) which must be initialized for all existing objects (i.e. any RackGroups which have already been defined). This is normally achieved by calling e.g. RackGroup.objects.rebuild().

While the fields can be added via a migration without issue, we don't have access to MPTT's TreeManager within the migration, so we can't call rebuild(). The method's logic is pretty simple though, so we could emulate it with regular update() queries, however this results in an exception when the migration is run: django.db.utils.OperationalError: cannot CREATE INDEX "dcim_rackgroup" because it has pending trigger events. We would need to split the rebuild process into its own migration to avoid this (and we'd still have to hack together our own clone of rebuild()).

Another option is to leverage the post_migrate trigger to automatically call RackGroup.objects.rebuild() when the migration completes. This seems like a cleaner solution, though we probably don't want to force a rebuild of the tree for every migration. Unfortunately it doesn't appear possible to limit this to certain models.

@jeremystretch commented on GitHub (Mar 2, 2020): I've been digging into this a bit and updating an existing model to sublcass MPTTModel is a bit tricky. This introduces four new database fields (`lft`, `rght`, `level`, and `tree_id`) which must be initialized for all existing objects (i.e. any RackGroups which have already been defined). This is normally achieved by calling e.g. `RackGroup.objects.rebuild()`. While the fields can be added via a migration without issue, we don't have access to MPTT's TreeManager within the migration, so we can't call `rebuild()`. The method's logic is pretty simple though, so we could emulate it with regular `update()` queries, however this results in an exception when the migration is run: `django.db.utils.OperationalError: cannot CREATE INDEX "dcim_rackgroup" because it has pending trigger events`. We would need to split the rebuild process into its own migration to avoid this (and we'd still have to hack together our own clone of `rebuild()`). Another option is to [leverage the `post_migrate` trigger](https://stackoverflow.com/a/56275798/2694522) to automatically call `RackGroup.objects.rebuild()` when the migration completes. This seems like a cleaner solution, though we probably don't want to force a rebuild of the tree for _every_ migration. Unfortunately it doesn't appear possible to limit this to certain models.
adam commented 2025-12-29 16:32:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 12, 2020):

I ended up separating the operations into two migrations and mimicking rebuild(), which seems to be straightforward enough.

@jeremystretch commented on GitHub (Mar 12, 2020): I ended up separating the operations into two migrations and mimicking `rebuild()`, which seems to be straightforward enough.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1439
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?