Extend Device model with front_image and rear_image fields #10958

New Issue

adam · 2025-12-29T21:38:23+01:00

adam commented

2025-12-29 21:38:23 +01:00

Originally created by @loubladi on GitHub (Mar 28, 2025).

NetBox version

v4.2.6

Feature type

Data model extension

Proposed functionality

Extend the Device model with front_image and rear_image fields, similar to the DeviceType model. These fields should allow overriding the default DeviceType images for an individual Device.

Use case

The primary use case is for modular chassis-based devices. In scenarios where a single DeviceType represents a chassis (e.g., a DWDM chassis), the installed Modules may change over time. Overriding the DeviceType images at the Device level would allow accurate visual representation of the device in rack views, reflecting the current state.

Database changes

Add front_image and rear_image fields to the Device model.
Ensure these fields override the DeviceType images when set.

External dependencies

N/A

Originally created by @loubladi on GitHub (Mar 28, 2025). ### NetBox version v4.2.6 ### Feature type Data model extension ### Proposed functionality Extend the **Device** model with _front_image_ and _rear_image_ fields, similar to the **DeviceType** model. These fields should allow overriding the default **DeviceType** images for an individual **Device**. ### Use case The primary use case is for modular chassis-based devices. In scenarios where a single **DeviceType** represents a chassis (e.g., a DWDM chassis), the installed **Modules** may change over time. Overriding the **DeviceType** images at the **Device** level would allow accurate visual representation of the device in rack views, reflecting the current state. ### Database changes - Add front_image and rear_image fields to the Device model. - Ensure these fields override the DeviceType images when set. ### External dependencies N/A

adam added the type: feature complexity: medium netbox needs milestone status: backlog labels 2025-12-29 21:38:23 +01:00

adam commented

2025-12-29 21:38:24 +01:00

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

While I get the proposed use case, it seems like it would require a ton of work for very little return. Are you intending to manually update & re-upload each image for each device every time a module is installed or removed?

@jeremystretch commented on GitHub (Apr 3, 2025): While I get the proposed use case, it seems like it would require a ton of work for very little return. Are you intending to manually update & re-upload each image for each device every time a module is installed or removed?

adam commented

2025-12-29 21:38:25 +01:00

@loubladi commented on GitHub (Apr 7, 2025):

That was the idea. The intention is to manually update and upload the front and rear images for specific devices when their module layout changes. The module setup doesn’t change frequently, so I believe it’s manageable.

Here’s one particular use case we currently have:

We use devices like the Cisco ASR-9903, which have several modules. The RSP (Route Processor), power supplies, and fan trays are always present, but the line card slot can either be empty or populated with a module such as the A9903-20HG-PEC.

It would be helpful to have the option to distinguish these two hardware states visually by allowing a front image override—one image with the line card and one without. These images would be prepared in advance, and in the rare event that the line card is removed, we would simply reupload the correct image for that specific device.

The behavior would be that the DeviceType defines the default image (e.g., without the line card), while only specific Device instances would have an image override, which would then be used in the rack view.

With the growing adoption of modules and module bays in NetBox, this could offer users a simple way to visually differentiate devices based on their installed modules. For example, many patch panels in the Device Type Library now consist of modular frames where modules with specific front and rear ports are inserted. Also from

There may be better ways in the future to visualize differences in installed modules, but I thought this method would be the simplest to implement compared to more complex automatic options. Ideally, we’d love to have automatic image rendering based on installed modules—a feature found in many DWDM device management systems—but I understand that would be extremely difficult to implement in NetBox. Using image overrides would shift that complexity to the user while still enabling better visual accuracy.

@loubladi commented on GitHub (Apr 7, 2025): That was the idea. The intention is to manually update and upload the front and rear images for specific devices when their module layout changes. The module setup doesn’t change frequently, so I believe it’s manageable. Here’s one particular use case we currently have: We use devices like the [Cisco ASR-9903](https://github.com/netbox-community/devicetype-library/blob/master/device-types/Cisco/ASR-9903.yaml), which have several modules. The RSP (Route Processor), power supplies, and fan trays are always present, but the line card slot can either be empty or populated with a module such as the [A9903-20HG-PEC](https://github.com/netbox-community/devicetype-library/blob/master/module-types/Cisco/A9903-20HG-PEC.yml). It would be helpful to have the option to distinguish these two hardware states visually by allowing a front image override—one image with the line card and one without. These images would be prepared in advance, and in the rare event that the line card is removed, we would simply reupload the correct image for that specific device. The behavior would be that the DeviceType defines the default image (e.g., without the line card), while only specific Device instances would have an image override, which would then be used in the rack view. With the growing adoption of modules and module bays in NetBox, this could offer users a simple way to visually differentiate devices based on their installed modules. For example, many patch panels in the Device Type Library now consist of modular frames where modules with specific front and rear ports are inserted. Also from There may be better ways in the future to visualize differences in installed modules, but I thought this method would be the simplest to implement compared to more complex automatic options. Ideally, we’d love to have automatic image rendering based on installed modules—a feature found in many DWDM device management systems—but I understand that would be extremely difficult to implement in NetBox. Using image overrides would shift that complexity to the user while still enabling better visual accuracy.

adam commented

2025-12-29 21:38:25 +01:00

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

I suspect you'd find very quickly that this approach doesn't work well in the long term, as updating the images for individual devices to reflect their current state is extremely tedious and error-prone. And those images are typically displayed at a size where readily discerning such detail is impractical (if not impossible).

What is gained by attempting to reflect the installed modules in the device's image versus simply viewing the device's page in NetBox?

@jeremystretch commented on GitHub (Apr 7, 2025): I suspect you'd find very quickly that this approach doesn't work well in the long term, as updating the images for individual devices to reflect their current state is extremely tedious and error-prone. And those images are typically displayed at a size where readily discerning such detail is impractical (if not impossible). What is gained by attempting to reflect the installed modules in the device's image versus simply viewing the device's page in NetBox?

adam commented

2025-12-29 21:38:25 +01:00

@loubladi commented on GitHub (Apr 7, 2025):

The main benefit of this feature is the ability to visually see the module configuration of a device. I would expect that the front and rear images would also render on the device detail page (as mentioned in Slack: link).

I agree that this request leans more toward visual enhancement—some might even call it “eye candy”—but I believe it could still be quite valuable for onboarding and documentation, especially for new employees unfamiliar with a particular hardware platform.

Regarding concerns about manual updates being tedious or error-prone: I don’t think that argument should be a blocker. That line of reasoning could also apply to other parts of NetBox where manual user input are key aspects.

If this is considered not worth the development effort within core NetBox, we will explore using the netbox-device-view plugin as an alternative. However, native support would provide a much more streamlined and integrated experience.

@loubladi commented on GitHub (Apr 7, 2025): The main benefit of this feature is the ability to visually see the module configuration of a device. I would expect that the front and rear images would also render on the device detail page (as mentioned in Slack: [link](https://netdev-community.slack.com/archives/C01P0FRSXRV/p1743782613550109?thread_ts=1743756063.208279&cid=C01P0FRSXRV)). I agree that this request leans more toward visual enhancement—some might even call it “eye candy”—but I believe it could still be quite valuable for onboarding and documentation, especially for new employees unfamiliar with a particular hardware platform. Regarding concerns about manual updates being tedious or error-prone: I don’t think that argument should be a blocker. That line of reasoning could also apply to other parts of NetBox where manual user input are key aspects. If this is considered not worth the development effort within core NetBox, we will explore using the [netbox-device-view plugin](https://github.com/peterbaumert/netbox-device-view) as an alternative. However, native support would provide a much more streamlined and integrated experience.

adam commented

2025-12-29 21:38:25 +01:00

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

In my case, I use Visio to create new images of modular equipment. It's not difficult at all. While my gear doesn't change much, it's nice having an image of an empty chassis in the DeviceType and an up to date image for each Device instance.

@Ximalas commented on GitHub (Apr 9, 2025): In my case, I use Visio to create new images of modular equipment. It's not difficult at all. While my gear doesn't change much, it's nice having an image of an empty chassis in the DeviceType and an up to date image for each Device instance.

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

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#10958