Add Fans to Device Component List #3110

New Issue

adam · 2025-12-29T18:25:42+01:00

adam commented

2025-12-29 18:25:42 +01:00

Originally created by @ryanmerolle on GitHub (Jan 2, 2020).

Environment

Python version: 3.6.3
NetBox version: 2.6.9

Proposed Functionality

Add a component type for fans. The data model would include:

Model/Part Number: Required
Serial Number: Optional (only for device and not device type)
Air Flow Direction: Required (default option is front-to-rear with a second choice of rear-to-front) - Could use a boolean in the data model

Use Case

Air Flow is an important DCIM feature that is currently missing. Operators may want to track and eventually audit their DCs to verify airflow direction.

Database Changes

Add a new data model type with the fields mentioned in the proposed functionality.

External Dependencies

None

Originally created by @ryanmerolle on GitHub (Jan 2, 2020). ### Environment * Python version: 3.6.3 * NetBox version: 2.6.9 ### Proposed Functionality Add a component type for fans. The data model would include: - Model/Part Number: Required - Serial Number: Optional (only for device and not device type) - Air Flow Direction: Required (default option is front-to-rear with a second choice of rear-to-front) - Could use a boolean in the data model ### Use Case Air Flow is an important DCIM feature that is currently missing. Operators may want to track and eventually audit their DCs to verify airflow direction. ### Database Changes Add a new data model type with the fields mentioned in the proposed functionality. ### External Dependencies None

adam closed this issue

2025-12-29 18:25:42 +01:00

adam commented

2025-12-29 18:25:42 +01:00

@hSaria commented on GitHub (Jan 2, 2020):

This seems like something already covered by inventory items.

@hSaria commented on GitHub (Jan 2, 2020): This seems like something already covered by inventory items.

adam commented

2025-12-29 18:25:43 +01:00

@tb-killa commented on GitHub (Jan 2, 2020):

This could be combined with the Floorplan issue who actually is already opened.

@tb-killa commented on GitHub (Jan 2, 2020): This could be combined with the Floorplan issue who actually is already opened.

adam commented

2025-12-29 18:25:43 +01:00

@jeremystretch commented on GitHub (Jan 2, 2020):

Air Flow is an important DCIM feature that is currently missing.

NetBox allows users to track airflow direction by DeviceType model number. For instance, Juniper has two part numbers for its QFX5100-48S switch:

QFX5100-48S-AFI (front-to-back airflow)
QFX5100-48S-AFO (back-to-front airflow)

I believe the catalyst for this FR was the realization that the device type definitions for two devices in this scenario are identical, except for the model number suffix. There is a desire for a a mechanism to differentiate airflow without having to create otherwise duplicate device types.

There is no need to introduce a new component model for fans, as the InventoryItem model already provides the ability to distinguish airflow direction by the fan module part number (e.g. QFX5100-FANAFI versus QFX5100-FANAFO).

A related but separate FR (which is what I had anticipated from the discussion) would be the introduction of a new field on the DeviceType model to indicate airflow. This would obviate the need for tracking airflow by model number at all. But again, this would need to be a new FR with a separate discussion.

This seems like something already covered by inventory items.

Just to reiterate, this is correct: fans should be modeled as inventory items..

@jeremystretch commented on GitHub (Jan 2, 2020): > Air Flow is an important DCIM feature that is currently missing. NetBox allows users to track airflow direction by DeviceType model number. For instance, Juniper has two part numbers for its QFX5100-48S switch: * `QFX5100-48S-AFI` (front-to-back airflow) * `QFX5100-48S-AFO` (back-to-front airflow) I believe the catalyst for this FR was the realization that the device type definitions for two devices in this scenario are identical, except for the model number suffix. There is a desire for a a mechanism to differentiate airflow without having to create otherwise duplicate device types. There is no need to introduce a new component model for fans, as the InventoryItem model already provides the ability to distinguish airflow direction by the fan module part number (e.g. `QFX5100-FANAFI` versus `QFX5100-FANAFO`). A related but separate FR (which is what I had anticipated from the discussion) would be the introduction of a new field on the DeviceType model to indicate airflow. This would obviate the need for tracking airflow by model number at all. But again, this would need to be a new FR with a separate discussion. > This seems like something already covered by inventory items. Just to reiterate, this is correct: fans should be modeled as inventory items..

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