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

Clone Custom Fields on Component Template Instantiation #11777

New Issue
Open
opened 2025-12-29 21:49:45 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:49:45 +01:00
Owner
Copy Link

Originally created by @anshulkamath on GitHub (Oct 25, 2025).

NetBox version

v4.4.4

Feature type

Change to existing functionality

Proposed functionality

It seems that none of the component templates have a "custom fields" section. As someone who performs large scale ingests of data centers, I would like the ability to define "templated custom fields" that can be cloned to the instantiated object.

Use case

We illustrate the use case with a practical example: suppose that I am instantiating a leaf-spine topology in Netbox. I've created a "interface roles" custom field which describes how each templated interface is meant to behave (i.e., this is an uplink/downlink/BGP speaker, etc.). When I'm instantiating this large fabric, I'd like the child devices to initialize with these roles.

This extends to any "enrichment" of a template with some context of the component.

Database changes

This will require that the component template models add field for custom fields, most likely. This will correspond to "all cloneable custom fields for the component".

External dependencies

Nope

Originally created by @anshulkamath on GitHub (Oct 25, 2025). ### NetBox version v4.4.4 ### Feature type Change to existing functionality ### Proposed functionality It seems that none of the component templates have a "custom fields" section. As someone who performs large scale ingests of data centers, I would like the ability to define "templated custom fields" that can be cloned to the instantiated object. ### Use case We illustrate the use case with a practical example: suppose that I am instantiating a leaf-spine topology in Netbox. I've created a "interface roles" custom field which describes how each templated interface is meant to behave (i.e., this is an uplink/downlink/BGP speaker, etc.). When I'm instantiating this large fabric, I'd like the child devices to initialize with these roles. This extends to any "enrichment" of a template with some context of the component. ### Database changes This will require that the component template models add field for custom fields, most likely. This will correspond to "all cloneable custom fields for the component". ### External dependencies Nope
adam added the type: featurestatus: under reviewnetbox labels 2025-12-29 21:49:45 +01:00
adam commented 2025-12-29 21:49:45 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 3, 2025):

Component templates describe the physical hardware structure of a device type, not its operational role or deployment context. The same device type (e.g., a specific switch model) might be deployed as a leaf switch in a fabric, a simple top-of-rack switch, or in different network roles with different interface purposes. Enriching component templates with operational context (interface roles, behaviors) conflates these two concerns and will create problems down the road when the same device type needs to be deployed in different scenarios. Binding operational roles to the device type prevents this reuse and conflates hardware characteristics with deployment decisions.

The "uplink/downlink/BGP speaker" roles you're describing are properties of how you're deploying a specific device, not characteristics of the device type itself. Hardcoding these into templates means you can't use the same device type in different contexts without either creating duplicate device types or accepting incorrect role information.

Automation tools are better suited for this workflow, like Ansible, Terraform, or other tools. These can template the operational enrichment (interface roles, etc.).

@jnovinger commented on GitHub (Nov 3, 2025): Component templates describe the physical hardware structure of a device type, not its operational role or deployment context. The same device type (e.g., a specific switch model) might be deployed as a leaf switch in a fabric, a simple top-of-rack switch, or in different network roles with different interface purposes. Enriching component templates with operational context (interface roles, behaviors) conflates these two concerns and _will_ create problems down the road when the same device type needs to be deployed in different scenarios. Binding operational roles to the device type prevents this reuse and conflates hardware characteristics with deployment decisions. The "uplink/downlink/BGP speaker" roles you're describing are properties of how you're deploying a specific device, not characteristics of the device type itself. Hardcoding these into templates means you can't use the same device type in different contexts without either creating duplicate device types or accepting incorrect role information. Automation tools are better suited for this workflow, like Ansible, Terraform, or other tools. These can template the operational enrichment (interface roles, etc.).
adam commented 2025-12-29 21:49:46 +01:00
Author
Owner
Copy Link

@anshulkamath commented on GitHub (Nov 4, 2025):

I agree with you in principle, but treating the device type as sacred chains you to the data model, and the data model may not always be representative of physical reality. If I am understanding the core of your argument, you're saying that the device type should reflect the manufacturer's data sheet / physical reality.

But what if I want to run a switch in breakout mode? The data model (as it stands today) does not allow me to reflect the channelization of the interface cleanly, and I have to operate within the confines of the data model to represent my reality. In an ideal world, we would keep the device type consistent with the data sheet and update the instance as desired, but now that means "adding and deleting 10s of interfaces on every instantiation of a ToR," of which there could be hundreds.

The spirit of custom fields is to allow extensions of the data model. From my understanding, component templates are really just "templates to be copied at instantiation time," so wouldn't it make sense for "cloneable" custom fields to be added and copied to these templates? It seems like a natural extension to me. I can understand that this specific use case may not be in the spirit of the data model, but that feels more like an implementation detail and not a design one.

@anshulkamath commented on GitHub (Nov 4, 2025): I agree with you in principle, but treating the device type as sacred chains you to the data model, and the data model may not always be representative of physical reality. If I am understanding the core of your argument, you're saying that the device type should reflect the manufacturer's data sheet / physical reality. But what if I want to run a switch in breakout mode? The data model (as it stands today) does not allow me to reflect the channelization of the interface cleanly, and I have [to operate within the confines of the data model to represent my reality](https://github.com/netbox-community/netbox/discussions/11917). In an ideal world, we would keep the device type consistent with the data sheet and update the instance as desired, but now that means "adding and deleting 10s of interfaces on every instantiation of a ToR," of which there could be hundreds. The spirit of custom fields is to allow extensions of the data model. From my understanding, component templates are really just "templates to be copied at instantiation time," so wouldn't it make sense for "cloneable" custom fields to be added and copied to these templates? It seems like a natural extension to me. I can understand that this specific use case may not be in the spirit of the data model, but that feels more like an implementation detail and not a design one.
adam commented 2025-12-29 21:49:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 4, 2025):

@anshulkamath the issue with your proposed strategy is that it conflates configuration details with the physical hardware. This only works if you use that piece of hardware exclusively in a single role, which is obviously not an assumption NetBox can (or should) make.

For example, let's say you introduce an "interface role" custom field for device type interfaces (the InterfaceTemplate model). And suppose you always use Juniper QFX5110 switches for your leaf switches, so you set about populating interface roles for all the interfaces templates for the QFX5110 device type. When you deploy a new leaf switch, all its interface roles get populated from the device type as you'd like.

But then you start using QFX5110s in some other capacity (e.g. storage networking) where those operational roles no longer make sense. Now you have storage switches with interface roles belonging to a leaf switch, which is incorrect and confusing. Hence @jnovinger's point above about the necessity of separating configuration details from the physical hardware. Device type components exist solely to replicate physical attributes.

What you're really after is some mechanism for populating configuration details on instantiated devices, separate from the instantiation itself. You have a few options for this:

  1. Employ automated tools like Terraform or Ansible to prescribe and effect these changes en masse after populating the devices (or do everything at once).
  2. Write a custom script to make these necessary changes to a selected set of devices, or even go as far as automating the entire topology build.
  3. Manually apply the changes. This can be a bit tedious, but might be sufficient when dealing with relative small sets. (Interface attributes can be editing in bulk.)
@jeremystretch commented on GitHub (Nov 4, 2025): @anshulkamath the issue with your proposed strategy is that it conflates configuration details with the physical hardware. This only works if you use that piece of hardware exclusively in a single role, which is obviously not an assumption NetBox can (or should) make. For example, let's say you introduce an "interface role" custom field for device type interfaces (the InterfaceTemplate model). And suppose you always use Juniper QFX5110 switches for your leaf switches, so you set about populating interface roles for all the interfaces templates for the QFX5110 device type. When you deploy a new leaf switch, all its interface roles get populated from the device type as you'd like. But then you start using QFX5110s in some other capacity (e.g. storage networking) where those operational roles no longer make sense. Now you have storage switches with interface roles belonging to a leaf switch, which is incorrect and confusing. Hence @jnovinger's point above about the necessity of separating configuration details from the physical hardware. Device type components exist solely to replicate physical attributes. What you're really after is some mechanism for populating configuration details on instantiated devices, separate from the instantiation itself. You have a few options for this: 1. Employ automated tools like Terraform or Ansible to prescribe and effect these changes en masse after populating the devices (or do everything at once). 2. Write a custom script to make these necessary changes to a selected set of devices, or even go as far as automating the entire topology build. 3. Manually apply the changes. This can be a bit tedious, but might be sufficient when dealing with relative small sets. (Interface attributes can be editing in bulk.)
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 netbox status: under review 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#11777
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?