Cooling Section #5197

New Issue

adam · 2025-12-29T19:25:20+01:00

adam commented

2025-12-29 19:25:20 +01:00

Originally created by @adamboutcher on GitHub (Aug 18, 2021).

NetBox version

v2.11.10

Feature type

New functionality

Proposed functionality

Add a section for cooling. Much like Power connections, water cooled data centres have lots of infrastructure relating to cooling. We require water cooled racks however some people have water cooled servers.

You need a loops similar in high-level function to the current power panel and you need a connection, similar in high-level function to the current power feed.

A rack/device would need an in/out connection but you could combine these into a single database "connection" as long as there was a space to write down notes to flow/return (in/out) details, typically these are a labelled valve, so it would require some freeform text.

For DCs that have water cooled servers, you have cooling into the rack as above but then you distribute this into a server (with a manifold), much like a PDU and so the functionality could be mirrored, although again a free-form text-input for flow/return valve numbering might be required (I've not used a manifold system as I'm unsure to how I'd document it exactly).

Use case

If its a "green" water cooled DC, then it add extra functionality to maintain connections/locations related to cooling, much like the power section, at the moment this has to be manually extended (we rather simply use custom inputs to include the valve numbers into the rack).

Database changes

Unknown

External dependencies

None.

Originally created by @adamboutcher on GitHub (Aug 18, 2021). ### NetBox version v2.11.10 ### Feature type New functionality ### Proposed functionality Add a section for cooling. Much like Power connections, water cooled data centres have lots of infrastructure relating to cooling. We require water cooled racks however some people have water cooled servers. You need a loops similar in high-level function to the current power panel and you need a connection, similar in high-level function to the current power feed. A rack/device would need an in/out connection but you could combine these into a single database "connection" as long as there was a space to write down notes to flow/return (in/out) details, typically these are a labelled valve, so it would require some freeform text. For DCs that have water cooled servers, you have cooling into the rack as above but then you distribute this into a server (with a manifold), much like a PDU and so the functionality could be mirrored, although again a free-form text-input for flow/return valve numbering might be required (I've not used a manifold system as I'm unsure to how I'd document it exactly). ### Use case If its a "green" water cooled DC, then it add extra functionality to maintain connections/locations related to cooling, much like the power section, at the moment this has to be manually extended (we rather simply use custom inputs to include the valve numbers into the rack). ### Database changes Unknown ### External dependencies None.

adam added the type: feature plugin candidate labels 2025-12-29 19:25:20 +01:00

adam closed this issue

2025-12-29 19:25:21 +01:00

adam commented

2025-12-29 19:25:21 +01:00

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

This would essentially be the exact same thing as power.

Perhaps the way to look at this would be modify the existing power models to be "service" models and let the user flag if the panels, feeds and components are either water or power?

@bellwood commented on GitHub (Aug 18, 2021): This would essentially be the exact same thing as power. Perhaps the way to look at this would be modify the existing power models to be "service" models and let the user flag if the panels, feeds and components are either water or power?

adam commented

2025-12-29 19:25:21 +01:00

@adamboutcher commented on GitHub (Aug 18, 2021):

That could work, the major difference to power is there's physically two connections that would need documenting in some way, you always have two connections, never just one or three etc.

The key data to capture is cooling capacity (typically in killawatts) , preassure (psi) connection type, flow/return connection (valve) id and maybe operating temp range on the actual loop.

@adamboutcher commented on GitHub (Aug 18, 2021): That could work, the major difference to power is there's physically two connections that would need documenting in some way, you always have two connections, never just one or three etc. The key data to capture is cooling capacity (typically in killawatts) , preassure (psi) connection type, flow/return connection (valve) id and maybe operating temp range on the actual loop.

adam commented

2025-12-29 19:25:22 +01:00

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

That could work, the major difference to power is there's physically two connections that would need documenting in some way, you always have two connections, never just one or three etc.

This would be just be another feed no?

@bellwood commented on GitHub (Aug 18, 2021): > That could work, the major difference to power is there's physically two connections that would need documenting in some way, you always have two connections, never just one or three etc. This would be just be another feed no?

adam commented

2025-12-29 19:25:22 +01:00

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

The key data to capture is cooling capacity (typically in killawatts) , preassure (psi) connection type, flow/return connection (valve) id and maybe operating temp range on the actual loop.

This would definitely be a modification/expansion of the existing model.

@bellwood commented on GitHub (Aug 18, 2021): > The key data to capture is cooling capacity (typically in killawatts) , preassure (psi) connection type, flow/return connection (valve) id and maybe operating temp range on the actual loop. This would definitely be a modification/expansion of the existing model.

adam commented

2025-12-29 19:25:22 +01:00

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

This sounds like the sort of thing that would be best implemented as a plugin initially. Then, once it's seen some real-world use, we can revisit the idea of adding it to NetBox.

@jeremystretch commented on GitHub (Oct 5, 2021): This sounds like the sort of thing that would be best implemented as a plugin initially. Then, once it's seen some real-world use, we can revisit the idea of adding it to NetBox.

adam commented

2025-12-29 19:25:22 +01:00

@adamboutcher commented on GitHub (Oct 5, 2021):

Thanks! I didn't know plugins were a thing. Will see if I can do it.

@adamboutcher commented on GitHub (Oct 5, 2021): Thanks! I didn't know plugins were a thing. Will see if I can do it.

adam referenced this issue

2025-12-29 22:24:43 +01:00

[PR #5208] [MERGED] 5197: Limit main IPAddress view to a max of 10 duplicate addresses; add new duplicates view #12983

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#5197