Support for Nested Sites #2127

New Issue

adam · 2025-12-29T17:22:30+01:00

adam commented

2025-12-29 17:22:30 +01:00

Originally created by @DanSheps on GitHub (Nov 15, 2018).

Environment

Python version: 3.5.4
NetBox version: 2.4.7 / 2.5.0-beta1

Proposed Functionality

This feature would add the ability, similar to Regions, to nest sites.

This would allow the modelling of a building "site" and room "site" (could also include specific area's within a building to further segregate).

This might also be particularly useful now that #20 is going to be implemented in v2.5.0 as it might be more relevant if you are currently using sites for "buildings" but you need a panel in a specific room. Additionally, the metadata allowed to be carried in site's is far more relevant to rooms compared to rack groups/racks.

Use Case

Currently the site object allows other objects to be tied to a specific site. Currently regions allows nested regions and rack groups are planned to get nested rack groups in #1754. However sites, which I would view as either a building or a room within a building, currently do not allow for nesting of rack groups.

If you use Rack Groups to represent sub-areas(area, room, etc) within a building, there will be no way to attach a device that isn't in a rack to a specific area like a room within a building.

This also allows you to model the vlans within a building site and room site more effectively.

Specific use case (assuming the following structure):

City (Region)
Building (Site)
Area (Site)
Room (Site)

Attach racks to a building
Attach devices to a building (with or without a rack)
Attach devices to a area (with or without a rack)
Attach devices to a room (with or without a rack)
Potentially allow inheritable VLANs

Database Changes

This would require a foreign key referencing the parent site.

Design Considerations

Currently, VLAN are tied into sites, when dealing with devices that are assigned vlans based on the site. For example, you might want to look at the site as well as all parent sites.

There may be other objects which look at sites in a similar vein and would also need to be considered.

External Dependencies

No external dependencies

Originally created by @DanSheps on GitHub (Nov 15, 2018). ### Environment * Python version: 3.5.4 * NetBox version: 2.4.7 / 2.5.0-beta1 ### Proposed Functionality This feature would add the ability, similar to Regions, to nest sites. This would allow the modelling of a building "site" and room "site" (could also include specific area's within a building to further segregate). This might also be particularly useful now that #20 is going to be implemented in v2.5.0 as it might be more relevant if you are currently using sites for "buildings" but you need a panel in a specific room. Additionally, the metadata allowed to be carried in site's is far more relevant to rooms compared to rack groups/racks. ### Use Case Currently the site object allows other objects to be tied to a specific site. Currently regions allows nested regions and rack groups are planned to get nested rack groups in #1754. However sites, which I would view as either a building or a room within a building, currently do not allow for nesting of rack groups. If you use Rack Groups to represent sub-areas(area, room, etc) within a building, there will be no way to attach a device that isn't in a rack to a specific area like a room within a building. This also allows you to model the vlans within a building site and room site more effectively. Specific use case (assuming the following structure): City (Region) Building (Site) Area (Site) Room (Site) * Attach racks to a building * Attach devices to a building (with or without a rack) * Attach devices to a area (with or without a rack) * Attach devices to a room (with or without a rack) * Potentially allow inheritable VLANs ### Database Changes This would require a foreign key referencing the parent site. ### Design Considerations Currently, VLAN are tied into sites, when dealing with devices that are assigned vlans based on the site. For example, you might want to look at the site as well as all parent sites. There may be other objects which look at sites in a similar vein and would also need to be considered. ### External Dependencies No external dependencies

adam closed this issue

2025-12-29 17:22:30 +01:00

adam commented

2025-12-29 17:22:30 +01:00

@jeremystretch commented on GitHub (Nov 15, 2018):

I think we've struck a good balance as it is with nested regions and rack groups. Allowing nested sites as well is bound to introduce unnecessary complexity and confusion.

@jeremystretch commented on GitHub (Nov 15, 2018): I think we've struck a good balance as it is with nested regions and rack groups. Allowing nested sites as well is bound to introduce unnecessary complexity and confusion.

adam commented

2025-12-29 17:22:31 +01:00

@lampwins commented on GitHub (Nov 15, 2018):

I am inclined to agree with @jeremystretch on this one. I don't really see a compelling reason to nest sites.

if you are currently using sites for "buildings" but you need a panel in a specific room.

@DanSheps can you expand on why Rack Groups alone cannot achieve this? I use Rack Groups all the time to represent IDFs in buildings.

the metadata allowed to be carried in site's is far more relevant to rooms compared to rack groups/racks.

What fields are you thinking? Perhaps there is a way to meaningfully capture this on a Rack Group in #1754

In any event, I feel we should move forward with #1754 and only after, revisit this if there is sufficient need at that time.

@lampwins commented on GitHub (Nov 15, 2018): I am inclined to agree with @jeremystretch on this one. I don't really see a compelling reason to nest sites. > if you are currently using sites for "buildings" but you need a panel in a specific room. @DanSheps can you expand on why Rack Groups alone cannot achieve this? I use Rack Groups all the time to represent IDFs in buildings. > the metadata allowed to be carried in site's is far more relevant to rooms compared to rack groups/racks. What fields are you thinking? Perhaps there is a way to meaningfully capture this on a Rack Group in #1754 In any event, I feel we should move forward with #1754 and only after, revisit this if there is sufficient need at that time.

adam commented

2025-12-29 17:22:31 +01:00

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

I think we've struck a good balance as it is with nested regions and rack groups. Allowing nested sites as well is bound to introduce unnecessary complexity and confusion.

Understandable, my own view is as follows though. Rack groups represent more of a physical or logical grouping of racks themselves, may not relate to anything physical related to the building. Regions are more logical separations of the physical address, up until you get to a physical building (or perhaps a group of physical buildings. Sites represent the attributes of the physical building(s) and the physical buildings themselves.

Sort of like below

Regions:

World
Country
State/Province
City
Neighbourhood

Sites:

Campus
Building
Area
Room

Rack Groups

Datacenter Grouping
Cage
Row
Rack "grouping"

Alternatively, and perhaps a better way may be to do away with regions all together and just use a generic object that can either be a container (region) or something more specific (site), and allows nesting. There would obviously be migration considerations here that would need to be addressed.

@DanSheps can you expand on why Rack Groups alone cannot achieve this? I use Rack Groups all the time to represent IDFs in buildings.

Rack Groups require racks for devices to be placed into them, there might be certain circumstances where you might not have a rack but might have a bunch of devices.

I can see cases where this might be needed with #20, where you might have a single physical device (fiber optic repeater, etc) attached to a specific room but not as part of a rack or rack group (perhaps it is just stuck to a wall). You still want to capture that connection but your highest level at that point is going to be the building and not the room. If you nest sites, you can attach the device to a site (but not in a rack) and accurately capture the state of the physical connection.

Another example is modeling administrative workstations that might be connected to the infrastructure, these aren't going to be in a rack that is part of a rack group either.

What fields are you thinking? Perhaps there is a way to meaningfully capture this on a Rack Group in #1754

Contacts, Tenant, Coordinates (this also lets you lay out individual rooms on a map as well as the overall site).

In any event, I feel we should move forward with #1754 and only after, revisit this if there is sufficient need at that time.

I definitely don't have a problem with this at all.

@DanSheps commented on GitHub (Nov 15, 2018): > I think we've struck a good balance as it is with nested regions and rack groups. Allowing nested sites as well is bound to introduce unnecessary complexity and confusion. Understandable, my own view is as follows though. Rack groups represent more of a physical or logical grouping of racks themselves, may not relate to anything physical related to the building. Regions are more logical separations of the physical address, up until you get to a physical building (or perhaps a group of physical buildings. Sites represent the attributes of the physical building(s) and the physical buildings themselves. Sort of like below Regions: * World * Country * State/Province * City * Neighbourhood Sites: * Campus * Building * Area * Room Rack Groups * Datacenter Grouping * Cage * Row * Rack "grouping" *Alternatively*, and perhaps a better way may be to do away with regions all together and just use a generic object that can either be a container (region) or something more specific (site), and allows nesting. There would obviously be migration considerations here that would need to be addressed. > @DanSheps can you expand on why Rack Groups alone cannot achieve this? I use Rack Groups all the time to represent IDFs in buildings. Rack Groups require racks for devices to be placed into them, there might be certain circumstances where you might not have a rack but might have a bunch of devices. I can see cases where this might be needed with #20, where you might have a single physical device (fiber optic repeater, etc) attached to a specific room but not as part of a rack or rack group (perhaps it is just stuck to a wall). You still want to capture that connection but your highest level at that point is going to be the building and not the room. If you nest sites, you can attach the device to a site (but not in a rack) and accurately capture the state of the physical connection. Another example is modeling administrative workstations that might be connected to the infrastructure, these aren't going to be in a rack that is part of a rack group either. > What fields are you thinking? Perhaps there is a way to meaningfully capture this on a Rack Group in #1754 Contacts, Tenant, Coordinates (this also lets you lay out individual rooms on a map as well as the overall site). > In any event, I feel we should move forward with #1754 and only after, revisit this if there is sufficient need at that time. I definitely don't have a problem with this at all.

adam commented

2025-12-29 17:22:31 +01:00

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

To further add, I just did some preliminary testing, and it seems to work by just switching to a TreeForeignKey & MPTT type field. If you don't mind, I think basic functionality of nested sites could be added then the far reaching impact of parent sites for things like vlans could be added. I would like to program this and then submit a PR.

Thoughts?

@DanSheps commented on GitHub (Nov 15, 2018): To further add, I just did some preliminary testing, and it seems to work by just switching to a TreeForeignKey & MPTT type field. If you don't mind, I think basic functionality of nested sites could be added then the far reaching impact of parent sites for things like vlans could be added. I would like to program this and then submit a PR. Thoughts?

adam commented

2025-12-29 17:22:31 +01:00

@jeremystretch commented on GitHub (Nov 16, 2018):

I'm going to close this out as we need to evaluate community feedback after implementing #1754 before we consider any further modifications to the region/site/group/rack hierarchy. Unfortunately I don't have an ETA for #1754.

@jeremystretch commented on GitHub (Nov 16, 2018): I'm going to close this out as we need to evaluate community feedback after implementing #1754 before we consider any further modifications to the region/site/group/rack hierarchy. Unfortunately I don't have an ETA for #1754.

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