mirror of
https://github.com/netbox-community/netbox.git
synced 2026-01-11 21:10:29 +01:00
Track available power per rack #31
Closed
opened 2025-12-29 15:30:03 +01:00 by adam
·
14 comments
No Branch/Tag Specified
main
update-changelog-comments-docs
feature-removal-issue-type
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
v4.5.0
v4.4.10
v4.4.9
v4.5.0-beta1
v4.4.8
v4.4.7
v4.4.6
v4.4.5
v4.4.4
v4.4.3
v4.4.2
v4.4.1
v4.4.0
v4.3.7
v4.4.0-beta1
v4.3.6
v4.3.5
v4.3.4
v4.3.3
v4.3.2
v4.3.1
v4.3.0
v4.2.9
v4.3.0-beta2
v4.2.8
v4.3.0-beta1
v4.2.7
v4.2.6
v4.2.5
v4.2.4
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.11
v4.1.10
v4.1.9
v4.1.8
v4.2-beta1
v4.1.7
v4.1.6
v4.1.5
v4.1.4
v4.1.3
v4.1.2
v4.1.1
v4.1.0
v4.0.11
v4.0.10
v4.0.9
v4.1-beta1
v4.0.8
v4.0.7
v4.0.6
v4.0.5
v4.0.3
v4.0.2
v4.0.1
v4.0.0
v3.7.8
v3.7.7
v4.0-beta2
v3.7.6
v3.7.5
v4.0-beta1
v3.7.4
v3.7.3
v3.7.2
v3.7.1
v3.7.0
v3.6.9
v3.6.8
v3.6.7
v3.7-beta1
v3.6.6
v3.6.5
v3.6.4
v3.6.3
v3.6.2
v3.6.1
v3.6.0
v3.5.9
v3.6-beta2
v3.5.8
v3.6-beta1
v3.5.7
v3.5.6
v3.5.5
v3.5.4
v3.5.3
v3.5.2
v3.5.1
v3.5.0
v3.4.10
v3.4.9
v3.5-beta2
v3.4.8
v3.5-beta1
v3.4.7
v3.4.6
v3.4.5
v3.4.4
v3.4.3
v3.4.2
v3.4.1
v3.4.0
v3.3.10
v3.3.9
v3.4-beta1
v3.3.8
v3.3.7
v3.3.6
v3.3.5
v3.3.4
v3.3.3
v3.3.2
v3.3.1
v3.3.0
v3.2.9
v3.2.8
v3.3-beta2
v3.2.7
v3.3-beta1
v3.2.6
v3.2.5
v3.2.4
v3.2.3
v3.2.2
v3.2.1
v3.2.0
v3.1.11
v3.1.10
v3.2-beta2
v3.1.9
v3.2-beta1
v3.1.8
v3.1.7
v3.1.6
v3.1.5
v3.1.4
v3.1.3
v3.1.2
v3.1.1
v3.1.0
v3.0.12
v3.0.11
v3.0.10
v3.1-beta1
v3.0.9
v3.0.8
v3.0.7
v3.0.6
v3.0.5
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
v2.11.12
v3.0-beta2
v2.11.11
v2.11.10
v3.0-beta1
v2.11.9
v2.11.8
v2.11.7
v2.11.6
v2.11.5
v2.11.4
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.10
v2.10.9
v2.11-beta1
v2.10.8
v2.10.7
v2.10.6
v2.10.5
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.11
v2.10-beta2
v2.9.10
v2.10-beta1
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.9-beta2
v2.8.9
v2.9-beta1
v2.8.8
v2.8.7
v2.8.6
v2.8.5
v2.8.4
v2.8.3
v2.8.2
v2.8.1
v2.8.0
v2.7.12
v2.7.11
v2.7.10
v2.7.9
v2.7.8
v2.7.7
v2.7.6
v2.7.5
v2.7.4
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.12
v2.6.11
v2.6.10
v2.6.9
v2.7-beta1
Solcon-2020-01-06
v2.6.8
v2.6.7
v2.6.6
v2.6.5
v2.6.4
v2.6.3
v2.6.2
v2.6.1
v2.6.0
v2.5.13
v2.5.12
v2.6-beta1
v2.5.11
v2.5.10
v2.5.9
v2.5.8
v2.5.7
v2.5.6
v2.5.5
v2.5.4
v2.5.3
v2.5.2
v2.5.1
v2.5.0
v2.4.9
v2.5-beta2
v2.4.8
v2.5-beta1
v2.4.7
v2.4.6
v2.4.5
v2.4.4
v2.4.3
v2.4.2
v2.4.1
v2.4.0
v2.3.7
v2.4-beta1
v2.3.6
v2.3.5
v2.3.4
v2.3.3
v2.3.2
v2.3.1
v2.3.0
v2.2.10
v2.3-beta2
v2.2.9
v2.3-beta1
v2.2.8
v2.2.7
v2.2.6
v2.2.5
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.6
v2.2-beta2
v2.1.5
v2.2-beta1
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.1.0
v2.0.10
v2.1-beta1
v2.0.9
v2.0.8
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v2.0-beta3
v1.9.6
v1.9.5
v2.0-beta2
v1.9.4-r1
v1.9.3
v2.0-beta1
v1.9.2
v1.9.1
v1.9.0-r1
v1.8.4
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.7.3
v1.7.2-r1
v1.7.1
v1.7.0
v1.6.3
v1.6.2-r1
v1.6.1-r1
1.6.1
v1.6.0
v1.5.2
v1.5.1
v1.5.0
v1.4.2
v1.4.1
v1.4.0
v1.3.2
v1.3.1
v1.3.0
v1.2.2
v1.2.1
v1.2.0
v1.1.0
v1.0.7-r1
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3-r1
v1.0.3
1.0.0
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
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
Mirrored from GitHub Pull Request
No Label
status: accepted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/netbox#31
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?
Originally created by @Gelob on GitHub (Jun 28, 2016).
Power Connections feels like an afterthought right now. There is no interface to add a PDU with a # of outlets, but you can import this information.
I think there should be a separate Power tab that is tied back to the individual rack. This would help greatly with tracking power circuits per rack (30A phase, etc) and their IDs.
@jeremystretch commented on GitHub (Jun 28, 2016):
PDUs are treated like any other device in NetBox. You can simply create a device type to represent the model of PDU you'd like to install (for example, an APC AP7900). Vertically-mounted PDUs which don't consume rack space should be treated as 0U devices. Then, you can add the appropriate number of outlets to the device type.
NetBox doesn't currently support any mechanism for tracking power circuits outside of a rack. This would be a pretty substantial feature expansion.
@Gelob commented on GitHub (Jun 28, 2016):
Thanks, I see that now PDUs are part of devices. My bad.
I think it could easily be accomplished by having a field on the rack in terms of how much power it has, but it would be nice to track the individual power circuits.
@jeremystretch commented on GitHub (Jun 28, 2016):
I'd love to get more detail around specifically what you'd like to track. We're planning to implement custom fields in the near future, but I think it makes sense to add a dedicated field or two to the Rack model to track power if there's interest. I don't know enough about power to know what it should look like.
@bellwood commented on GitHub (Jun 28, 2016):
Typically when it comes to power you have:
free form field would be fine
2a) phase ID
single phase breakers on a 3 phase capable busway are either A/B/C in terms of the leg they are powered from
free form field would be fine, some prefer 110 over 120 and there are odd voltages out there
breaker ID
possibly breaker PDU/panel ID
we use overhead busway for breakers so our breaker ID's are the rack ID + pdu number in the rack
my junipers hold four PSU's and each is fed from a different UPS/busway/breaker so denoting power "type" would be nice
@Gelob commented on GitHub (Jun 28, 2016):
Bellwood hit a lot of it spot on. What about 2b) bank id? In 3 phase you have 3 banks of outlets tied back to the 2 phases which is tied back to the breakers. Its deep, but it would be nice to have the option to track that my device is plugged into outlet 24 which is tied back to bank 3 which is tied back to phases 1 + 2. It helps with knowing and understanding at a glance where my heavy power usage is per device.
I don't know much about DC power but that should be an option too (AC or DC).
Example Use Case:
I have a row of 3 racks:
Rack 1 has 2x 30A 3phase power circuits and two PDUs installed.
Rack 2 has 4x 30A 3phase power circuits and two PDUs installed.
Rack 3 has 2x 20A single phase power circuits installed and two PDU installed
The power circuits live under raised tile. I want to be able to track that the PDU A in Rack 1 is plugged into a specific 30A circuit. The datacenter has their own labeling scheme that I want to notate for my reference. For Rack 2 I have had the datacenter install 4x circuits, but only two are active at this time. Having tracking would help with capacity planning of unused power or future power if we have available racks but no power yet.
@dinoocch commented on GitHub (Aug 4, 2016):
@jeremystretch Is there monitoring included in this plan? - to monitor and perhaps visualize real power consumption (via snmp) seems like a useful feature to me, although it would introduce a lot more complexity. I understand that Netbox is not designed to be a monitoring platform - however having this data, especially power usage, all in one place makes sense to me...what do you think?
@jeremystretch commented on GitHub (Aug 4, 2016):
@dinoocch Definitely not. Monitoring is firmly out of scope for NetBox. But you can quite feasibly pull data from NetBox to inform a monitoring system.
@puck commented on GitHub (Sep 1, 2016):
Not sure if people are visualising their distribution boards currently, but I have each distribution board as a rack and I've added a "device" which has the appropriate number of outputs for each circuit (both 1P and 3P).
@travisn08 commented on GitHub (Oct 30, 2016):
It would be most helpful if we could see a convenient rack view of the power budget (used/total) kW in a rack. Even if total kW is a static field define per rack and used is an accumulation of watts defined per device [type].
@nicpar commented on GitHub (Aug 21, 2017):
I would also like to see power capacity planning added via the following:
Implement a "circuits" model for power (that the PDUs can plug into). I am reading consensus in tracking upstream details like outlet type and specs. I am looking at this from a colocation customer, but I could see how the colocation provider may need a lot more details. (Maybe support multiple power paths as part of the power circuit model? We could sort power system A and B separately and use below.)
Allow per rack power utilization % similar to physical Us used. This is covered in Issue #524. We should be able to statically set a rack's power capacity or do some calculation off circuits located within. We should work in a notation of watts to determine capacity since it can be normalized despite amp and voltage differences between circuits. We need to consider A+B side (redundant) power path circuits with which we would want to mark one circuit as redundant so calculations are accurate. This needs some more thought behind handling this. See above for suggestion on adding A & B to a power circuit model.
Each device should have a power spec defined. I suggest a field for "max draw" or "design spec". We see the vendors publishing higher maximum draws than real world so a second field for "average" or "expected" draw may also make sense.
@mmahacek commented on GitHub (Mar 23, 2019):
I'm late to this conversation, but tracking power assigned to a rack doesn't make sense to me. Many of our racks have two PDUs attached to different circuits. We would like to track amps/phase/voltage/breaker/etc as above, but at the PDU level, not the rack level.
Am I interpreting this issue correctly?
@jeremystretch commented on GitHub (Mar 23, 2019):
Apparent power will be associated with a new PowerFeed model, instances of which may be assigned to a rack. In a typical datacenter environment you'd have two feeds per rack (primary and redundant), but that's entirely up to the user.
@nicpar commented on GitHub (Mar 23, 2019):
Some high density configurations have multiple redundant circuits. The
last company i worked in we deployed dual A+B circuits per rack (30A each,
for 60A total available to the rack). This is where my initial
description came from, having 4 circuits, two marked as redundant, and two
summed to show available power. Tracking power allocated per device (by
design) against this total would be extremely useful. NetBox is supposed
to be the reference of how things should be, so this is a good baseline to
compare actual power draw against.
On Fri, Mar 22, 2019 at 18:08 Jeremy Stretch notifications@github.com
wrote:
@jeremystretch commented on GitHub (Apr 11, 2019):
The bulk of this work has been completed and merged into
develop-2.6. 🎉