Support for Nested Sites

[DanSheps]

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

[jeremystretch]

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.

[lampwins]

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.

[DanSheps]

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]

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?

[jeremystretch]

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.