Add device field to indicate airflow #3115

@walday commented on GitHub (Jan 21, 2020):

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.

@walday commented on GitHub (Jan 21, 2020): 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.

adam commented

@ryanmerolle commented on GitHub (Feb 24, 2020):

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.

@ryanmerolle commented on GitHub (Feb 24, 2020): 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.

adam commented

@tiagoasousa commented on GitHub (Jun 9, 2020):

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)

@tiagoasousa commented on GitHub (Jun 9, 2020): 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)

adam commented

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

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?

@jeremystretch commented on GitHub (Jul 24, 2020): 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?

adam commented

@tb-killa commented on GitHub (Aug 6, 2020):

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.

@tb-killa commented on GitHub (Aug 6, 2020): > * 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.

adam commented

@ryanmerolle commented on GitHub (Aug 9, 2020):

You mean this? https://github.com/netbox-community/netbox/issues/3839

On Thu, Aug 6, 2020 at 5:35 AM Oliver notifications@github.com 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
https://github.com/netbox-community/netbox/issues/3839#issuecomment-669822530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACEXYY2CVVFU4PK7T3BAJMTR7J2NDANCNFSM4KCSG2AA
.

@ryanmerolle commented on GitHub (Aug 9, 2020): You mean this? https://github.com/netbox-community/netbox/issues/3839 On Thu, Aug 6, 2020 at 5:35 AM Oliver <notifications@github.com> 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 > <https://github.com/netbox-community/netbox/issues/3839#issuecomment-669822530>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACEXYY2CVVFU4PK7T3BAJMTR7J2NDANCNFSM4KCSG2AA> > . >

adam commented

@jeremystretch commented on GitHub (Sep 1, 2020):

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.

@jeremystretch commented on GitHub (Sep 1, 2020): 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.

adam commented

@BarbarossaTM commented on GitHub (Oct 15, 2020):

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.

@BarbarossaTM commented on GitHub (Oct 15, 2020): 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.

adam commented

@hchybz commented on GitHub (Nov 3, 2020):

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

@hchybz commented on GitHub (Nov 3, 2020): Working on HPC clusters .. where all cables are in front ... thus network switches have non-standard airflow (and racked at front) Need that field !

adam commented

@991jo commented on GitHub (Nov 3, 2020):

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.

@991jo commented on GitHub (Nov 3, 2020): `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.

adam commented

@bellwood commented on GitHub (Aug 6, 2021):

I suppose if we're going to model all the various directions, could we add Passive or None for devices that have no fans or defined airflow pattern?

Just as an aside, "front" and "back" are somewhat ambiguous terms, Cisco nomenclature is, typically, Port Side Intake or Port Side Exhaust.

@bellwood commented on GitHub (Aug 6, 2021): I suppose if we're going to model all the various directions, could we add `Passive` or `None` for devices that have no fans or defined airflow pattern? Just as an aside, "front" and "back" are somewhat ambiguous terms, Cisco nomenclature is, typically, Port Side Intake or Port Side Exhaust.

adam commented

@tb-killa commented on GitHub (Aug 10, 2021):

If this Part is implemented we should rework the "Device Templates" also to introduce this field informations :)

@tb-killa commented on GitHub (Aug 10, 2021): If this Part is implemented we should rework the "Device Templates" also to introduce this field informations :)

adam commented

@jeremystretch commented on GitHub (Oct 12, 2021):

Rather than trying to capture all potential combinations of inlet and exhaust, maybe it would be sufficient to just denote the exhaust. For example:

Front
Rear
Left
Right
None (passive)

@ryanmerolle what are your thoughts?

@jeremystretch commented on GitHub (Oct 12, 2021): Rather than trying to capture all potential combinations of inlet and exhaust, maybe it would be sufficient to just denote the exhaust. For example: * Front * Rear * Left * Right * None (passive) @ryanmerolle what are your thoughts?

adam commented

@BarbarossaTM commented on GitHub (Oct 12, 2021):

Depending on the architecture of the DC both inlet and exhaust might be relevant. If you have cold-aisle containment you may need to fiddle around with some metal/tape to make cold air flow to the side of a device or care about inlet, if you have hot-aisle containment it's the other way around. I think it would be best to to have te

front -> back
back -> front
left -> right
right -> left
side -> back
..

options, so everyone can make use of them. This will come at the cost of adding options later on as we probably might miss some esoteric ones on the 1st shot :-)

@BarbarossaTM commented on GitHub (Oct 12, 2021): Depending on the architecture of the DC both inlet and exhaust might be relevant. If you have cold-aisle containment you may need to fiddle around with some metal/tape to make cold air flow to the side of a device or care about inlet, if you have hot-aisle containment it's the other way around. I think it would be best to to have te - front -> back - back -> front - left -> right - right -> left - side -> back - .. options, so everyone can make use of them. This will come at the cost of adding options later on as we probably might miss some esoteric ones on the 1st shot :-)

adam commented

@zombah commented on GitHub (Oct 13, 2021):

There are device's which mix multiple airflow directions in one box, f.e. Juniper MX480 which have left to right for card slots and front to back for power modules.

@zombah commented on GitHub (Oct 13, 2021): There are device's which mix multiple airflow directions in one box, f.e. Juniper MX480 which have left to right for card slots and front to back for power modules.

adam commented

@991jo commented on GitHub (Oct 13, 2021):

maybe we don't need an airflow direction but intake and exhaust sides of the device? (there can possibly be multiple of those)
the example from @zombah would then have an intake on the left and front and exhausts in the right and back.

@991jo commented on GitHub (Oct 13, 2021): maybe we don't need an airflow direction but intake and exhaust sides of the device? (there can possibly be multiple of those) the example from @zombah would then have an intake on the left and front and exhausts in the right and back.

adam commented

@jeremystretch commented on GitHub (Oct 14, 2021):

In the interest of moving forward with this, I'm going to commit to adding an optional ChoiceField named airflow to both the DeviceType and Device models, with the following options:

front-to-rear
rear-to-front
left-ro-right
right-to-left
side-to-rear
passive

If defined on a DeviceType, this value will be automatically replicated to instantiated Devices, however the user will be able to modify it independently. (This may be needed e.g. when swapping AFI/AFO power supplies and fans within the device.)

This approach seems like it will cover all the concerns raised here. There will be an opportunity to collect feedback during the v3.1 beta period as well.

@jeremystretch commented on GitHub (Oct 14, 2021): In the interest of moving forward with this, I'm going to commit to adding an optional ChoiceField named `airflow` to both the DeviceType and Device models, with the following options: * `front-to-rear` * `rear-to-front` * `left-ro-right` * `right-to-left` * `side-to-rear` * `passive` If defined on a DeviceType, this value will be automatically replicated to instantiated Devices, however the user will be able to modify it independently. (This may be needed e.g. when swapping AFI/AFO power supplies and fans within the device.) This approach seems like it will cover all the concerns raised here. There will be an opportunity to collect feedback during the v3.1 beta period as well.

adam commented