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

Add Role field to Virtual Chassis model #5057

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

Originally created by @sleepinggenius2 on GitHub (Jul 9, 2021).

NetBox version

v2.11.3

Feature type

Data model extension

Proposed functionality

I propose adding a Role field to the Virtual Chassis model, just like we have the Device role field on Device today.

Use case

My company uses the device role in our naming conventions, as I believe a number of other companies do as well. We currently utilize reactive reporting to enforce compliance, but are looking to move toward more proactive enforcement with the upcoming custom validators. It would be useful to be able to do the same thing with Virtual Chassis naming as we are able to do with Device naming. We looked at doing this with a custom field, but that seemed overly tedious to maintain versus this solution.

Database changes

Add a Role field to the Virtual Chassis model, just like the Device role field on Device today

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Jul 9, 2021). ### NetBox version v2.11.3 ### Feature type Data model extension ### Proposed functionality I propose adding a _Role_ field to the _Virtual Chassis_ model, just like we have the _Device role_ field on _Device_ today. ### Use case My company uses the device role in our naming conventions, as I believe a number of other companies do as well. We currently utilize reactive reporting to enforce compliance, but are looking to move toward more proactive enforcement with the upcoming custom validators. It would be useful to be able to do the same thing with _Virtual Chassis_ naming as we are able to do with _Device_ naming. We looked at doing this with a custom field, but that seemed overly tedious to maintain versus this solution. ### Database changes Add a _Role_ field to the _Virtual Chassis_ model, just like the _Device role_ field on _Device_ today ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 19:23:37 +01:00
adam closed this issue 2025-12-29 19:23:38 +01:00
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 15, 2021):

Presumably the role for the virtual chassis would be the same as the switch, could you not check the master switch role in your reporting against the virtual chassis?

@DanSheps commented on GitHub (Jul 15, 2021): Presumably the role for the virtual chassis would be the same as the switch, could you not check the master switch role in your reporting against the virtual chassis?
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 15, 2021):

We have a few scenarios in our current implementation where that doesn't quite work. In the common use case of something like a homogeneous switch stack, I can see where adding the first switch as the master and then checking that additional devices have the same role would work.

The first scenario is that we currently use virtual chassis to represent battery strings in our DC power plant, with the individual batteries as devices under it, so the virtual chassis would have a role of Battery String and the devices would have a role of Battery. There is no "master" in this case. We already model a battery shelf as a container device with bays for the individual batteries and originally looked at just calling each shelf a string, but we found too many places where we have wet cells that span multiple shelves, since they're typically only 2V per cell. It's important for us to have that logical grouping to give it a unique name and attributes. It would be really nice to be able to give a virtual chassis a config context that could be inherited by the child devices, but I realize that would be a separate issue.

A second scenario is in our optical network, we like to group the optics together in a shelf by type, so we would have a virtual chassis with a role of Optical Transport and one shelf with a role of Forward Optics containing the transmitters and another with a role of Return Optics containing the receivers, for example. We group them as a virtual chassis, since they share a common control plane. It's also helpful for compliance to require at least one forward shelf and one return shelf within the stack.

A third scenario would be with our blade servers. They have switch modules that can be inserted into the chassis that we give a role of Chassis Ethernet Switch and they connect to the top-of-rack switches that we give a role of ToR Ethernet Switch. We then create a virtual chassis with a role of Ethernet Switch Fabric to model the fabric and allow for creating MC-LAG interfaces.

I am open to suggestions for how to model these scenarios differently, but this is what we've come up with so far using the base NetBox platform.

@sleepinggenius2 commented on GitHub (Jul 15, 2021): We have a few scenarios in our current implementation where that doesn't quite work. In the common use case of something like a homogeneous switch stack, I can see where adding the first switch as the master and then checking that additional devices have the same role would work. The first scenario is that we currently use virtual chassis to represent battery strings in our DC power plant, with the individual batteries as devices under it, so the virtual chassis would have a role of _Battery String_ and the devices would have a role of _Battery_. There is no "master" in this case. We already model a battery shelf as a container device with bays for the individual batteries and originally looked at just calling each shelf a string, but we found too many places where we have wet cells that span multiple shelves, since they're typically only 2V per cell. It's important for us to have that logical grouping to give it a unique name and attributes. It would be really nice to be able to give a virtual chassis a config context that could be inherited by the child devices, but I realize that would be a separate issue. A second scenario is in our optical network, we like to group the optics together in a shelf by type, so we would have a virtual chassis with a role of _Optical Transport_ and one shelf with a role of _Forward Optics_ containing the transmitters and another with a role of _Return Optics_ containing the receivers, for example. We group them as a virtual chassis, since they share a common control plane. It's also helpful for compliance to require at least one forward shelf and one return shelf within the stack. A third scenario would be with our blade servers. They have switch modules that can be inserted into the chassis that we give a role of _Chassis Ethernet Switch_ and they connect to the top-of-rack switches that we give a role of _ToR Ethernet Switch_. We then create a virtual chassis with a role of _Ethernet Switch Fabric_ to model the fabric and allow for creating MC-LAG interfaces. I am open to suggestions for how to model these scenarios differently, but this is what we've come up with so far using the base NetBox platform.
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 30, 2021):

These all seem like pretty niche circumstances unique to your environment, and that is the role that custom fields fill.

I am not sure what would be tedious about defining these roles in custom fields

@DanSheps commented on GitHub (Jul 30, 2021): These all seem like pretty niche circumstances unique to your environment, and that is the role that custom fields fill. I am not sure what would be tedious about defining these roles in custom fields
adam commented 2025-12-29 19:23:39 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jul 30, 2021):

In our environment, the users that are able to manipulate device roles do not have permissions to change custom field definitions, which would be required to update a list of choices. We also use the slug field in our naming conventions, while keeping the Name field on Device Roles human-readable, so we would need to maintain a separate mapping table in our validation code and update it any time there are changes made to the list of Device Roles. That just seemed like a very error-prone solution when the Device Role model already exists and meets our needs.

We have a lot of "devices" in our network that are multi-chassis and have generally treated a "device" or network element as one or more chassis that share a common control plane, so this Device as a single chassis and Virtual Chassis for multiple chassis that share a common control plane model has been a little cumbersome to transition to. I'm certainly open to suggestions if there is a different way that is supposed to be handled in NetBox. Because there are so many "devices" that fall into this category on our network, it would also be nice to easily see counts for Virtual Chassis roles like we can today for Devices and VMs on the Device Roles list, since that is generally more important for us from a reporting standpoint than the number of individual chassis that we have.

@sleepinggenius2 commented on GitHub (Jul 30, 2021): In our environment, the users that are able to manipulate device roles do not have permissions to change custom field definitions, which would be required to update a list of choices. We also use the slug field in our naming conventions, while keeping the Name field on Device Roles human-readable, so we would need to maintain a separate mapping table in our validation code and update it any time there are changes made to the list of Device Roles. That just seemed like a very error-prone solution when the Device Role model already exists and meets our needs. We have a lot of "devices" in our network that are multi-chassis and have generally treated a "device" or network element as one or more chassis that share a common control plane, so this Device as a single chassis and Virtual Chassis for multiple chassis that share a common control plane model has been a little cumbersome to transition to. I'm certainly open to suggestions if there is a different way that is supposed to be handled in NetBox. Because there are so many "devices" that fall into this category on our network, it would also be nice to easily see counts for Virtual Chassis roles like we can today for Devices and VMs on the Device Roles list, since that is generally more important for us from a reporting standpoint than the number of individual chassis that we have.
adam commented 2025-12-29 19:23:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 1, 2021):

Closing for inactivity as there has been no further comment from the community.

@jeremystretch commented on GitHub (Sep 1, 2021): Closing for inactivity as there has been no further comment from the community.
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 pending closure 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#5057
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?