Update Devices with Device-Type Configuration #2646

New Issue

adam · 2025-12-29T18:20:48+01:00

adam commented

2025-12-29 18:20:48 +01:00

Originally created by @Hossy on GitHub (Jun 3, 2019).

Environment

Python version:
NetBox version: 2.5.12

Proposed Functionality

When viewing a Device Type, provide an option to mass-update all or some (selected) Devices associated with that Device Type. Preserve as much existing Device data as possible. Discard data where components are no longer present or haven't been recreated. Allow option for non-destructive update (add only). Case-insensitive match, but case-sensitive update.

In the Device view next to Device Type, put an indicator to show if the Device configuration matches the Device Type (and a link to correct it).

Preview of changes would be nice down the line.

Use Case

When setting up Device for the first time or expanding the documentation of an environment, it becomes necessary to update many Devices of the same type (like adding interface ports where none were previously documented). Instead of deleting these devices and recreating them (writing down all the other data and then re-entering it), it would be better to apply the desired change/correction to the Device Type and apply it to the Devices you need.

Other Notes

It was stated in https://github.com/digitalocean/netbox/issues/2036 that the presumably automatic updating of Devices would not be desired as the end result might be undesirable, but putting the update under the administrator's control would eliminate that fear.

Originally created by @Hossy on GitHub (Jun 3, 2019).  ### Environment * Python version:  * NetBox version: 2.5.12  ### Proposed Functionality When viewing a Device Type, provide an option to mass-update all or some (selected) Devices associated with that Device Type. Preserve as much existing Device data as possible. Discard data where components are no longer present or haven't been recreated. Allow option for non-destructive update (add only). Case-insensitive match, but case-sensitive update. In the Device view next to Device Type, put an indicator to show if the Device configuration matches the Device Type (and a link to correct it). Preview of changes would be nice down the line.  ### Use Case When setting up Device for the first time or expanding the documentation of an environment, it becomes necessary to update many Devices of the same type (like adding interface ports where none were previously documented). Instead of deleting these devices and recreating them (writing down all the _other_ data and then re-entering it), it would be better to apply the desired change/correction to the Device Type and apply it to the Devices you need. ### Other Notes It was stated in https://github.com/digitalocean/netbox/issues/2036 that the presumably automatic updating of Devices would not be desired as the end result might be undesirable, but putting the update under the administrator's control would eliminate that fear.

adam closed this issue

2025-12-29 18:20:48 +01:00

adam commented

2025-12-29 18:20:48 +01:00

@tb-killa commented on GitHub (Jun 4, 2019):

We would advocate such a functionality, we often have topics where we have to edit the template ourselves, but have to touch the devices manually to make the difference.

This would save us a lot of work.

Therefore in any case a 👍

@tb-killa commented on GitHub (Jun 4, 2019): We would advocate such a functionality, we often have topics where we have to edit the template ourselves, but have to touch the devices manually to make the difference. This would save us a lot of work. Therefore in any case a :+1:

adam commented

2025-12-29 18:20:48 +01:00

@cpmills1975 commented on GitHub (Jun 11, 2019):

I've just started playing with Netbox and while I came across this 'feature' fairly early on. I had to delete a couple of devices to recreate them with an updated template. Had I had hundreds of switches and wanted to add, perhaps a mgmt port to them all, that would be a nightmare. I agree though that it needs to be possible to effect only chosen devices and ideally re-use data if a component with the same name has already been added to a specific instance of the device.

Is it feasible to come up with some method of displaying a 'diff' between the current instance of a device and how it will look after changes to the template have been pushed to it?

@cpmills1975 commented on GitHub (Jun 11, 2019): I've just started playing with Netbox and while I came across this 'feature' fairly early on. I had to delete a couple of devices to recreate them with an updated template. Had I had hundreds of switches and wanted to add, perhaps a mgmt port to them all, that would be a nightmare. I agree though that it needs to be possible to effect only chosen devices and ideally re-use data if a component with the same name has already been added to a specific instance of the device. Is it feasible to come up with some method of displaying a 'diff' between the current instance of a device and how it will look after changes to the template have been pushed to it?

adam commented

2025-12-29 18:20:48 +01:00

@lampwins commented on GitHub (Jun 11, 2019):

Note though that device components (including of course interfaces) can easily be added to existing devices in bulk. Simply select the desired devices in the list view and at the bottom left click the blue button to add components.

We have historically felt this balance in functionality far outweighs the risk of unintended retroactive changes, or the significant development effort to build in any sort of diff or contextual warning.

@lampwins commented on GitHub (Jun 11, 2019): Note though that device components (including of course interfaces) can _easily_ be added to existing devices in bulk. Simply select the desired devices in the list view and at the bottom left click the blue button to add components. We have historically felt this balance in functionality far outweighs the risk of unintended retroactive changes, or the _significant_ development effort to build in any sort of diff or contextual warning.

adam commented

2025-12-29 18:20:48 +01:00

@nward commented on GitHub (Jun 16, 2019):

I think a per-device button/api call for copying differences (perhaps additions, but not deletions, or perhaps only deletions for which there is no non-default settings) from the template would be useful.

Perhaps this could be implemented as an external API client or something, too, rather than built in to netbox core - but I think that a button for the same in the UI would be beneficial to many.

@nward commented on GitHub (Jun 16, 2019): I think a per-device button/api call for copying differences (perhaps additions, but not deletions, or perhaps only deletions for which there is no non-default settings) from the template would be useful. Perhaps this could be implemented as an external API client or something, too, rather than built in to netbox core - but I think that a button for the same in the UI would be beneficial to many.

adam commented

2025-12-29 18:20:49 +01:00

@jeremystretch commented on GitHub (Jun 17, 2019):

When setting up Device for the first time or expanding the documentation of an environment, it becomes necessary to update many Devices of the same type (like adding interface ports where none were previously documented).

This is the purpose of device types: First define the physical model of a device with all its components (power, network, etc.) and then create instances of unique devices from that definition. If you find yourself adding new interfaces, for example, to existing devices that should have been there initially, it's because your original device type definition was incomplete.

There are two types of device components: fixed and variable. Fixed components always exist, no matter what, on every instance of a given device type. For example, every single Juniper EX4300-48T ever produced has 48 GigabitEthernet interfaces. These will never change. So, when creating a device type to represent an EX4300-48T, we add 48 appropriately named interfaces to it. There should never be a reason to add or remove these from individual devices, because they are fixed components.

Variable components, on the other hand, may or may not be present on a given device instance. For example, you might have one EX4300-48T with a 4x10GE interface module installed, and one without. Logical interfaces likewise are obviously variable components. NetBox allows you to add these to devices in bulk to specific devices as appropriate without needing to modify the base device type definition.

To summarize, fixed components should be defined on the device type, and variable components should not. Thus, the only reason to modify a device type is to correct an error, and retroactive reconfiguration of devices based on a change to the parent device type should be unnecessary.

Granted, there may be cases where you want to deploy certain complex configurations of devices: for example, a chassis-based switch with many different interfaces in a certain configuration. This use case will be served by deployment templates (#1364) which is planned for implementation in a future release.

@jeremystretch commented on GitHub (Jun 17, 2019): > When setting up Device for the first time or expanding the documentation of an environment, it becomes necessary to update many Devices of the same type (like adding interface ports where none were previously documented). This is the purpose of device types: First define the physical model of a device with all its components (power, network, etc.) and then create instances of unique devices from that definition. If you find yourself adding new interfaces, for example, to existing devices that should have been there initially, it's because your original device type definition was incomplete. There are two types of device components: fixed and variable. Fixed components always exist, no matter what, on every instance of a given device type. For example, every single Juniper EX4300-48T ever produced has 48 GigabitEthernet interfaces. These will never change. So, when creating a device type to represent an EX4300-48T, we add 48 appropriately named interfaces to it. There should never be a reason to add or remove these from individual devices, because they are fixed components. Variable components, on the other hand, may or may not be present on a given device instance. For example, you might have one EX4300-48T with a 4x10GE interface module installed, and one without. Logical interfaces likewise are obviously variable components. NetBox allows you to add these to devices in bulk to specific devices as appropriate without needing to modify the base device type definition. To summarize, _fixed_ components should be defined on the device type, and _variable_ components should not. Thus, the only reason to modify a device type is to correct an error, and retroactive reconfiguration of devices based on a change to the parent device type should be unnecessary. Granted, there may be cases where you want to deploy certain complex configurations of devices: for example, a chassis-based switch with many different interfaces in a certain configuration. This use case will be served by deployment templates (#1364) which is planned for implementation in a future release.

adam commented

2025-12-29 18:20:49 +01:00

@nward commented on GitHub (Jun 17, 2019):

I think this is largely a learning issue. As people are learning netbox, they tend to model only network interfaces. Over time either as new functionality is added to netbox, or as they decide to model more things, they update the device types.

A very common thing in netbox instances I look at is people not modelling power and console ports, then adding this later, and having a huge battle to do it.

This is ultimately a result of poor device modelling up front - however - I think a way to update devices from device types to match newly added bits would really ease the burden on people who've done this poorly.

@jeremystretch - I mentioned implementing this in an external script, so that it's a very intentional administrative function to execute. I have had a look, but I don't see any sort of "directory" of external scripts. Perhaps we could make one for this type of thing, and can put in the blurb for each why it is not netbox core functionality. If I opened a documentation PR for this, would you be supportive of that? Should it go on some sort of 3rd party community site?

@nward commented on GitHub (Jun 17, 2019): I think this is largely a learning issue. As people are learning netbox, they tend to model only network interfaces. Over time either as new functionality is added to netbox, or as they decide to model more things, they update the device types. A very common thing in netbox instances I look at is people not modelling power and console ports, then adding this later, and having a huge battle to do it. This is ultimately a result of poor device modelling up front - however - I think a way to update devices from device types to match newly added bits would really ease the burden on people who've done this poorly. @jeremystretch - I mentioned implementing this in an external script, so that it's a very intentional administrative function to execute. I have had a look, but I don't see any sort of "directory" of external scripts. Perhaps we could make one for this type of thing, and can put in the blurb for each why it is not netbox core functionality. If I opened a documentation PR for this, would you be supportive of that? Should it go on some sort of 3rd party community site?

adam commented

2025-12-29 18:20:49 +01:00

@chicks-net commented on GitHub (Jun 17, 2019):

@nward maybe this would fit under https://github.com/netbox-community

@chicks-net commented on GitHub (Jun 17, 2019): @nward maybe this would fit under https://github.com/netbox-community

adam commented

2025-12-29 18:20:49 +01:00

@nward commented on GitHub (Jun 17, 2019):

Yep - that would be the right place for it !

@nward commented on GitHub (Jun 17, 2019): Yep - that would be the right place for it !

adam commented

2025-12-29 18:20:49 +01:00

@lampwins commented on GitHub (Jun 18, 2019):

A very common thing in netbox instances I look at is people not modelling power and console ports, then adding this later, and having a huge battle to do it.

Maybe I am missing something here, but how is this not entirely solved by the long existing functionality to bulk add/edit device components (to existing devices)? This is quite honestly a drastically simpler UX than any sort of workflow we could come up with as proposed here.

I simply add this comment to ensure others know this has long been an option, and that said this issue is still closed.

@lampwins commented on GitHub (Jun 18, 2019): > A very common thing in netbox instances I look at is people not modelling power and console ports, then adding this later, and having a huge battle to do it. Maybe I am missing something here, but how is this not entirely solved by the long existing functionality to bulk add/edit device components (to existing devices)? This is quite honestly a drastically simpler UX than any sort of workflow we could come up with as proposed here. I simply add this comment to ensure others know this has long been an option, and that said this issue is still closed.

adam commented

2025-12-29 18:20:49 +01:00

@nward commented on GitHub (Jun 18, 2019):

I wasn't aware of that functionality - if that works as you describe then that sounds like a great solution. A report (custom per org, of course) for device types not matching devices would be useful, too, and quite trivial to implement. Perhaps reports should have a workflow to select devices for bulk edit - i.e. select all failed devices, then move to a bulk edit on them.

@nward commented on GitHub (Jun 18, 2019): I wasn't aware of that functionality - if that works as you describe then that sounds like a great solution. A report (custom per org, of course) for device types not matching devices would be useful, too, and quite trivial to implement. Perhaps reports should have a workflow to select devices for bulk edit - i.e. select all failed devices, then move to a bulk edit on them.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#2646