Should airflow be part of the new RackTypes?

[arthanson]

As part of NetBox 4.1 we are introducing the concept of RackTypes and also introduced the airflow into Racks in (see #11969). Currently airflow is part of RackType, but the question came up should it be part of RackType, or just a field on Racks. The argument is that Airflow is not typically dictated by the rack type.

Currently the airflow on Racks and RackTypes allow choosing "front to back" and "back to front".

[candlerb]

Note that Airflow is also an attribute on Device, and Netbox allows you to change it independently of the Device Type. So I think it would be consistent for Rack to behave the same way.

[jeremystretch]

This is a good point, however there's an important distinction to consider: The airflow direction of a device type can be dictated inherently: We can say "This PacketThrower 9000 draws air from the front and exhausts it to the rear" and that will always be true.

However, a make and model of rack generally has no distinction AFAIK. The direction of airflow through a rack is not inherent to its design, but its placement e.g. between hot and cold aisles in a datacenter.

[ZPrimed]

My preference, as someone who models lots of similar or identical things, would be to allow the Template object (RackType) to define every feasible value of the final object.

If I'm setting a value on the ThingType, I generally expect that value to be copied into all Thing objects. As long as it's possible to override at the Thing (Rack) level, is there any harm?

[jeremystretch]

would be to allow the Template object (RackType) to define every feasible value of the final object.

The RackType and DeviceType models are intentionally not templates for this purpose. Rather, they define a unique make & model of physical product, including all its physical attributes. They purposely stop short of prescribing any specific configuration.