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

Introduce a SiteGroup model to provide a secondary mechanism for classifying sites #4604

New Issue
Closed
opened 2025-12-29 18:38:10 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:38:10 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Feb 27, 2021).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.7.9
  • NetBox version: 2.10.5

Proposed Functionality

Introduce a new SiteGroup model, recursively nested similar to Region. Each site can be assigned to both a region and a site group.

Use Case

As regions are intended for the geographic classification of sites (e.g. continent > country > city), site groups can be used to classify sites by function. Site groups also offer an attractive avenue for supporting more flexible L2/L3 domain scoping.

Database Changes

  • Create a table for the SiteGroup model
  • Add a ForeignKey field on Site to SiteGroup

External Dependencies

None

Originally created by @jeremystretch on GitHub (Feb 27, 2021). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.7.9 * NetBox version: 2.10.5 ### Proposed Functionality Introduce a new SiteGroup model, recursively nested similar to Region. Each site can be assigned to both a region and a site group. ### Use Case As regions are intended for the geographic classification of sites (e.g. continent > country > city), site groups can be used to classify sites by function. Site groups also offer an attractive avenue for supporting more flexible L2/L3 domain scoping. ### Database Changes - Create a table for the SiteGroup model - Add a ForeignKey field on Site to SiteGroup ### External Dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 18:38:10 +01:00
adam closed this issue 2025-12-29 18:38:10 +01:00
adam commented 2025-12-29 18:38:10 +01:00
Author
Owner
Copy Link

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

I like this approach, and I think it addresses current concerns with the model, BUT have you thought about calling it a "site role" instead to follow the consistency of other models (racks and devices)?

@ryanmerolle commented on GitHub (Feb 27, 2021): I like this approach, and I think it addresses current concerns with the model, BUT have you thought about calling it a "site role" instead to follow the consistency of other models (racks and devices)?
adam commented 2025-12-29 18:38:10 +01:00
Author
Owner
Copy Link

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

Possibly. I think we've established two patterns of organizational models: "flat" (device roles, rack roles, etc.) and hierarchical (regions, rack groups, tenant groups). I like the hierarchical approach because it allows users to employ nesting. It might be beneficial to stick with the "group" naming for organizational models which support recursive hierarchy (via MPTT) for consistency.

(I know that the VLANGroup model is not hierarchical, but #5895 proposes renaming it for unrelated reasons.)

@jeremystretch commented on GitHub (Feb 27, 2021): Possibly. I think we've established two patterns of organizational models: "flat" (device roles, rack roles, etc.) and hierarchical (regions, rack groups, tenant groups). I like the hierarchical approach because it allows users to employ nesting. It might be beneficial to stick with the "group" naming for organizational models which support recursive hierarchy (via MPTT) for consistency. (I know that the VLANGroup model is _not_ hierarchical, but #5895 proposes renaming it for unrelated reasons.)
adam commented 2025-12-29 18:38:10 +01:00
Author
Owner
Copy Link

@networkhorse commented on GitHub (Mar 4, 2021):

I think this would be quite nice. Personally I've resorted to putting roles on racks, but putting them on sites would be much nicer. My use case has been marking "Data Centre", "Field" or "Exchange" with respect to ISP network deployment. This way, we know what type of set up to expect.

@networkhorse commented on GitHub (Mar 4, 2021): I think this would be quite nice. Personally I've resorted to putting roles on racks, but putting them on sites would be much nicer. My use case has been marking "Data Centre", "Field" or "Exchange" with respect to ISP network deployment. This way, we know what type of set up to expect.
adam commented 2025-12-29 18:38:11 +01:00
Author
Owner
Copy Link

@fischa commented on GitHub (Mar 4, 2021):

I like the idea as well. Having an option for a "meta" grouping that is not geographical sounds promising 😄 But I also like the idea of roles for sites.

@fischa commented on GitHub (Mar 4, 2021): I like the idea as well. Having an option for a "meta" grouping that is not geographical sounds promising 😄 But I also like the idea of roles for sites.
adam commented 2025-12-29 18:38:11 +01:00
Author
Owner
Copy Link

@bryanward-net commented on GitHub (Mar 4, 2021):

For our campus network, we've run into some challenges surrounding the lack of ability to nest sites. Our network and geographical hierarchy is similar to:

-Main Campus
  -North
    -Building Group A
      -Building A1
      -Building A2
      -Building A3
    -Building Group B
      -Building B1
      -Building B2
    -Building C
    -Building D
  -South
    -Building Group E
      -Building E1
      -Building E2
    -Building Group F
      -Building F1
      -Building F2
      -Building F3
      -Building F4
    -Building G
    -Building H
-Remote Offices
  -Remote Office 1
  -Remote Office 2
  -Remote Office 3
  -Remote Office Group A
    -Remote Office A1
    -Remote Office A2

Where South and North would have distribution-layer routers, and each Building would have switches that connect to the distribution layer. However, all buildings in a Building Group would have several VLANs and config contexts in common with each other (such as building management devices, where the water pump in Building B1 needs to be Layer2 adjacent to the water pump in Building B2 - we span these VLANs between the buildings). Additionally, all buildings in a North/South level organization would also have several VLANs and config contexts in common with each other (such as for WiFi clients, to allow seamless roaming of a client device around that section of the campus).
I've managed to make this work by calling North and South each a Site in netbox, and then using VLAN Groups for each Building. But, I end up having to duplicate data between VLAN Groups.

Ideally, each building would be a Site, and then a Building Group could be this new proposed Site Group, and North/South could also be Site Groups. Inheritance would trickle down from the top-most level with lower levels overriding as necessary. Allowing for an arbitrary amount of nesting levels would be ideal.

For the Remote Offices, each Remote Office has the same VLAN IDs as each other (vlan 10 is data, vlan 11 is voice, vlan 12 is guest wifi, etc.) For now, I end up having to duplicate all these as well. That's not a bad thing, as technically VLAN 10 as it exists in Remote Office 1 is totally separate from VLAN 10 in Remote Office 2. I'm OK with these having to be created per-site, but it raises the question of how to enforce uniqueness of VLAN IDs within a Site or Site Group. I'd want to enforce unique VLAN IDs within the North and South Site Groups, but not within the Remote Offices Site group or the Main Campus Site Group.

For those who might ask "Why not use Regions?" - VLANs belong to Sites, not Regions. Using Regions would allow me to model the geographical hierarchy, but not the network one.

@bryanward-net commented on GitHub (Mar 4, 2021): For our campus network, we've run into some challenges surrounding the lack of ability to nest sites. Our network and geographical hierarchy is similar to: ``` -Main Campus -North -Building Group A -Building A1 -Building A2 -Building A3 -Building Group B -Building B1 -Building B2 -Building C -Building D -South -Building Group E -Building E1 -Building E2 -Building Group F -Building F1 -Building F2 -Building F3 -Building F4 -Building G -Building H -Remote Offices -Remote Office 1 -Remote Office 2 -Remote Office 3 -Remote Office Group A -Remote Office A1 -Remote Office A2 ``` Where South and North would have distribution-layer routers, and each Building would have switches that connect to the distribution layer. However, all buildings in a Building Group would have several VLANs and config contexts in common with each other (such as building management devices, where the water pump in Building B1 needs to be Layer2 adjacent to the water pump in Building B2 - we span these VLANs between the buildings). Additionally, all buildings in a North/South level organization would also have several VLANs and config contexts in common with each other (such as for WiFi clients, to allow seamless roaming of a client device around that section of the campus). I've managed to make this work by calling North and South each a Site in netbox, and then using VLAN Groups for each Building. But, I end up having to duplicate data between VLAN Groups. Ideally, each building would be a Site, and then a Building Group could be this new proposed Site Group, and North/South could also be Site Groups. Inheritance would trickle down from the top-most level with lower levels overriding as necessary. Allowing for an arbitrary amount of nesting levels would be ideal. For the Remote Offices, each Remote Office has the same VLAN IDs as each other (vlan 10 is data, vlan 11 is voice, vlan 12 is guest wifi, etc.) For now, I end up having to duplicate all these as well. That's not a bad thing, as technically VLAN 10 as it exists in Remote Office 1 is totally separate from VLAN 10 in Remote Office 2. I'm OK with these having to be created per-site, but it raises the question of how to enforce uniqueness of VLAN IDs within a Site or Site Group. I'd want to enforce unique VLAN IDs within the North and South Site Groups, but not within the Remote Offices Site group or the Main Campus Site Group. For those who might ask "Why not use Regions?" - VLANs belong to Sites, not Regions. Using Regions would allow me to model the geographical hierarchy, but not the network one.
adam commented 2025-12-29 18:38:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 4, 2021):

VLANs belong to Sites, not Regions.

The assignment of a VLAN to a site is optional. You can have "global" VLANs available to all sites. #5284 seeks to provide more flexibility in this regard, however it is possible with the current release.

@jeremystretch commented on GitHub (Mar 4, 2021): > VLANs belong to Sites, not Regions. The assignment of a VLAN to a site is optional. You can have "global" VLANs available to all sites. #5284 seeks to provide more flexibility in this regard, however it is possible with the current release.
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#4604
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?