Add device field to indicate airflow

[ryanmerolle]

Environment

• Python version: 3.6.3
• NetBox version: 2.6.9

Proposed Functionality

Though we can model airflow / FAN model numbers in the inventory of a device, not everyone is going to do this. It just might be more ideal to signify in an optional field of the device. Additionally, one could also add the type to the deviceType model, for platforms that do not have swappable fans. At the very least, adding it to device model should be enough.

Relates to #3825

Use Case

There is no standard way the industry signifies airflow direction. Some platforms hardcode the airflow in the model number, some dynamically adjust show version model number with a -F or -R, some just indicate the airflow direction in a bundle SKU not seen in the device's OS, and some combine all of the above methods.

Database Changes

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

External Dependencies

N/A

[tb-killa]

After some consideration and the insight in other DCIM tools, this FR should also be extended to the rack model, because ultimately the rack represents the actual airflow in a data center (front to back / back to front). In order to push things to the absolute limit, a default setting should be possible (e.g. Front to Back), but if more than 50% of the devices set up in the rack have an airflow (for eg. Back to Front), this direction is automatically preferred.

As soon as airflow is available on the rack model, the issue: #114 can be edited.

[walday]

I need.. for this field in device and rack model.. in DC happens and the option of air movement in the front-to-side.. and this requiment air organisation tool.

[ryanmerolle]

Rack airflow seems to make sense. @jeremystretch let me know if you need any more feedback or thought on the data model. I think to our earlier conversation on slack, a simple drop down indicator field for the device (and rack if you decide it to be needed) would work just fine. If you apply to both, people could create reports/scripts to check that all devices in a rack are facing the proper way based on the airflow of the device, the front of the device, and the airflow of the rack. Further down the road, fans in the device inventory could be tracked against these feilds.

[tiagoasousa]

Is this something i could contribute in some way? is a field that for where i am would be very usefull because i have rows of front to back (mostly compute rows) and back to front on the same datacenter. A standard way to document this would be very useful even for capacity management (buying the correct gear for the correct place)

[jeremystretch]

This seems like it's still half-baked. There are several details that need to be nailed down before this is actionable:

• What fields are proposed for that models?
• How is the direction of airflow conveyed to the user? I.e. what is the "front" of the device?
• What is the specific validation logic (if any) being proposed, and how are violations reported to the user?

[tb-killa]

• What fields are proposed for that models?
• How is the direction of airflow conveyed to the user? I.e. what is the "front" of the device?
• What is the specific validation logic (if any) being proposed, and how are violations reported to the user?

The Device-Model should be extended with one field called "airflow-direction" who should select two states (front-to-back / back-to-front).

If someone document devices in netbox or physical in one rack he knows about the airflow themselves (hopefully after he bring the device online and feel the flow).

i think validations are somthing wo could be great running via plugin or reporting script, the first stepp should be here to provide an direct way of documentation.

[ryanmerolle]

You mean this? #3839

…

On Thu, Aug 6, 2020 at 5:35 AM Oliver ***@***.***> wrote: - What fields are proposed for that models? - How is the direction of airflow conveyed to the user? I.e. what is the "front" of the device? - What is the specific validation logic (if any) being proposed, and how are violations reported to the user? The Device-Model should be extended with one field called "airflow-direction" who should select two states (front-to-back / back-to-front). If someone document devices in netbox or physical in one rack he knows about the airflow themselves (hopefully after he bring the device online and feel the flow). i think validations are somthing wo could be great running via plugin or reporting script, the first stepp should be here to provide an direct way of documentation. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3839 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEXYY2CVVFU4PK7T3BAJMTR7J2NDANCNFSM4KCSG2AA> .

[jeremystretch]

I'm going to mark this as tentatively accepted (awaiting milestone designation) with the following assumptions:

• A new airflow field will be added to the DeviceType model. This can be front-to-back, back-to-front, or null (default).
• The same field will be also added to the Device model. This will inherit from DeviceType upon instantiation of a new device, but can be modified by the user.

[BarbarossaTM]

Hi,

I would like to propose two values for this option: left-to-right and right-to-left

There are devices like Cisco Catalyst 4900-M which sadly don't to front-to-back or back-to-front but side-to-side, which might require some magic to happen in data centers.

[hchybz]

Working on HPC clusters .. where all cables are in front ... thus network switches have non-standard airflow (and racked at front)
Need that field !

[991jo]

side-to-back is also a airflow direction that I have seen in the field. Usually on access switches. At least some of the (tbh rather old) 3560/3750 G/E models have that.