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

Cluster relations for Devices (HA) #11369

New Issue
Closed
opened 2025-12-29 21:44:18 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:44:18 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Jul 11, 2025).

NetBox version

v4.2.9

Feature type

New functionality

Proposed functionality

Provide a relation between dcim.devices that can contain 'shared' resources.
The current 'virtualization.cluster' is very limited in functionality and lacking ways to assign shared resources between clustered devices.

This FR is a request to create a dcim.cluster object that can contain

  • cluster type
  • dcim.devices
  • ipam.ipaddress
  • grouped interfaces (a grouping of interfaces of the existing dcim.devices members interfaces)
  • MAC address for the grouped.interfaces (to document the 'virtual' MAC addresses some solutions create)
  • tags
  • custom fields
  • related virtual.cluster

This is rough idea of what is needed, more fleshout will be required.
This is an addition to the "Virtual Device Contexts" and "Virtual Chassis"

(The VirtualChassis is a very specific implementation of a cluster, with master/slave relation, single mgmt plane. This proposal is for devices that have their own management plane, but share logical services like)

Use case

We have several devices that form an HA cluster (A/S, A/A, Scaleset).
Those clusters typically have multiple shared and dedicated resources (IP, interfaces, cluster type)
The dedicated resources will be assigned to the nodes themself (node ip, interfaces, serial, ...)
The key are the shared resources.
A Cluster has one or more 'floating' ip addresses that live on the 'active' device. This FR will enable us to assign those floating IPs to a dedicated device, rather than to 'a' device.
By the ability of 'grouping' interfaces on the cluster, we can remain the relationship between the interface of the nodes and the ip addresses assigned to those interfaces. The setting of this 'grouped' interface (for ex vlan mode and list) are pushed to the member interfaces, so that they are always aligned.

This could also be used to document the relation between interfaces when using MLAG/vPC/Multihoming.

Another usecase is to keep the configuration of clustered physical devices in sync. ex: all ESXi hosts of a vCenter cluster must have the same vlans/mtu. This FR can be used to link all ports of one portprofile of all ESXi hosts and provide a single place to configure these settings. It would be mandatory that this cluster can be related to virtual clusters.

Database changes

create a dcim.cluster object that can contain

  • cluster type
  • dcim.devices
  • ipam.ipaddress
  • grouped interfaces (a grouping of interfaces of the existing dcim.devices members interfaces)
  • tags
  • custom fields
  • related virtual.cluster

External dependencies

No response

Originally created by @PieterL75 on GitHub (Jul 11, 2025). ### NetBox version v4.2.9 ### Feature type New functionality ### Proposed functionality Provide a relation between dcim.devices that can contain 'shared' resources. The current 'virtualization.cluster' is very limited in functionality and lacking ways to assign shared resources between clustered devices. This FR is a request to create a dcim.cluster object that can contain - cluster type - dcim.devices - ipam.ipaddress - grouped interfaces (a grouping of interfaces of the existing dcim.devices members interfaces) - MAC address for the grouped.interfaces (to document the 'virtual' MAC addresses some solutions create) - tags - custom fields - related virtual.cluster This is rough idea of what is needed, more fleshout will be required. This is an addition to the "Virtual Device Contexts" and "Virtual Chassis" (The VirtualChassis is a very specific implementation of a cluster, with master/slave relation, single mgmt plane. This proposal is for devices that have their own management plane, but share logical services like) ### Use case We have several devices that form an HA cluster (A/S, A/A, Scaleset). Those clusters typically have multiple shared and dedicated resources (IP, interfaces, cluster type) The dedicated resources will be assigned to the nodes themself (node ip, interfaces, serial, ...) The key are the shared resources. A Cluster has one or more 'floating' ip addresses that live on the 'active' device. This FR will enable us to assign those floating IPs to a dedicated device, rather than to 'a' device. By the ability of 'grouping' interfaces on the cluster, we can remain the relationship between the interface of the nodes and the ip addresses assigned to those interfaces. The setting of this 'grouped' interface (for ex vlan mode and list) are pushed to the member interfaces, so that they are always aligned. This could also be used to document the relation between interfaces when using MLAG/vPC/Multihoming. Another usecase is to keep the configuration of clustered physical devices in sync. ex: all ESXi hosts of a vCenter cluster must have the same vlans/mtu. This FR can be used to link all ports of one portprofile of all ESXi hosts and provide a single place to configure these settings. It would be mandatory that this cluster can be related to virtual clusters. ### Database changes create a dcim.cluster object that can contain - cluster type - dcim.devices - ipam.ipaddress - grouped interfaces (a grouping of interfaces of the existing dcim.devices members interfaces) - tags - custom fields - related virtual.cluster ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:44:18 +01:00
adam closed this issue 2025-12-29 21:44:18 +01:00
adam commented 2025-12-29 21:44:19 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jul 14, 2025):

@PieterL75 , this appears to be a word-for-word duplicate of #19450. Did you file this intentionally, with the intention that we revisit the decision? Or was it filed accidentally?

@jnovinger commented on GitHub (Jul 14, 2025): @PieterL75 , this appears to be a word-for-word duplicate of #19450. Did you file this intentionally, with the intention that we revisit the decision? Or was it filed accidentally?
adam commented 2025-12-29 21:44:19 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jul 14, 2025):

I filled it again. The previous was closed.
But this is a missing link in documenting device related clusters (ha, frw, vpc, mlag, ... ).
I think the proposal might need more eyes.
And there is interest from the community.

Pieter

@PieterL75 commented on GitHub (Jul 14, 2025): I filled it again. The previous was closed. But this is a missing link in documenting device related clusters (ha, frw, vpc, mlag, ... ). I think the proposal might need more eyes. And there is interest from the community. Pieter
adam commented 2025-12-29 21:44:19 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jul 14, 2025):

@PieterL75 , I appreciate you making your intentions clear. Opening a word-for-word duplicate of a feature request that the maintainers have already rejected will not result in a reconsideration of the initial request.

The decision to reject #19450 was not arbitrary nor was it unilateral on my part. The NetBox maintainers discussed this as a group and decided together that the feature is currently out of the scope for NetBox's core feature set. We understand that you, and others in the community, disagree. However, we will not be re-opening this discussion right now. The proposal was given due consideration, but was ultimately rejected.

Will our view change in the future? I don't know, but it certainly hasn't changed in the barely more than a month since the initial rejection. As always, you are welcome to implement and maintain this feature in a fork of NetBox.

@jnovinger commented on GitHub (Jul 14, 2025): @PieterL75 , I appreciate you making your intentions clear. Opening a word-for-word duplicate of a feature request that the maintainers have already rejected will not result in a reconsideration of the initial request. The decision to reject #19450 was not arbitrary nor was it unilateral on my part. The NetBox maintainers discussed this as a group and decided together that the feature is currently out of the scope for NetBox's core feature set. We understand that you, and others in the community, disagree. However, we will not be re-opening this discussion right now. The proposal was given due consideration, but was ultimately rejected. Will our view change in the future? I don't know, but it certainly hasn't changed in the barely more than a month since the initial rejection. As always, you are welcome to implement and maintain this feature in a fork of NetBox.
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#11369
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?