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) #11152

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

Originally created by @PieterL75 on GitHub (May 9, 2025).

NetBox version

v4.1.11

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 (May 9, 2025). ### NetBox version v4.1.11 ### 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:41:00 +01:00
adam closed this issue 2025-12-29 21:41:00 +01:00
adam commented 2025-12-29 21:41:01 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (May 16, 2025):

It could also solve the problem written here https://github.com/netbox-community/netbox/issues/4867
When there are 'virtual' mac addresses for a HA cluster. The interface created on the cluster, can have it's own MAC address
Eliminating the need for multiple MAC addresses on one interface (which I found a doubtful FR when I learned about it)

@PieterL75 commented on GitHub (May 16, 2025): It could also solve the problem written here https://github.com/netbox-community/netbox/issues/4867 When there are 'virtual' mac addresses for a HA cluster. The interface created on the cluster, can have it's own MAC address Eliminating the need for multiple MAC addresses on one interface (which I found a doubtful FR when I learned about it)
adam commented 2025-12-29 21:41:01 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (May 27, 2025):

Another usecase :
When documenting ESXi/vCenter resources, it is a challenge to link the interfaces of all ESXi nodes to one configuration ( All uplinks of clustered ESXi hosts MUST have the same vlans for example).
This FR can also be used to document the physical part of the vCenter cluster and the member ESXi hosts

Maybe a good add, is that a functional cluster can be part of a virtual.cluster.

@PieterL75 commented on GitHub (May 27, 2025): Another usecase : When documenting ESXi/vCenter resources, it is a challenge to link the interfaces of all ESXi nodes to one configuration ( All uplinks of clustered ESXi hosts MUST have the same vlans for example). This FR can also be used to document the physical part of the vCenter cluster and the member ESXi hosts Maybe a good add, is that a functional cluster can be part of a virtual.cluster.
adam commented 2025-12-29 21:41:03 +01:00
Author
Owner
Copy Link

@cmcknz77 commented on GitHub (Jun 3, 2025):

Need almost exactly this but for Virtual_Clusters for properly modelling stacked switches.

@cmcknz77 commented on GitHub (Jun 3, 2025): Need almost exactly this but for Virtual_Clusters for properly modelling stacked switches.
adam commented 2025-12-29 21:41:05 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jun 5, 2025):

@PieterL75, the proposed functionality falls outside the current scope of NetBox's core feature set. It may make a good candidate for a NetBox plugin, and we encourage you to pursue its development and a standalone project.

@jnovinger commented on GitHub (Jun 5, 2025): @PieterL75, the proposed functionality falls outside the current scope of NetBox's core feature set. It may make a good candidate for a [NetBox plugin](https://netbox.readthedocs.io/en/stable/plugins/), and we encourage you to pursue its development and a standalone project.
adam commented 2025-12-29 21:41:05 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jun 6, 2025):

@jnovinger
Jason,
How can this not be a core feature ?
You have VirtualChassis, VirtualDeviceContext and VirtualCluster.
This FR is a the closing part of these 3 concepts, and with 10 👍 something that the community wants.

A Plugin never integrates as smooth as a core function. The info is scattered on lower left/right and not within the direct view.

I hope you re-evaluate the request and make a different decision

Pieter

@PieterL75 commented on GitHub (Jun 6, 2025): @jnovinger Jason, How can this not be a core feature ? You have VirtualChassis, VirtualDeviceContext and VirtualCluster. This FR is a the closing part of these 3 concepts, and with 10 👍 something that the community wants. A Plugin never integrates as smooth as a core function. The info is scattered on lower left/right and not within the direct view. I hope you re-evaluate the request and make a different decision Pieter
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#11152
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?