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 NIC chipset, and PCI address at the device type level that will propagate to the device level #8897

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

Originally created by @dfitzpatrick128 on GitHub (Nov 30, 2023).

NetBox version

v3.4.4

Feature type

Data model extension

Proposed functionality

Adding an optional field for NIC chipset, and PCI address at the device type level that will propagate to the device level. We currently do this as custom fields at the device level. It is in my opinion very very laborious to do this when deploying 10s of the same device only to have to repopulate each device with the chipset and pci that is the same.

Follow up to
https://github.com/netbox-community/netbox/issues/9243
and
https://github.com/netbox-community/netbox/issues/13540#issuecomment-1691574308

Use case

We track several additional fields such as NIC chipset, NIC PCIe address, etc that would be well suited to track at the device type level since they are associated with different device models. Currently we have to manually populate those fields each time we create a new device of that device type.

Database changes

No response

External dependencies

No response

Originally created by @dfitzpatrick128 on GitHub (Nov 30, 2023). ### NetBox version v3.4.4 ### Feature type Data model extension ### Proposed functionality Adding an optional field for NIC chipset, and PCI address at the device type level that will propagate to the device level. We currently do this as custom fields at the device level. It is in my opinion very very laborious to do this when deploying 10s of the same device only to have to repopulate each device with the chipset and pci that is the same. Follow up to https://github.com/netbox-community/netbox/issues/9243 and https://github.com/netbox-community/netbox/issues/13540#issuecomment-1691574308 ### Use case We track several additional fields such as NIC chipset, NIC PCIe address, etc that would be well suited to track at the device type level since they are associated with different device models. Currently we have to manually populate those fields each time we create a new device of that device type. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: revisions needed labels 2025-12-29 20:42:38 +01:00
adam closed this issue 2025-12-29 20:42:38 +01:00
adam commented 2025-12-29 20:42:38 +01:00
Author
Owner
Copy Link

@mdzwil-JNPR commented on GitHub (Nov 30, 2023):

I would also like this proposed functionality!

@mdzwil-JNPR commented on GitHub (Nov 30, 2023): I would also like this proposed functionality!
adam commented 2025-12-29 20:42:39 +01:00
Author
Owner
Copy Link

@dfitzpatrick128 commented on GitHub (Nov 30, 2023):

If a PR was opened to add this functionality @jeremystretch would it be struck down/ not allowed? It seems like a small PR

@dfitzpatrick128 commented on GitHub (Nov 30, 2023): If a PR was opened to add this functionality @jeremystretch would it be struck down/ not allowed? It seems like a small PR
adam commented 2025-12-29 20:42:39 +01:00
Author
Owner
Copy Link

@pratik-maharjan commented on GitHub (Nov 30, 2023):

It would certainly make sense to add ability to propagate certain fields and data within to the devices.

@pratik-maharjan commented on GitHub (Nov 30, 2023): It would certainly make sense to add ability to propagate certain fields and data within to the devices.
adam commented 2025-12-29 20:42:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 30, 2023):

I would also like this proposed functionality!

Please use 👍 and 👎 reactions on issues to vote.

If a PR was opened to add this functionality @jeremystretch would it be struck down/ not allowed? It seems like a small PR

Per our contributing guide:

It's very important that you not submit a pull request until a relevant issue has been opened and assigned to you. Otherwise, you risk wasting time on work that may ultimately not be needed.

@dfitzpatrick128 please add more detail to your FR, as it's not actionable in its current form. You propose the addition of new database fields yet don't list anything under "database changes." Please also describe the intended replication behavior as it's not clear from your description above.

@jeremystretch commented on GitHub (Nov 30, 2023): > I would also like this proposed functionality! Please use :+1: and :-1: reactions on issues to vote. > If a PR was opened to add this functionality @jeremystretch would it be struck down/ not allowed? It seems like a small PR Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md#arrow_heading_up-submitting-pull-requests): > It's very important that you not submit a pull request until a relevant issue has been opened and assigned to you. Otherwise, you risk wasting time on work that may ultimately not be needed. @dfitzpatrick128 please add more detail to your FR, as it's not actionable in its current form. You propose the addition of new database fields yet don't list anything under "database changes." Please also describe the intended replication behavior as it's not clear from your description above.
adam commented 2025-12-29 20:42:39 +01:00
Author
Owner
Copy Link

@bitcollector1 commented on GitHub (Dec 9, 2023):

I'm currently using the label to denote the PCI BUS address for our server interfaces, but an official place holder would be welcomed by me.

We also track things like drivers and firmware levels for all these server interfaces, so that would also be welcomed, currently we track a bunch of things in custom fields or tag it in inventory.

@bitcollector1 commented on GitHub (Dec 9, 2023): I'm currently using the label to denote the PCI BUS address for our server interfaces, but an official place holder would be welcomed by me. We also track things like drivers and firmware levels for all these server interfaces, so that would also be welcomed, currently we track a bunch of things in custom fields or tag it in inventory.
adam commented 2025-12-29 20:42:39 +01:00
Author
Owner
Copy Link

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

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@jeremystretch commented on GitHub (Dec 27, 2023): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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 status: revisions needed 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#8897
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?