starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow linking of rack power to PDUs or UPSs #7475

New Issue
Closed
opened 2025-12-29 20:23:49 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:23:49 +01:00
Owner
Copy Link

Originally created by @dutchman80 on GitHub (Jan 9, 2023).

NetBox version

v3.4.0

Feature type

Change to existing functionality

Proposed functionality

Within a rack, allow the selection of any devices with "Power Outlets" (like PDUs and UPSs) as the "Power Feeds" for that rack. Selecting a device would supplant the default "Power Feeds" that show up now, when a rack is associated with a power feed in the power feed's definition.

The "Maximum Draw" setting of the power device (and any preceding power devices that it's plugged into) could define the total amount of power that device can feed to the rack.

For example, for power path:

power feed (30A max) -> ups (20A max) -> pdu (15A max)

the rack where the pdu is installed would have a max amperage draw of 15A

Use case

This greatly increases flexibility. Right now, a rack's power consumption is tracked by which power feeds are associated with that rack. This would allow you to instead tie a rack's power consumption to specific PDUs, specific UPSs, etc.

This leads to more accurate power tracking when cross wiring devices (i.e. power feed -> ups -> rack1 pdu & rack2 pdu), and also when a rack's PDU has a lower max amperage than the power feed that it's plugged into.

Database changes

No response

External dependencies

No response

Originally created by @dutchman80 on GitHub (Jan 9, 2023). ### NetBox version v3.4.0 ### Feature type Change to existing functionality ### Proposed functionality Within a rack, allow the selection of any devices with "Power Outlets" (like PDUs and UPSs) as the "Power Feeds" for that rack. Selecting a device would supplant the default "Power Feeds" that show up now, when a rack is associated with a power feed in the power feed's definition. The "Maximum Draw" setting of the power device (and any preceding power devices that it's plugged into) could define the total amount of power that device can feed to the rack. For example, for power path: power feed (30A max) -> ups (20A max) -> pdu (15A max) the rack where the pdu is installed would have a max amperage draw of 15A ### Use case This greatly increases flexibility. Right now, a rack's power consumption is tracked by which power feeds are associated with that rack. This would allow you to instead tie a rack's power consumption to specific PDUs, specific UPSs, etc. This leads to more accurate power tracking when cross wiring devices (i.e. power feed -> ups -> rack1 pdu & rack2 pdu), and also when a rack's PDU has a lower max amperage than the power feed that it's plugged into. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closurestatus: under review labels 2025-12-29 20:23:49 +01:00
adam closed this issue 2025-12-29 20:23:50 +01:00
adam commented 2025-12-29 20:23:50 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 9, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 9, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:23:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 1, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Aug 1, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:23:51 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Aug 5, 2023):

I agree with the concept of shifting the power path modeling from racks to devices as part of a broader goal to properly model the entire DC electrical system (at a practical level). In DC design, racks are not the focus, but devices are.

For each utility source delivered to the DC, it follows through a topology of equipment within a distribution path including UPS, switch board, PDU, RPP (remote power panel), power strips, etc. Racks or cabinets are important for organizing devices, but shouldn't be the unit of power consumption. The modeled electrical system itself, and the power devices included in it, should track consumption.

Below is example of a fault tolerant DC design from the ANSI/BICSI 002-2019 Data Center Design and Implementation Best Practices manual. I would love to help improve NetBox's power and mechanical system modeling to improve the representation of these aspects.

image

@eronlloyd commented on GitHub (Aug 5, 2023): I agree with the concept of shifting the power path modeling from racks to devices as part of a broader goal to properly model the entire DC electrical system (at a practical level). In DC design, racks are not the focus, but devices are. For each utility source delivered to the DC, it follows through a topology of equipment within a distribution path including UPS, switch board, PDU, RPP (remote power panel), power strips, etc. Racks or cabinets are important for organizing devices, but shouldn't be the unit of power consumption. The modeled electrical system itself, and the power devices included in it, should track consumption. Below is example of a fault tolerant DC design from the ANSI/BICSI 002-2019 Data Center Design and Implementation Best Practices manual. I would love to help improve NetBox's power and mechanical system modeling to improve the representation of these aspects. ![image](https://github.com/netbox-community/netbox/assets/197778/55f8466b-73b5-491e-aabf-6cc6a22b5256)
adam commented 2025-12-29 20:23:51 +01:00
Author
Owner
Copy Link

@justin-davisibm commented on GitHub (Sep 7, 2023):

More complete power mapping is sorely needed on the DCIM side - The ability to extend the existing Power Panel concept and link multiple together would be a potential first-step.

@justin-davisibm commented on GitHub (Sep 7, 2023): More complete power mapping is sorely needed on the DCIM side - The ability to extend the existing Power Panel concept and link multiple together would be a potential first-step.
adam commented 2025-12-29 20:23:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 6, 2023):

After being open for nine months, there has unfortunately not been any real discussion or detailing of the changes proposed here. (It would not make sense to treat a device or set of devices as "power feeds.") The FR does not even provide a response under the "database changes" section, so I'm not sure what work anyone was expecting to take place. While it is clear this is an area of interest, there has not been any effort made to propose specific data model or API changes, or any consideration paid to how this would impact the current model. As such, I'm going to close it out.

If anyone would like to submit a new feature request to to propose a specific set of changes, including options for migrating existing power feed associations, you are welcome to do so in a new issue.

@eronlloyd the diagram you shared above represents datacenter facility power design. The scope of NetBox's power model encompasses only the PDUs and critical load portions of that diagram. Anything beyond that is well out of scope for this particular feature request, but similarly you are welcome to submit a new FR to extend the data model northbound if you think it would be appropriate for the application.

@jeremystretch commented on GitHub (Oct 6, 2023): After being open for nine months, there has unfortunately not been any real discussion or detailing of the changes proposed here. (It would not make sense to treat a device or set of devices as "power feeds.") The FR does not even provide a response under the "database changes" section, so I'm not sure what work anyone was expecting to take place. While it is clear this is an area of interest, there has not been any effort made to propose specific data model or API changes, or any consideration paid to how this would impact the current model. As such, I'm going to close it out. If anyone would like to submit a new feature request to to propose a _specific set of changes_, including options for migrating existing power feed associations, you are welcome to do so in a new issue. @eronlloyd the diagram you shared above represents datacenter facility power design. The scope of NetBox's power model encompasses only the PDUs and critical load portions of that diagram. Anything beyond that is well out of scope for this particular feature request, but similarly you are welcome to submit a new FR to extend the data model northbound if you think it would be appropriate for the application.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7475
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?