-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Airflow attribute for PSU and fan modules #11969
Comments
I absolutely agree, we do need to add |
Maybe a check also ? that if the device is has a certain airflow, that the modules have to have the same ? |
How would these values map to the options for device airflow? |
As a rough idea, we could have an airflow attribute on devices called something like 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 |
@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?
|
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. |
* Shorten choice constant names * Add filter tests for airflow
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
The text was updated successfully, but these errors were encountered: