Track available power per rack #31

Closed
opened 2025-12-29 15:30:03 +01:00 by adam · 14 comments
Owner

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.

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.
adam added the status: accepted label 2025-12-29 15:30:03 +01:00
adam closed this issue 2025-12-29 15:30:04 +01:00
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@bellwood commented on GitHub (Jun 28, 2016):

Typically when it comes to power you have:

  1. amps (15/20/30/etc)

free form field would be fine

  1. phase (1 or 3)

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

  1. volts (120/208/etc)

free form field would be fine, some prefer 110 over 120 and there are odd voltages out there

  1. breaker ID

  2. 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

  1. A, B, C, etc power

my junipers hold four PSU's and each is fed from a different UPS/busway/breaker so denoting power "type" would be nice

@bellwood commented on GitHub (Jun 28, 2016): Typically when it comes to power you have: 1) amps (15/20/30/etc) free form field would be fine 2) phase (1 or 3) 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 3) volts (120/208/etc) free form field would be fine, some prefer 110 over 120 and there are odd voltages out there 4) breaker ID 5) 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 6) A, B, C, etc power my junipers hold four PSU's and each is fed from a different UPS/busway/breaker so denoting power "type" would be nice
Author
Owner

@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.

@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.
Author
Owner

@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?

@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?
Author
Owner

@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.

@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.
Author
Owner

@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).

@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).
Author
Owner

@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].

@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].
Author
Owner

@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.

@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.
Author
Owner

@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?

@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?
Author
Owner

@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.

@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.
Author
Owner

@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:

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.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/54#issuecomment-475826314,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALsn_4jpHzicwqTRhxCC4bc57EEAdIbgks5vZX56gaJpZM4I_q0V
.

@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: > 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. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/digitalocean/netbox/issues/54#issuecomment-475826314>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ALsn_4jpHzicwqTRhxCC4bc57EEAdIbgks5vZX56gaJpZM4I_q0V> > . >
Author
Owner

@jeremystretch commented on GitHub (Apr 11, 2019):

The bulk of this work has been completed and merged into develop-2.6. 🎉

@jeremystretch commented on GitHub (Apr 11, 2019): The bulk of this work has been completed and merged into `develop-2.6`. :tada:
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#31