Cisco Modular Power Supplies and Fans

[michaelklose]

Discussed in https://github.com/netbox-community/devicetype-library/discussions/1172

^{Originally posted by **michaelklose** March 4, 2023} I have seen the last community call on Youtube right now and the short discussion about modular power supplies and fans. Most device types are currently modeled with fixed fans/power supplies as most of them were created before module types were supported. In the past I already extracted most uplink modules from Cisco devices to modules. If there is interest to do this in the same way for fans and power supplies I would open an issue for that and starting to work on it for at least all Cisco devices.

This issue is for tracking the modularization of all existing Cisco device types in regards to power supplies and fans.

[michaelklose]

@danner26 I have done a proof of concept implementation for Catalyst 9300. You can find it here Please let me know what you think before I go on with further devices. I do see really good benefits for power supplies as they have different power ports but I'm unsure about module bays for fans as they have no components. Another question came up how I could do multi-line comments? It works with two trailing spaces but they are filtered out by pre-commit.

[danner26]

Looks good to me so far! What do you mean by "I'm unsure about module bays for fans as they have no components"?

Multi line comments can be done like in this file or this file

[jbemmel]

Airflow is a consideration for Cisco fan/power modules too, see https://github.com/netbox-community/netbox/issues/11969

e.g. for Catalyst 9300 https://www.enterasource.com/cisco-c3kx-pwr-1100wac-ac-power-supply-3k-x-1100w

"Fan Info | Front to Back Airflow"

[danner26]

@jbemmel airflow is definitely something I think we should add to modules as well, especially if they change the way devices airflow is handled. The FR is a good start but we are going to need to figure out the best way to A) model this change and B) alter the device based upon the module installed

[jbemmel]

@danner26 I'm thinking we could create an AirflowMixin similar to the WeightMixin (https://github.com/netbox-community/netbox/blob/develop/netbox/dcim/models/mixins.py)

I'm not sure if there would be a need to "alter the device" - for devices that have a module bay, their 'airflow' attribute could act as a constraint to filter the list of modules available for insertion

[danner26]

I think that is probably the way to go in regards to adding a mixin for airflow

Correct me if I am wrong, but I seem to recall working on a set of device definitions recently whose airflow pattern depended entirely upon the PSU (module) installed. I.E. if the device has a front-to-rear PSU, then the devices airflow was front-to-rear, but if you swapped that out and put a rear-to-front PSU then the airflow for the device swapped as well.

This leads me to believe that the devices airflow definition in NetBox would need to be altered based upon the modules defined airflow. Thoughts?

[jbemmel]

Airflow is part of the data center design decisions to be made; all components in a rack should have the same direction. I think it would make most sense if users could specify the airflow direction they want at the rack instance level, and then use it as a filter to disallow devices and/or modules that have an incompatible airflow specified.

The definition of "incompatible" would need to be tweaked though - rear-to-front and front-to-rear are incompatible, but side-to-rear and front-to-rear may not be, and "passive" can be combined with any other. Could also opt to require users to specify "mixed" if they want to allow such combinations in the same rack

[michaelklose]

Having airflow on modules will definitely makes sense.

Looks good to me so far! What do you mean by "I'm unsure about module bays for fans as they have no components"?

Multi line comments can be done like in this file or this file

---
manufacturer: Cisco
model: FAN-T2
part_number: FAN-T2
comments: Type 2 Fan Module / [Cisco Catalyst 9300 Series Switches Data Sheet](https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/nb-06-cat9300-ser-data-sheet-cte-en.html)

So with the current model having a FAN module doesn't bring a lot of benefits and it might make more sense to use an inventory for tracking FANs. But I fully agree it makes a lot of sense if we could define airflow on a module.

[michaelklose]

Airflow is part of the data center design decisions to be made; all components in a rack should have the same direction. I think it would make most sense if users could specify the airflow direction they want at the rack instance level, and then use it as a filter to disallow devices and/or modules that have an incompatible airflow specified.

The definition of "incompatible" would need to be tweaked though - rear-to-front and front-to-rear are incompatible, but side-to-rear and front-to-rear may not be, and "passive" can be combined with any other. Could also opt to require users to specify "mixed" if they want to allow such combinations in the same rack

But on a rack instance level it should be optional. Maybe not all devices support front-to-rear or rear-to-front airflow but you want to operate it in the same rack. But it would be nice to have a compatible/incompatible state on device level if there is a mismatch between device/module or module/module.

[jbemmel]

Yes, also for backwards compatibility airflow would have to be optional. But if it is specified, things must be compatible (either an alert flag, or disallowing the provisioning)

I came across this issue when contributing some devices and modules for Nokia SR Linux. For only 5 devices I needed to add 28 modules - 14 times 2 airflow directions - so imagine what you'd get if we convert the Cisco portfolio. We need a filtering mechanism, else users won't be able to select the correct module(s)

On that note: Module bays should also list the module types they support. For example, PSUs are designed for certain devices - a Nokia 7220 IXR D2L needs a D2L/D3L PSU module

[michaelklose]

I also came across this topic. As more module types we support we need an option to define which modules are allowed in a module-bay

[a084ed22]

But it would be nice to have a compatible/incompatible state on device level if there is a mismatch between device/module or module/module.

isn't this more fitting as a report?

[danner26]

But it would be nice to have a compatible/incompatible state on device level if there is a mismatch between device/module or module/module.

isn't this more fitting as a report?

I agree, this is a great thing to have but it is moreso report material imo

I agree filtering is beneficial, and in fact all of this is dependent on the upstream netbox repository. Since there is a PR related to module airflow, I can work on that when I get some time but unfortunately it will have to wait until we get that merged.. This is all really good conversation though!

[mayafox]

@danner26 I finally got a moment to return to this w/ respect to the Extreme Networks devices I was looking to add. I reached a similar conclusion that specifying fixed states (IE AC or DC fans, and either front to back or back to front airflow) for the devices was not the correct way to approach this, so I closed my pull request for the time being. I was also wondering if it would be possible to add the weight and airflow to the module type schema as optional data to more correctly model the fans, power supply, but it appears @michaelklose had a similar thought.

I do agree some sort of way to reference the module-types to the appropriate device-type is possibly needed so users don't put a incorrect or incompatible gear together, but still allow for the re-use of the defined module-types across various device-types.

This would follow the SKU's Extreme ships (pizza box w/o fans or PSU, and seperate line item for fans, seperate line item for PSU with matching airflow) based on their tech specs. For example:

device-types/Extreme Networks/9920-NPB-8.yaml

---
manufacturer: Extreme Networks
model: 9920-NPB-8
slug: 9920-npb-8
part_number: 9920-NPB-8
u_height: 4
is_full_depth: true
comments: "[Extreme 9920 Data Sheet](https://www.extremenetworks.com/product/extreme-9920/)"
weight: 33.0
weight-type: kg
module-bays:
  - name: FAN1
    position: 1
    description: Fan tray 1
    valid_modules:
      - 9920-FAN-F
  - name: PSU1
    position: 1
    description: Power module bay 1
    valid_modules:
      - 9920-ACPWR-1600W-F
      - 9920-DCPWR-1600W-F

module-types/Extreme\ Networks/9920-DCPOWER-1600W-F.yaml

---
manufacturer: Extreme Networks
model: 9920-DCPWR-1600W-F
part_number: 9920-DCPWR-1600W-F
comments: '[Extreme 9920 Data Sheet](https://www.extremenetworks.com/product/extreme-9920/)'
power-ports:
  - name: PSU{module}
    type: dc-terminal
    maximum_draw: 1600
    airflow: front-to-rear
    weight: 1.0
    weight-type: kg

module-types/Extreme\ Networks/9920-FAN-F.yaml

---
manufacturer: Extreme Networks
model: 9920-FAN-F
part_number: 9920-FAN-F
comments: '[Extreme 9920 Data Sheet](https://www.extremenetworks.com/product/extreme-9920/)'
airflow: front-to-rear
weight: 2.5
weight-type: kg