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

Airflow attribute for PSU and fan modules #7755

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

Originally created by @jbemmel on GitHub (Mar 13, 2023).

Originally assigned to: @arthanson on GitHub.

NetBox version

latest

Feature type

Data model extension

Proposed functionality

The schema at https://github.com/netbox-community/devicetype-library/blob/master/schema/moduletype.json currently does not allow 'airflow' attributes.

Assuming that is in line with what's currently in Netbox, I'd like to propose adding 'airflow' support for modules and racks

In typical systems, fan and psu modules have a specific airflow direction. It is not a property of the base system - it depends on the modules being used. Moreover, data centers are designed with a specific airflow in mind - this 'design intent' should be captured and used to reduce provisioning errors, by disallowing combinations of devices with incompatible airflow in the same rack (and similar for modules in the same device)

Use case

Supporting 'airflow' at the module and rack level allows for proper modeling of the system. The rack level 'airflow' would allow users to specify a filter for the devices and modules to be installed in that rack

Database changes

Adds 'airflow' field per module/rack (as a mixin, like weight), plus logic to validate that all modules added support the same airflow direction, and filtering of module_types presented given a device in a rack with specified airflow

External dependencies

none

Originally created by @jbemmel on GitHub (Mar 13, 2023). Originally assigned to: @arthanson on GitHub. ### NetBox version latest ### Feature type Data model extension ### Proposed functionality The schema at https://github.com/netbox-community/devicetype-library/blob/master/schema/moduletype.json currently does not allow 'airflow' attributes. Assuming that is in line with what's currently in Netbox, I'd like to propose adding 'airflow' support for modules and racks In typical systems, fan and psu modules have a specific airflow direction. It is not a property of the base system - it depends on the modules being used. Moreover, data centers are designed with a specific airflow in mind - this 'design intent' should be captured and used to reduce provisioning errors, by disallowing combinations of devices with incompatible airflow in the same rack (and similar for modules in the same device) ### Use case Supporting 'airflow' at the module and rack level allows for proper modeling of the system. The rack level 'airflow' would allow users to specify a filter for the devices and modules to be installed in that rack ### Database changes Adds 'airflow' field per module/rack (as a mixin, like weight), plus logic to validate that all modules added support the same airflow direction, and filtering of module_types presented given a device in a rack with specified airflow ### External dependencies none
adam added the status: acceptedtype: featurecomplexity: medium labels 2025-12-29 20:27:50 +01:00
adam closed this issue 2025-12-29 20:27:50 +01:00
adam commented 2025-12-29 20:27:50 +01:00
Author
Owner
Copy Link

@danner26 commented on GitHub (Mar 13, 2023):

I absolutely agree, we do need to add airflow as a property to modules as well

@danner26 commented on GitHub (Mar 13, 2023): I absolutely agree, we do need to add `airflow` as a property to modules as well
adam commented 2025-12-29 20:27:50 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Mar 17, 2023):

Maybe a check also ? that if the device is has a certain airflow, that the modules have to have the same ?
Not sure if that is always a good idea...

@PieterL75 commented on GitHub (Mar 17, 2023): Maybe a check also ? that if the device is has a certain airflow, that the modules have to have the same ? Not sure if that is always a good idea...
adam commented 2025-12-29 20:27:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2023):

How would these values map to the options for device airflow?

@jeremystretch commented on GitHub (Jul 26, 2023): How would these values map to the options for device airflow?
adam commented 2025-12-29 20:27:51 +01:00
Author
Owner
Copy Link

@danner26 commented on GitHub (Jul 27, 2023):

As a rough idea, we could have an airflow attribute on devices called something like airflow: module-regulated which then on the NetBox backend is determined by the installed modules which have the airflow attribute to specify the direction

Working with the devicetype-library I have noticed a lot of switches chassis' will have a sku for no PSU/FANs, and then depending on which PSU is installed that determins the direction of the airflow

@danner26 commented on GitHub (Jul 27, 2023): As a rough idea, we could have an airflow attribute on devices called something like `airflow: module-regulated` which then on the NetBox backend is determined by the installed modules which have the airflow attribute to specify the direction Working with the devicetype-library I have noticed a lot of switches chassis' will have a sku for no PSU/FANs, and then depending on which PSU is installed that determins the direction of the airflow
adam commented 2025-12-29 20:27:51 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Jul 23, 2024):

@jeremystretch Would this then have the same airflow choices as Device (below), and if-so, if Mixed would the filter allow all device airflow in, also for devices without airflow defined, would they be allowed to be in the rack if airflow was set on the rack? Would the logic be that airflow for rack / device has to match unless it is Mixed or Passive?

    CHOICES = (
        (AIRFLOW_FRONT_TO_REAR, _('Front to rear')),
        (AIRFLOW_REAR_TO_FRONT, _('Rear to front')),
        (AIRFLOW_LEFT_TO_RIGHT, _('Left to right')),
        (AIRFLOW_RIGHT_TO_LEFT, _('Right to left')),
        (AIRFLOW_SIDE_TO_REAR, _('Side to rear')),
        (AIRFLOW_PASSIVE, _('Passive')),
        (AIRFLOW_MIXED, _('Mixed')),
    )
@arthanson commented on GitHub (Jul 23, 2024): @jeremystretch Would this then have the same airflow choices as Device (below), and if-so, if Mixed would the filter allow all device airflow in, also for devices without airflow defined, would they be allowed to be in the rack if airflow was set on the rack? Would the logic be that airflow for rack / device has to match unless it is Mixed or Passive? ``` CHOICES = ( (AIRFLOW_FRONT_TO_REAR, _('Front to rear')), (AIRFLOW_REAR_TO_FRONT, _('Rear to front')), (AIRFLOW_LEFT_TO_RIGHT, _('Left to right')), (AIRFLOW_RIGHT_TO_LEFT, _('Right to left')), (AIRFLOW_SIDE_TO_REAR, _('Side to rear')), (AIRFLOW_PASSIVE, _('Passive')), (AIRFLOW_MIXED, _('Mixed')), ) ```
adam commented 2025-12-29 20:27:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 24, 2024):

I think we'd omit "mixed" as a choice for individual modules. (It's never made sense to me personally.) The other options should all be retained.

@jeremystretch commented on GitHub (Jul 24, 2024): I think we'd omit "mixed" as a choice for individual modules. (It's never made sense to me personally.) The other options should all be retained.
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 complexity: medium status: accepted 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#7755
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?