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

Allow cluster to be assigned to a site group #6795

New Issue
Closed
opened 2025-12-29 19:45:28 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:45:28 +01:00
Owner
Copy Link

Originally created by @LuPo on GitHub (Aug 10, 2022).

NetBox version

v3.2.7

Feature type

Change to existing functionality

Proposed functionality

Existing Virtualization cluster definition allows for Site group selection only as a convenience to narrow down the Site selection. Currently it does not assign the cluster to the site group. This proposal aims to define a new relationship of cluster and site group.

Use case

Clusters are not necessarily bound to the single site. It is frequent to have a cluster stretched over multiple sites ad example VMware vSAN Stretched Cluster. At the university campus we have two datacenters (defined as separate sites) in a single region. We have vSAN deployed clusters between the two datacenters. Having our deployments located at 3 different regions it is important to assign a region to a cluster or a site group which can be defined as a group of sites within a region.

In NetBox there is no relationships between objects like vlans or prefixes and regions. Locations is also not a viable option as it is not related to Clusters and, even if it were, it is only possible to assign Site to a Location. It is always possible to use tags to mark such relationships, but with growing number of associations it would quickly become messy.

Database changes

none

External dependencies

none

Originally created by @LuPo on GitHub (Aug 10, 2022). ### NetBox version v3.2.7 ### Feature type Change to existing functionality ### Proposed functionality Existing Virtualization cluster definition allows for Site group selection only as a convenience to narrow down the Site selection. Currently it does not assign the cluster to the site group. This proposal aims to define a new relationship of cluster and site group. ### Use case Clusters are not necessarily bound to the single site. It is frequent to have a cluster stretched over multiple sites ad example VMware vSAN Stretched Cluster. At the university campus we have two datacenters (defined as separate sites) in a single region. We have vSAN deployed clusters between the two datacenters. Having our deployments located at 3 different regions it is important to assign a region to a cluster or a site group which can be defined as a group of sites within a region. In NetBox there is no relationships between objects like vlans or prefixes and regions. Locations is also not a viable option as it is not related to Clusters and, even if it were, it is only possible to assign Site to a Location. It is always possible to use tags to mark such relationships, but with growing number of associations it would quickly become messy. ### Database changes none ### External dependencies none
adam added the type: feature label 2025-12-29 19:45:28 +01:00
adam closed this issue 2025-12-29 19:45:28 +01:00
adam commented 2025-12-29 19:45:28 +01:00
Author
Owner
Copy Link

@t8simon commented on GitHub (Sep 2, 2022):

I would really love to have this implemented as well. Currently it is not really possible to correctly track a stretched cluster (without assigning hardware devices to the wrong site, which in effect also breaks the correctness of rack elevation / HU allocation).

This Issue is already requested since 2021: https://github.com/netbox-community/netbox/issues/6429 which was back then blocked by https://github.com/netbox-community/netbox/issues/6440 . This blocker is solved in the mean time :)
Maybe this issue also could be something for a live coding session as well? Would be interesting to watch.

@t8simon commented on GitHub (Sep 2, 2022): I would really love to have this implemented as well. Currently it is not really possible to correctly track a stretched cluster (without assigning hardware devices to the wrong site, which in effect also breaks the correctness of rack elevation / HU allocation). This Issue is already requested since 2021: https://github.com/netbox-community/netbox/issues/6429 which was back then blocked by https://github.com/netbox-community/netbox/issues/6440 . This blocker is solved in the mean time :) Maybe this issue also could be something for a live coding session as well? Would be interesting to watch.
adam commented 2025-12-29 19:45:29 +01:00
Author
Owner
Copy Link

@shauser commented on GitHub (Oct 12, 2022):

We discussed this topic for some time internally and have come up with some topics we'd like to discuss with you:

The site group is most likely the wrong object to link to. A site group is defined as a "role or function" of multiple sites (e.g. an office site), and not just a group of multiple sites. Additionally, a site can only be assigned to a single group, so we couldn't have multiple stretched clusters assigned to different groups containing the same sites (e.g. cluster 1 stretching sites A and B, cluster 2 stretching sites B and C).

So we'd like to introduce a new (hidden) stretch group object, which links n:n from site to cluster. This allows to assign a cluster to multiple sites using a multi select, and would cleanly migrate existing clusters to the new model.

UI wise we would propose a switch to the multi select control used for the tags. This should provide a good UX for this.

API wise the following changes would apply:

  • cluster.sites would be an array of site objects, replacing the existing cluster.site (breaking change)
  • the clusters query API should map without any changes matching any of the sites
  • POST, PUT and PATCH APIs would also switch to sites array (breaking change)

Other changes:

  • Devices can be assigned to a cluster if any of the sites match
  • The vlan filter for a VM only includes VLANs available at all sites (would require the use of VLAN groups for users of the feature) or VLANs without a group
  • If a VM is assigned to a cluster and a site, any of the cluster's sites has to match the selected site
  • The automatic assignment of vm.site = vm.cluster.site would have to be removed (see below)

Open questions:

  • Are the assumptions of site group vs. stretch group correct?
  • The required association between VM and site would have to be loosened up. I don't know 100% if there is an impact of this change, although the DB already allows for it. @jeremystretch, can you chime in on this?

We would love to sponsor a PR on this, but we'd have to clear up the open questions first before we can do the actual implementation.

@shauser commented on GitHub (Oct 12, 2022): We discussed this topic for some time internally and have come up with some topics we'd like to discuss with you: The site group is most likely the wrong object to link to. A site group is defined as a "role or function" of multiple sites (e.g. an _office site_), and not just a group of multiple sites. Additionally, a site can only be assigned to a single group, so we couldn't have multiple stretched clusters assigned to different groups containing the same sites (e.g. cluster 1 stretching sites A and B, cluster 2 stretching sites B and C). So we'd like to introduce a new (hidden) stretch group object, which links n:n from site to cluster. This allows to assign a cluster to multiple sites using a multi select, and would cleanly migrate existing clusters to the new model. UI wise we would propose a switch to the multi select control used for the tags. This should provide a good UX for this. API wise the following changes would apply: - cluster.sites would be an array of site objects, replacing the existing cluster.site (breaking change) - the clusters query API should map without any changes matching any of the sites - POST, PUT and PATCH APIs would also switch to sites array (breaking change) Other changes: - Devices can be assigned to a cluster if any of the sites match - The vlan filter for a VM only includes VLANs available at all sites (would require the use of VLAN groups for users of the feature) or VLANs without a group - If a VM is assigned to a cluster and a site, any of the cluster's sites has to match the selected site - The automatic assignment of vm.site = vm.cluster.site would have to be removed (see below) Open questions: - Are the assumptions of site group vs. stretch group correct? - The required association between VM and site would have to be loosened up. I don't know 100% if there is an impact of this change, although the DB already allows for it. @jeremystretch, can you chime in on this? We would love to sponsor a PR on this, but we'd have to clear up the open questions first before we can do the actual implementation.
adam commented 2025-12-29 19:45:29 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 17, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 17, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:45:29 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Jan 3, 2023):

@shauser , I've seen your message on slack. If you can work on a fork to show the baselines of your idea this can be used after to better understand the changes required. You don't have to do everything like tests/api/frontend but this would help us (maintainers) to figure out if the idea should/could move forward with a proper PR.

Thanks for your contribution nonetheless :)

@jsenecal commented on GitHub (Jan 3, 2023): @shauser , I've seen your message on slack. If you can work on a fork to show the baselines of your idea this can be used after to better understand the changes required. You don't have to do everything like tests/api/frontend but this would help us (maintainers) to figure out if the idea should/could move forward with a proper PR. Thanks for your contribution nonetheless :)
adam commented 2025-12-29 19:45:30 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 4, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 4, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:45:30 +01:00
Author
Owner
Copy Link

@Patrick-Remy commented on GitHub (Apr 4, 2023):

For our requirements we'd like modelling a Kubernetes Cluster in Netbox. The Cluster spans over multiple VMs at different DC sites from multiple hosters. That only solution is to model these VMs as normal devices, as they always can be assigned to the cluster, where VMs can't

So we'd like to introduce a new (hidden) stretch group object, which links n:n from site to cluster. This allows to assign a cluster to multiple sites using a multi select, and would cleanly migrate existing clusters to the new model.
UI wise we would propose a switch to the multi select control used for the tags. This should provide a good UX for this.

Open questions:

Are the assumptions of site group vs. stretch group correct?
The required association between VM and site would have to be loosened up. I don't know 100% if there is an impact of this change, although the DB already allows for it. @jeremystretch, can you chime in on this?

We currently group the sites by Hoster, and plan a multi-hoster cluster, where sites from two site-groups are required. So multi-selecting sites or multi-selecting site groups would be welcomed way for us!

@Patrick-Remy commented on GitHub (Apr 4, 2023): For our requirements we'd like modelling a Kubernetes Cluster in Netbox. The Cluster spans over multiple VMs at different DC sites from multiple hosters. That only solution is to model these VMs as normal devices, as they always can be assigned to the cluster, where VMs can't > So we'd like to introduce a new (hidden) stretch group object, which links n:n from site to cluster. This allows to assign a cluster to multiple sites using a multi select, and would cleanly migrate existing clusters to the new model. > UI wise we would propose a switch to the multi select control used for the tags. This should provide a good UX for this. > Open questions: > > Are the assumptions of site group vs. stretch group correct? > The required association between VM and site would have to be loosened up. I don't know 100% if there is an impact of this change, although the DB already allows for it. @jeremystretch, can you chime in on this? We currently group the sites by Hoster, and plan a multi-hoster cluster, where sites from two site-groups are required. So multi-selecting sites or multi-selecting site groups would be welcomed way for us!
adam commented 2025-12-29 19:45:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2023):

Folding this into #7699

@jeremystretch commented on GitHub (May 2, 2023): Folding this into #7699
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 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#6795
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?