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

Unable to select VLANs on Device Interfaces where they are scoped by Cluster or Cluster Groups #8141

New Issue
Closed
opened 2025-12-29 20:33:01 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:33:01 +01:00
Owner
Copy Link

Originally created by @stuntguy3000 on GitHub (May 31, 2023).

NetBox version

v3.5.3-dev

Python version

3.8

Expected Behavior

I expect the available VLANs to include those defined by Cluster or Cluster Group scopes.

Observed Behavior

They are not shown as available options.

Steps to Reproduce

Create the following Virtualization objects:

  • Create a Cluster Type named Generic Cluster Type
  • Create a Cluster Group named Cluster Group 1
  • Create a Cluster named Ungrouped Cluster
  • Create a Cluster named Grouped Cluster (Group: Cluster Group 1)
    image
  • Create a Virtual Machine named Ungrouped Cluster VM (Cluster: Ungrouped Cluster)
  • Create a Virtual Machine named Grouped Cluster VM (Cluster: Grouped Cluster)
    image

Create the following IPAM objects:

  • Create a VLAN Group named Cluster Group 1 VG (Scope: Cluster Group, Cluster Group 1)
  • Create a VLAN Group named Grouped Cluster VG (Scope: Cluster, Grouped Cluster)
    image
  • Create a VLAN named Alpha (Group: Cluster Group 1 VG)
  • Create a VLAN named Beta (Group: Grouped Cluster VG)
    image

Create the following Organization objects:

  • Create a Site named Generic Site

Create the following Device objects:

  • Create a Manufacturer named Generic Manufacturer
  • Create a Device Type named Generic Model (Manufacturer: Generic Manufacturer)
  • Create a Device Role named Generic Role
  • Create a Device named Grouped Cluster Device (Role: Generic Role, Type: Generic Model, Site: Generic Site, Virtualization Cluster: Grouped Cluster)
  • Create a Device named Ungrouped Cluster Device (Role: Generic Role, Type: Generic Model, Site: Generic Site, Virtualization Cluster: Ungrouped Cluster)
    image
  • Add an Interface (of any type) to Grouped Cluster Device named Generic Interface
  • Add an Interface (of any type) to Ungrouped Cluster Device named Generic Interface

Finally... replicate the issue:

  • Attempt to add a untagged or tagged VLAN to each device's interface
    image
    image

This is the issue - no VLANS will be present, including those which should be

Notes

This issue has been resolved in a branch in my fork. If this issue has been resolved this will be submitted as a new PR addressing this specific issue.

This issue only applies to Devices, but not Virtual Machines.

I hope this isn't death by information, please let me know if I can do anything more to get this accepted and resolved (including a video walkthrough or database object dump).

References

This section of code already exists and performs the correct filtering.

This section of the code are my changes which adds this correct filtering/resolves this issue.

Originally created by @stuntguy3000 on GitHub (May 31, 2023). ### NetBox version v3.5.3-dev ### Python version 3.8 ### Expected Behavior I expect the available VLANs to include those defined by Cluster or Cluster Group scopes. ### Observed Behavior They are not shown as available options. ------------------------------ ### Steps to Reproduce Create the following **Virtualization** objects: - Create a **Cluster Type** named `Generic Cluster Type` - Create a **Cluster Group** named `Cluster Group 1` - Create a **Cluster** named `Ungrouped Cluster` - Create a **Cluster** named `Grouped Cluster` (Group: `Cluster Group 1`) ![image](https://github.com/netbox-community/netbox/assets/1522389/cff1b24b-4b76-4390-b006-4cc3cf23e814) - Create a **Virtual Machine** named `Ungrouped Cluster VM` (Cluster: `Ungrouped Cluster`) - Create a **Virtual Machine** named `Grouped Cluster VM` (Cluster: `Grouped Cluster`) ![image](https://github.com/netbox-community/netbox/assets/1522389/84f9f9de-3e26-4d2e-bdff-d3633f14c1f9) Create the following **IPAM** objects: - Create a **VLAN Group** named `Cluster Group 1 VG` (Scope: `Cluster Group`, `Cluster Group 1`) - Create a **VLAN Group** named `Grouped Cluster VG` (Scope: `Cluster`, `Grouped Cluster`) ![image](https://github.com/netbox-community/netbox/assets/1522389/4fcdacaf-188e-4492-8d6f-a4756f13b0f5) - Create a **VLAN** named `Alpha` (Group: `Cluster Group 1 VG`) - Create a **VLAN** named `Beta` (Group: `Grouped Cluster VG`) ![image](https://github.com/netbox-community/netbox/assets/1522389/1f20ff85-fd04-4586-a5f9-3a5ebd5ebe16) Create the following **Organization** objects: - Create a **Site** named `Generic Site` Create the following **Device** objects: - Create a **Manufacturer** named `Generic Manufacturer` - Create a **Device Type** named `Generic Model` (Manufacturer: `Generic Manufacturer`) - Create a **Device Role** named `Generic Role` - Create a **Device** named `Grouped Cluster Device` (Role: `Generic Role`, Type: `Generic Model`, Site: `Generic Site`, Virtualization Cluster: `Grouped Cluster`) - Create a **Device** named `Ungrouped Cluster Device` (Role: `Generic Role`, Type: `Generic Model`, Site: `Generic Site`, Virtualization Cluster: `Ungrouped Cluster`) ![image](https://github.com/netbox-community/netbox/assets/1522389/8ce8d9ee-8ec1-4dec-9647-2985702acb23) - Add an **Interface** (of any type) to `Grouped Cluster Device` named `Generic Interface` - Add an **Interface** (of any type) to `Ungrouped Cluster Device` named `Generic Interface` Finally... replicate the issue: - Attempt to add a untagged or tagged VLAN to each device's interface ![image](https://github.com/netbox-community/netbox/assets/1522389/335e72b2-fe97-4417-9db5-c65544410a02) ![image](https://github.com/netbox-community/netbox/assets/1522389/b62bde84-4d30-489a-a6e2-86451dfcad18) **This is the issue - no VLANS will be present, including those which should be** ------------------------------ ### Notes This issue has been resolved in a branch in my fork. If this issue has been resolved this will be submitted as a new PR addressing this specific issue. This issue only applies to **Devices**, but not **Virtual Machines**. I hope this isn't death by information, please let me know if I can do anything more to get this accepted and resolved (including a video walkthrough or database object dump). #### References [This section](https://github.com/stuntguy3000/netbox/blob/2038eb3ff633dc70b4220fa1874334177482e8f9/netbox/ipam/querysets.py#L95-L105) of code already exists and performs the correct filtering. [This section](https://github.com/stuntguy3000/netbox/blob/2038eb3ff633dc70b4220fa1874334177482e8f9/netbox/ipam/querysets.py#L67-L76) of the code are my changes which adds this correct filtering/resolves this issue.
adam closed this issue 2025-12-29 20:33:01 +01:00
adam commented 2025-12-29 20:33:02 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (May 31, 2023):

Ready for review.

@stuntguy3000 commented on GitHub (May 31, 2023): Ready for review.
adam commented 2025-12-29 20:33:02 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (Jun 11, 2023):

Sorry for the bump @jeremystretch, I've got a code fix for this ready to go as you requested in the previous issue - will create a PR if/when this is accepted.

@stuntguy3000 commented on GitHub (Jun 11, 2023): Sorry for the bump @jeremystretch, I've got a code fix for this ready to go as you requested in the previous issue - will create a PR if/when this is accepted.
adam commented 2025-12-29 20:33:02 +01:00
Author
Owner
Copy Link

@SteveRodrigue commented on GitHub (Jul 28, 2023):

@stuntguy3000 : Thanks to have reformatted the original issue. Also, thank you very to have proposed a solution.

I just tested https://demo.netbox.dev and I confirm the problem is still present. The current workaround I found is to assign vlan(s) using the API directly.

@SteveRodrigue commented on GitHub (Jul 28, 2023): @stuntguy3000 : Thanks to have reformatted the [original issue](https://github.com/netbox-community/netbox/issues/12690). Also, thank you very to have proposed a solution. I just tested https://demo.netbox.dev and I confirm the problem is still present. The current workaround I found is to assign vlan(s) using the API directly.
adam commented 2025-12-29 20:33:03 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (Jul 29, 2023):

I still have a PR for this, https://github.com/netbox-community/netbox/pull/12708

@stuntguy3000 commented on GitHub (Jul 29, 2023): I still have a PR for this, https://github.com/netbox-community/netbox/pull/12708
adam commented 2025-12-29 20:33:03 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Aug 4, 2023):

@DanSheps as you already interacted with issue https://github.com/netbox-community/netbox/issues/12690, do you feel the steps described here are sufficient to replicate the issue ? Feels like the solution is simple enough.

@jsenecal commented on GitHub (Aug 4, 2023): @DanSheps as you already interacted with issue https://github.com/netbox-community/netbox/issues/12690, do you feel the steps described here are sufficient to replicate the issue ? Feels like the solution is simple enough.
adam commented 2025-12-29 20:33:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 21, 2023):

@stuntguy3000 thank you for providing comprehensive reproduction steps.

While I believe I understand the use case, I'll posit a conflicting use case. Consider a scenario wherein a VLAN is shared among virtual machines within a cluster, but not available to the host device. (This is a quite common solution to providing isolated L2 domains.) In such a scenario, I definitely don't want to consider the VLAN as being available on the host device, which is why the available_on_device VLAN filter does not currently consider cluster assignment.

This should really be a feature request rather than a bug report, proposing that cluster assignment be considered when determining the VLANs available on a device.

@jeremystretch commented on GitHub (Sep 21, 2023): @stuntguy3000 thank you for providing comprehensive reproduction steps. While I believe I understand the use case, I'll posit a conflicting use case. Consider a scenario wherein a VLAN is shared among virtual machines within a cluster, but not available to the host device. (This is a quite common solution to providing isolated L2 domains.) In such a scenario, I definitely _don't_ want to consider the VLAN as being available on the host device, which is why the `available_on_device` VLAN filter does not currently consider cluster assignment. This should really be a feature request rather than a bug report, proposing that cluster assignment be considered when determining the VLANs available on a device.
adam commented 2025-12-29 20:33:03 +01:00
Author
Owner
Copy Link

@stuntguy3000 commented on GitHub (Sep 23, 2023):

@stuntguy3000 thank you for providing comprehensive reproduction steps.

While I believe I understand the use case, I'll posit a conflicting use case. Consider a scenario wherein a VLAN is shared among virtual machines within a cluster, but not available to the host device. (This is a quite common solution to providing isolated L2 domains.) In such a scenario, I definitely don't want to consider the VLAN as being available on the host device, which is why the available_on_device VLAN filter does not currently consider cluster assignment.

This should really be a feature request rather than a bug report, proposing that cluster assignment be considered when determining the VLANs available on a device.

I definitely follow you, in that scenario then it makes sense to not show the vlan. However, I believe that usage would be less common than people who use fully-connected virtual groups and hosts.

My rationale is that, simply put, not having VLANs visible make it harder to document entire Clusters and Cluster Groups where VLANs are usually stretched across VM Hosts and their associated VMs.

Alternatively, I could see an introduction of VM Groups within Clusters, hypothetically where these isolated VLANs could be scoped too. These groups would roughly represent Folders that contain VMs. I believe that is an elegant solution to your use case.

@stuntguy3000 commented on GitHub (Sep 23, 2023): > @stuntguy3000 thank you for providing comprehensive reproduction steps. > > While I believe I understand the use case, I'll posit a conflicting use case. Consider a scenario wherein a VLAN is shared among virtual machines within a cluster, but not available to the host device. (This is a quite common solution to providing isolated L2 domains.) In such a scenario, I definitely _don't_ want to consider the VLAN as being available on the host device, which is why the `available_on_device` VLAN filter does not currently consider cluster assignment. > > This should really be a feature request rather than a bug report, proposing that cluster assignment be considered when determining the VLANs available on a device. I definitely follow you, in that scenario then it makes sense to not show the vlan. However, I believe that usage would be less common than people who use fully-connected virtual groups and hosts. My rationale is that, simply put, not having VLANs visible make it harder to document entire Clusters and Cluster Groups where **VLANs are _usually_ stretched across VM Hosts** and their associated VMs. Alternatively, I could see an introduction of **VM Groups** _within_ **Clusters**, hypothetically where these isolated VLANs could be scoped too. These groups would _roughly_ represent Folders that contain VMs. I believe that is an elegant solution to your use case.
adam commented 2025-12-29 20:33:04 +01:00
Author
Owner
Copy Link

@Chiniquy commented on GitHub (Oct 11, 2023):

Just ran into the same issue when trying to model VLAN usage for virtual interfaces on a Palo Alto firewall. What is required as a next step to get something actionable here? A feature request?

@Chiniquy commented on GitHub (Oct 11, 2023): Just ran into the same issue when trying to model VLAN usage for virtual interfaces on a Palo Alto firewall. What is required as a next step to get something actionable here? A feature request?
adam commented 2025-12-29 20:33:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 26, 2023):

Closing this out as this is not an actionable bug report per the above discussion. Anyone is welcome to open a feature request proposing that the described behavior be implemented, along with a compelling use case.

@jeremystretch commented on GitHub (Dec 26, 2023): Closing this out as this is not an actionable bug report per the above discussion. Anyone is welcome to open a feature request proposing that the described behavior be implemented, along with a compelling use case.
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
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#8141
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?