starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-03-13 13:56:25 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow Filtering IP Addresses by Related Virtual Machine Role #10498

New Issue
Open
opened 2025-12-29 21:32:16 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:32:16 +01:00
Owner
Copy Link

Originally created by @robduffy2010 on GitHub (Nov 21, 2024).

NetBox version

v4.1.6

Feature type

New functionality

Triage priority

I volunteer to perform this work (if approved)

Proposed functionality

Right, now it's possible to filter an IP address by it's related virtual machine name or ID. We would like to be able to also filter by the related virtual machine role.

https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/filtersets.py#L613

Use case

It can be very convenient to find all IPs connected to VMs with a particular role. For example, all Radius, AD or DNS server IP addresses.

Database changes

NA

External dependencies

NA

Originally created by @robduffy2010 on GitHub (Nov 21, 2024). ### NetBox version v4.1.6 ### Feature type New functionality ### Triage priority I volunteer to perform this work (if approved) ### Proposed functionality Right, now it's possible to filter an IP address by it's related virtual machine name or ID. We would like to be able to also filter by the related virtual machine role. https://github.com/netbox-community/netbox/blob/develop/netbox/ipam/filtersets.py#L613 ### Use case It can be very convenient to find all IPs connected to VMs with a particular role. For example, all Radius, AD or DNS server IP addresses. ### Database changes NA ### External dependencies NA
adam added the type: featurenetboxstatus: backlogcomplexity: low labels 2025-12-29 21:32:16 +01:00
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@robduffy2010 commented on GitHub (Nov 26, 2024):

@bctiemann could you take a look at the pull request for this one when you have some time? I originally forgot to link the pull request to an issue so it might have been missed.

@robduffy2010 commented on GitHub (Nov 26, 2024): @bctiemann could you take a look at the pull request for this one when you have some time? I originally forgot to link the pull request to an issue so it might have been missed.
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Nov 26, 2024):

@robduffy2010 thanks for your work on this. There's been some internal discussion around how supportable this kind of change is, where this would set a precedent for arbitrary fields on related models to be broadly thought of as filterable through the addition of simple, incremental, even in-spirit additions like this. I think that where we've landed is that having pk and name is the limit of what fields on related objects we want to be filterable per the pervasive systemwide pattern, and beyond that we shouldn't add the functionality unless/until we develop a way to make it sustainable at scale (i.e. some kind of auto-config framework that eliminates the need for maintenance).

What we want to avoid in particular is inviting future contributors to see opportunities to add arbitrary filter fields like this one, which would certainly happen (considering how comparatively little effort it takes to extend the classes piecemeal). While convenient, it's not maintainable. My apologies!

@bctiemann commented on GitHub (Nov 26, 2024): @robduffy2010 thanks for your work on this. There's been some internal discussion around how supportable this kind of change is, where this would set a precedent for arbitrary fields on related models to be broadly thought of as filterable through the addition of simple, incremental, even in-spirit additions like this. I think that where we've landed is that having `pk` and `name` is the limit of what fields on related objects we want to be filterable per the pervasive systemwide pattern, and beyond that we shouldn't add the functionality unless/until we develop a way to make it sustainable at scale (i.e. some kind of auto-config framework that eliminates the need for maintenance). What we want to avoid in particular is inviting future contributors to see opportunities to add arbitrary filter fields like this one, which would certainly happen (considering how comparatively little effort it takes to extend the classes piecemeal). While convenient, it's not maintainable. My apologies!
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@robduffy2010 commented on GitHub (Nov 26, 2024):

While this is a good use case, I understand the reasoning and not wanting to set a precedent. I'll go ahead and close the pull request.

As a workaround, I'd like to search for VM names which include a specific string. However, this doesn't seem to work according to the documentation. Is this as intended or is it a bug?

@robduffy2010 commented on GitHub (Nov 26, 2024): While this is a good use case, I understand the reasoning and not wanting to set a precedent. I'll go ahead and close the pull request. As a workaround, I'd like to search for VM names which include a specific string. However, this doesn't seem to work according to the documentation. Is this as intended or is it a bug?
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@robduffy2010 commented on GitHub (Nov 26, 2024):

Just to clarify, I'm referring to the __ic filter referenced in the documentation.

https://demo.netbox.dev/static/docs/rest-api/filtering/#string-fields

The query I'm using is.

https://netbox.company.tld/api/ipam/ip-addresses/?virtual_machine__ic=rad

@robduffy2010 commented on GitHub (Nov 26, 2024): Just to clarify, I'm referring to the __ic filter referenced in the documentation. https://demo.netbox.dev/static/docs/rest-api/filtering/#string-fields The query I'm using is. https://netbox.company.tld/api/ipam/ip-addresses/?virtual_machine__ic=rad
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 9, 2025):

Hi @robduffy2010, are you still working on this?

@jeremystretch commented on GitHub (Apr 9, 2025): Hi @robduffy2010, are you still working on this?
adam commented 2025-12-29 21:32:18 +01:00
Author
Owner
Copy Link

@robduffy2010 commented on GitHub (Apr 9, 2025):

@jeremystretch the change was initially approved so I sent in a pull request. It was then rejected as the core team changed their mind regarding which types of changes ought to be permitted. If it's now going to be accepted, I can submit a new pull request.

@robduffy2010 commented on GitHub (Apr 9, 2025): @jeremystretch the change was initially approved so I sent in a pull request. It was then rejected as the core team changed their mind regarding which types of changes ought to be permitted. If it's now going to be accepted, I can submit a new pull request.
adam commented 2025-12-29 21:32:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 10, 2025):

Yeah I can definitely see how this sort of thing could spiral out of control without a clear, scalable pattern in place. Looks like something for future consideration.

@jeremystretch commented on GitHub (Apr 10, 2025): Yeah I can definitely see how this sort of thing could spiral out of control without a clear, scalable pattern in place. Looks like something for future consideration.
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@robduffy2010 commented on GitHub (Apr 10, 2025):

Understandable. If this stance changes in the future, I'd be more than happy to resubmit this contribution.

@robduffy2010 commented on GitHub (Apr 10, 2025): Understandable. If this stance changes in the future, I'd be more than happy to resubmit this contribution.
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 complexity: low netbox status: backlog 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#10498
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?