Power utilization not calculated over cascaded devices/PDU #2765

Closed
opened 2025-12-29 18:21:51 +01:00 by adam · 34 comments
Owner

Originally created by @resource-not-found-blank on GitHub (Jul 30, 2019).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.6.1

Steps to Reproduce

  1. create power panel
  2. create power feed
  3. create 3 devices (example: 'pdu_1level', 'pdu_2level', 'device')
  4. connect 'pdu_1level' to created feed (over power port)
  5. connect 'pdu_2level' to 'pdu_1level' (over power port + power outlet)
  6. connect 'device' to 'pdu_2level'
  7. set 'Allocated draw' for 'device' (example: 300)

Expected Behavior

In 'pdu_2level' view 'Power Utilization -> Allocated' - 300;
In 'pdu_1level' view 'Power Utilization -> Allocated' - 300;
In power feed view 'Utilization (Allocated)' - 300.

Observed Behavior

In 'pdu_2level' view 'Power Utilization -> Allocated' - 300;
In 'pdu_1level' view 'Power Utilization -> Allocated' - 0;
In power feed view 'Utilization (Allocated)' - 0.

Originally created by @resource-not-found-blank on GitHub (Jul 30, 2019). # Environment * Python version: 3.6.8 * NetBox version: 2.6.1 ### Steps to Reproduce 1. create power panel 2. create power feed 3. create 3 devices (example: 'pdu_1level', 'pdu_2level', 'device') 4. connect 'pdu_1level' to created feed (over power port) 5. connect 'pdu_2level' to 'pdu_1level' (over power port + power outlet) 6. connect 'device' to 'pdu_2level' 7. set 'Allocated draw' for 'device' (example: 300) ### Expected Behavior In 'pdu_2level' view 'Power Utilization -> Allocated' - 300; In 'pdu_1level' view 'Power Utilization -> Allocated' - 300; In power feed view 'Utilization (Allocated)' - 300. ### Observed Behavior In 'pdu_2level' view 'Power Utilization -> Allocated' - 300; In 'pdu_1level' view 'Power Utilization -> Allocated' - **0**; In power feed view 'Utilization (Allocated)' - **0**.
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 18:21:51 +01:00
adam closed this issue 2025-12-29 18:21:51 +01:00
Author
Owner

@larsuhartmann commented on GitHub (Sep 16, 2019):

Same behaviour on our Side - It would be nice to have this Feature - it is not uncommon to add PDUs to USVs and USVs to Power Feeds especially in smaller Edge Cabinets..

@larsuhartmann commented on GitHub (Sep 16, 2019): Same behaviour on our Side - It would be nice to have this Feature - it is not uncommon to add PDUs to USVs and USVs to Power Feeds especially in smaller Edge Cabinets..
Author
Owner

@roblarose commented on GitHub (Oct 3, 2019):

Agreed. In a "server room" (versus a large datacenter?) we often see multiple PDUs on a single UPS (backed by a single circuit/feed), so at least 3 hops for most equipment.

Feed -> UPS -> PDU -> Device

@roblarose commented on GitHub (Oct 3, 2019): Agreed. In a "server room" (versus a large datacenter?) we often see multiple PDUs on a single UPS (backed by a single circuit/feed), so at least 3 hops for most equipment. Feed -> UPS -> PDU -> Device
Author
Owner

@jeremystretch commented on GitHub (Oct 17, 2019):

Issues like this illustrate why participation in beta releases is so important. Modifying the current approach to support recursive calculations efficiently would require a substantial amount of work. Do we have any volunteers?

@jeremystretch commented on GitHub (Oct 17, 2019): Issues like this illustrate why participation in beta releases is so important. Modifying the current approach to support recursive calculations efficiently would require a substantial amount of work. Do we have any volunteers?
Author
Owner

@larsuhartmann commented on GitHub (Oct 19, 2019):

We could switch our Netbox instance to a beta branch to test it out - no problem!

@larsuhartmann commented on GitHub (Oct 19, 2019): We could switch our Netbox instance to a beta branch to test it out - no problem!
Author
Owner

@jeremystretch commented on GitHub (Oct 21, 2019):

@larsuhartmann not beta testing, actually committing to doing the work.

@jeremystretch commented on GitHub (Oct 21, 2019): @larsuhartmann not beta testing, actually committing to doing the work.
Author
Owner

@andrewcleveland commented on GitHub (Nov 25, 2019):

@jeremystretch Is a recursive SQL query the right way to go about this?
nested_power_draw_legs.patch.txt
Just a proof of concept (individual legs only).

@andrewcleveland commented on GitHub (Nov 25, 2019): @jeremystretch Is a recursive SQL query the right way to go about this? [nested_power_draw_legs.patch.txt](https://github.com/netbox-community/netbox/files/3884733/nested_power_draw_legs.patch.txt) Just a proof of concept (individual legs only).
Author
Owner

@stale[bot] commented on GitHub (Dec 9, 2019):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Dec 9, 2019): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@chas0rde commented on GitHub (Dec 10, 2019):

This definetly is also an issue for us. Sadly we do not have internal coding-capabilities we could supply but we would be happy if anyone could support this think

@chas0rde commented on GitHub (Dec 10, 2019): This definetly is also an issue for us. Sadly we do not have internal coding-capabilities we could supply but we would be happy if anyone could support this think
Author
Owner

@hSaria commented on GitHub (Dec 16, 2019):

Using a recursive query in the database seems like the best approach; as far as I can tell, performing the recursion outside of it would entail O(n) as opposed to O(1) in it.

The work that @andrewcleveland has done looks good, but NetBox is currently prone to loops with that query because the current power model allows for loops, be it direct (power port connected back to a power outlet on the same device) or indirect (looped over multiple devices).

It might be worth addressing the power loop first as it could very well fix this issue in the process. I'm not sure how a recursive model (or multiple) can be handled by Django as most solutions out there are handled at the database.

@hSaria commented on GitHub (Dec 16, 2019): Using a recursive query in the database seems like the best approach; as far as I can tell, performing the recursion outside of it would entail O(n) as opposed to O(1) in it. The work that @andrewcleveland has done looks good, but NetBox is currently prone to loops with that query because the current power model allows for loops, be it direct (power port connected back to a power outlet on the same device) or indirect (looped over multiple devices). It might be worth addressing the power loop first as it could very well fix this issue in the process. I'm not sure how a recursive model (or multiple) can be handled by Django as most [solutions](https://haughtcodeworks.com/blog/software-development/recursive-sql-queries-using-ctes/) out there are handled at the database.
Author
Owner

@stale[bot] commented on GitHub (Dec 30, 2019):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Dec 30, 2019): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@phurrelmann commented on GitHub (Dec 30, 2019):

@jeremystretch could you please check if the proposed solution (see @andrewcleveland and #3782) is accetable? I'd really like to have this fixed. We have several cascaded PDUs in our racks and thus currently can't montor the power usage.

@phurrelmann commented on GitHub (Dec 30, 2019): @jeremystretch could you please check if the proposed solution (see @andrewcleveland and #3782) is accetable? I'd really like to have this fixed. We have several cascaded PDUs in our racks and thus currently can't montor the power usage.
Author
Owner

@hSaria commented on GitHub (Jan 12, 2020):

I'll take care of creating the PR for this. I was initially wanting to prevent power loops, but I'm more than fine with keeping them (see #3782 for more info).

Instead, I'll limit the recursive query to a number of iterations (maybe 16) and use UNION instead of UNION ALL (former doesn't include duplicates). If there is a loop, it'll cause the query to hit the iteration limit, but will still return valid and non-inflated/non-duplicate results.

No preference on the number, but I figure it's unreal for someone to chain 16 power sources

I'll make sure to put enough tests to detect any regression in this as it involves a raw query.

@hSaria commented on GitHub (Jan 12, 2020): I'll take care of creating the PR for this. I was initially wanting to prevent power loops, but I'm more than fine with keeping them (see #3782 for more info). Instead, I'll limit the recursive query to a number of iterations (maybe 16) and use `UNION` instead of `UNION ALL` (former doesn't include duplicates). If there is a loop, it'll cause the query to hit the iteration limit, but will still return valid and non-inflated/non-duplicate results. > No preference on the number, but I figure it's unreal for someone to chain 16 power sources I'll make sure to put enough tests to detect any regression in this as it involves a raw query.
Author
Owner

@roblarose commented on GitHub (Jan 13, 2020):

My hero!

--Rob

--

Rob LaRose

engineer | rock paper scissors https://rockpaperscissors.com/ 245 5th
ave 23rd floor new york ny 10016 | O 212 255 6446

On Sun, Jan 12, 2020 at 3:34 PM hSaria notifications@github.com wrote:

I'll take care of creating the PR for this. I was initially wanting to
prevent power loops, but I'm more than fine with keeping them (see #3782
https://github.com/netbox-community/netbox/issues/3782 for more info).

Instead, I'll limit the recursive query to a number of iterations (maybe
16) and use UNION instead of UNION ALL (former doesn't include
duplicates). If there is a loop, it'll cause the query to hit the iteration
limit, but will still return valid and non-inflated/non-duplicate results.

I'll make sure to put enough tests to detect any regression in this as it
involves a raw query.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFE3SFPJDIYZMEAVJEGDQ5N5EPA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXDQPA#issuecomment-573454396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFSTFE4I3FH2X4BO7HA54BTQ5N5EPANCNFSM4IIAORBQ
.

@roblarose commented on GitHub (Jan 13, 2020): My hero! --Rob *--* *Rob LaRose* *engineer | rock paper scissors <https://rockpaperscissors.com/> 245 5th ave 23rd floor new york ny 10016 | O 212 255 6446* On Sun, Jan 12, 2020 at 3:34 PM hSaria <notifications@github.com> wrote: > I'll take care of creating the PR for this. I was initially wanting to > prevent power loops, but I'm more than fine with keeping them (see #3782 > <https://github.com/netbox-community/netbox/issues/3782> for more info). > > Instead, I'll limit the recursive query to a number of iterations (maybe > 16) and use UNION instead of UNION ALL (former doesn't include > duplicates). If there is a loop, it'll cause the query to hit the iteration > limit, but will still return valid and non-inflated/non-duplicate results. > > I'll make sure to put enough tests to detect any regression in this as it > involves a raw query. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFE3SFPJDIYZMEAVJEGDQ5N5EPA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXDQPA#issuecomment-573454396>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFSTFE4I3FH2X4BO7HA54BTQ5N5EPANCNFSM4IIAORBQ> > . >
Author
Owner

@hSaria commented on GitHub (Jan 14, 2020):

@andrewcleveland Thanks a lot for your query; I modified it to remove looped entries, but apart from that, it pretty much worked from the get go.

Just need to add tests for this and then I'll fire up a PR.

@hSaria commented on GitHub (Jan 14, 2020): @andrewcleveland Thanks a lot for your query; I modified it to remove looped entries, but apart from that, it pretty much worked from the get go. Just need to add tests for this and then I'll fire up a PR.
Author
Owner

@phurrelmann commented on GitHub (Jan 14, 2020):

@hSaria, thank you. I'm eager to test this :)

@phurrelmann commented on GitHub (Jan 14, 2020): @hSaria, thank you. I'm eager to test this :)
Author
Owner

@roblarose commented on GitHub (Jan 14, 2020):

Me too!

--Rob

--

Rob LaRose

engineer | rock paper scissors https://rockpaperscissors.com/ 245 5th
ave 23rd floor new york ny 10016 | O 212 255 6446

On Tue, Jan 14, 2020 at 8:17 AM Patrick Hurrelmann notifications@github.com
wrote:

@hSaria https://github.com/hSaria, thank you. I'm eager to test this :)


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFE5DXW6K6OXXOVALUCDQ5W3PPA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4R5DA#issuecomment-574168716,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFSTFE2FHQCFHJF3I6FBJYDQ5W3PPANCNFSM4IIAORBQ
.

@roblarose commented on GitHub (Jan 14, 2020): Me too! --Rob *--* *Rob LaRose* *engineer | rock paper scissors <https://rockpaperscissors.com/> 245 5th ave 23rd floor new york ny 10016 | O 212 255 6446* On Tue, Jan 14, 2020 at 8:17 AM Patrick Hurrelmann <notifications@github.com> wrote: > @hSaria <https://github.com/hSaria>, thank you. I'm eager to test this :) > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFE5DXW6K6OXXOVALUCDQ5W3PPA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4R5DA#issuecomment-574168716>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFSTFE2FHQCFHJF3I6FBJYDQ5W3PPANCNFSM4IIAORBQ> > . >
Author
Owner

@Blackraz0r commented on GitHub (Jan 21, 2020):

Can someone help me with this?
my calculation also dows not work.

Is created a panel wich goes into a feed wich goes into a device called "UPS" wich goes into a device called "PDU" wich goes to other devices.

example:
Panel->Feed->(PowerPort of UPS - Power Outlet of UPS) ->
(PowerPort of PDU - Power Outlet of PDU) -> Switch

the allocated draw of the switch is not in the utilization of the pdu. and also not further down the chain.

fells like the power of the outlets are not calculated into the ultilization

can someone eli5 me how to do power in netbox? Have the strange feeling i am missing something here. since english is not my main language i also dont really understand what allocated and maximum draw means. the manual is kinda limited on this.
Like allocated on the pdu is the power the pdu itself neets for running its software (metered with webinterface) and the like ?

@Blackraz0r commented on GitHub (Jan 21, 2020): Can someone help me with this? my calculation also dows not work. Is created a panel wich goes into a feed wich goes into a device called "UPS" wich goes into a device called "PDU" wich goes to other devices. example: Panel->Feed->(PowerPort of UPS - Power Outlet of UPS) -> (PowerPort of PDU - Power Outlet of PDU) -> Switch the allocated draw of the switch is not in the utilization of the pdu. and also not further down the chain. fells like the power of the outlets are not calculated into the ultilization can someone eli5 me how to do power in netbox? Have the strange feeling i am missing something here. since english is not my main language i also dont really understand what allocated and maximum draw means. the manual is kinda limited on this. Like allocated on the pdu is the power the pdu itself neets for running its software (metered with webinterface) and the like ?
Author
Owner

@stale[bot] commented on GitHub (Feb 4, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Feb 4, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@roblarose commented on GitHub (Feb 4, 2020):

Looks like jeremystretch already intercepted this but yeah please don't let this go stale/wontfix. I'm eagerly awaiting!

@roblarose commented on GitHub (Feb 4, 2020): Looks like jeremystretch already intercepted this but yeah please don't let this go stale/wontfix. I'm eagerly awaiting!
Author
Owner

@phurrelmann commented on GitHub (Feb 4, 2020):

thank you Jeremy for accepting this one. I'm just spinning up a new vm to test this, as I could not do it yet in our testing-environment

@phurrelmann commented on GitHub (Feb 4, 2020): thank you Jeremy for accepting this one. I'm just spinning up a new vm to test this, as I could not do it yet in our testing-environment
Author
Owner

@phurrelmann commented on GitHub (Feb 4, 2020):

I just tested this in a new test setup and it is working great. Cascaded PDU get correctly summed and it now possible to handle the use cases described in this ticket. Thank you very much for your PR @hSaria and @jeremystretch for your tremendous work on this project and the patience with us users.

@phurrelmann commented on GitHub (Feb 4, 2020): I just tested this in a new test setup and it is working great. Cascaded PDU get correctly summed and it now possible to handle the use cases described in this ticket. Thank you very much for your PR @hSaria and @jeremystretch for your tremendous work on this project and the patience with us users.
Author
Owner

@roblarose commented on GitHub (Feb 4, 2020):

Is this feature included in the recent 2.7.4 release? Or still outside the releases?

--Rob

--
Rob LaRose
engineer | rock paper scissors
245 5th ave 23rd floor new york ny 10016 | O 212 255 6446

On Feb 4, 2020, at 5:51 PM, Patrick Hurrelmann notifications@github.com wrote:


I just tested this in a new test setup and it is working great. Cascaded PDU get correctly summed and it now possible to handle the use cases described in this ticket. Thank you very much for your PR @hSaria and @jeremystretch for your tremendous work on this project and the patience with us users.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@roblarose commented on GitHub (Feb 4, 2020): Is this feature included in the recent 2.7.4 release? Or still outside the releases? --Rob -- Rob LaRose engineer | rock paper scissors 245 5th ave 23rd floor new york ny 10016 | O 212 255 6446 > On Feb 4, 2020, at 5:51 PM, Patrick Hurrelmann <notifications@github.com> wrote: > >  > I just tested this in a new test setup and it is working great. Cascaded PDU get correctly summed and it now possible to handle the use cases described in this ticket. Thank you very much for your PR @hSaria and @jeremystretch for your tremendous work on this project and the patience with us users. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.
Author
Owner

@jeremystretch commented on GitHub (Feb 5, 2020):

@roblarose No, it hasn't been implemented yet. I believe @phurrelmann means that he tried out the pull request submitted by @hSaria above.

@jeremystretch commented on GitHub (Feb 5, 2020): @roblarose No, it hasn't been implemented yet. I believe @phurrelmann means that he tried out the pull request submitted by @hSaria above.
Author
Owner

@roblarose commented on GitHub (Feb 5, 2020):

Roger that. Thank you. :-)

--Rob

--

Rob LaRose

engineer | rock paper scissors https://rockpaperscissors.com/ 245 5th
ave 23rd floor new york ny 10016 | O 212 255 6446

On Tue, Feb 4, 2020 at 6:10 PM Jeremy Stretch notifications@github.com
wrote:

@roblarose https://github.com/roblarose No, it hasn't been implemented
yet. I believe @phurrelmann https://github.com/phurrelmann means that
he tried out the pull request submitted by @hSaria
https://github.com/hSaria above.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFEYLSLYQ4OCLGYTRJJDRBHYWVA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKZRDIY#issuecomment-582160803,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFSTFE6UEKP2T3H32D5RYBTRBHYWVANCNFSM4IIAORBQ
.

@roblarose commented on GitHub (Feb 5, 2020): Roger that. Thank you. :-) --Rob *--* *Rob LaRose* *engineer | rock paper scissors <https://rockpaperscissors.com/> 245 5th ave 23rd floor new york ny 10016 | O 212 255 6446* On Tue, Feb 4, 2020 at 6:10 PM Jeremy Stretch <notifications@github.com> wrote: > @roblarose <https://github.com/roblarose> No, it hasn't been implemented > yet. I believe @phurrelmann <https://github.com/phurrelmann> means that > he tried out the pull request submitted by @hSaria > <https://github.com/hSaria> above. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/netbox-community/netbox/issues/3377?email_source=notifications&email_token=AFSTFEYLSLYQ4OCLGYTRJJDRBHYWVA5CNFSM4IIAORB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKZRDIY#issuecomment-582160803>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AFSTFE6UEKP2T3H32D5RYBTRBHYWVANCNFSM4IIAORBQ> > . >
Author
Owner

@RHuehne commented on GitHub (Jul 6, 2020):

is this topic still being focused by the developers or won't this be fixed?
Thank you.

@RHuehne commented on GitHub (Jul 6, 2020): is this topic still being focused by the developers or won't this be fixed? Thank you.
Author
Owner

@stale[bot] commented on GitHub (Sep 29, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Sep 29, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@MarcHagen commented on GitHub (Sep 29, 2020):

Please do not close this. still needing this function

@MarcHagen commented on GitHub (Sep 29, 2020): Please do not close this. still needing this function
Author
Owner

@larsuhartmann commented on GitHub (Sep 29, 2020):

Same here! It would be really nice to have this!

@larsuhartmann commented on GitHub (Sep 29, 2020): Same here! It would be really nice to have this!
Author
Owner

@jeremystretch commented on GitHub (Sep 29, 2020):

This has been tagged "needs owner" for several months. If no one is interested in committing to the work, it will be closed. @MarcHagen @larsuhartmann are either of you volunteering to own the implementation?

@jeremystretch commented on GitHub (Sep 29, 2020): This has been tagged "needs owner" for several months. If no one is interested in committing to the work, it will be closed. @MarcHagen @larsuhartmann are either of you volunteering to own the implementation?
Author
Owner

@hSaria commented on GitHub (Sep 29, 2020):

Hey Jeremy,

I think the issue here is that we don’t have an acceptable solution without changing the existing behavior in power modelling. As you and I discussed in previous PRs, raw SQL is difficult to maintain and calculating a topology tree and storing it as a field in the model is somewhat complex.

Because loops are currently permitted in power modelling, we can’t use MPTT. Otherwise, that’s one solution that might work. If you got something in mind, I can try to help where I can.

Regards,
Saria

On 29 Sep 2020, at 4:00 pm, Jeremy Stretch notifications@github.com wrote:

This has been tagged "needs owner" for several months. If no one is interested in committing to the work, it will be closed. @MarcHagen @larsuhartmann are either of you volunteering to own the implementation?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@hSaria commented on GitHub (Sep 29, 2020): Hey Jeremy, I think the issue here is that we don’t have an acceptable solution without changing the existing behavior in power modelling. As you and I discussed in previous PRs, raw SQL is difficult to maintain and calculating a topology tree and storing it as a field in the model is somewhat complex. Because loops are currently permitted in power modelling, we can’t use MPTT. Otherwise, that’s one solution that might work. If you got something in mind, I can try to help where I can. Regards, Saria > On 29 Sep 2020, at 4:00 pm, Jeremy Stretch <notifications@github.com> wrote: >  > This has been tagged "needs owner" for several months. If no one is interested in committing to the work, it will be closed. @MarcHagen @larsuhartmann are either of you volunteering to own the implementation? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or unsubscribe.
Author
Owner

@MarcHagen commented on GitHub (Sep 29, 2020):

i would love to help with this, but my Python skills are just not up to the task, and this is a big "task/issue/feature". So sorry :(

@MarcHagen commented on GitHub (Sep 29, 2020): i would love to help with this, but my Python skills are just not up to the task, and this is a big "task/issue/feature". So sorry :(
Author
Owner

@larsuhartmann commented on GitHub (Oct 8, 2020):

Is there any way to "sponsor" someone to implement this feature?
We have the same situation at work: it would be nice to have this feature but none of us have the skills to implement it :-\

@larsuhartmann commented on GitHub (Oct 8, 2020): Is there any way to "sponsor" someone to implement this feature? We have the same situation at work: it would be nice to have this feature but none of us have the skills to implement it :-\
Author
Owner

@stale[bot] commented on GitHub (Oct 24, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Oct 24, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Author
Owner

@Starkstromkonsument commented on GitHub (Jan 2, 2021):

The function required for the calculation seems to be already implemented at

b2e05aafc1/netbox/dcim/models/device_components.py (L327)

It is called by Power Feeds (for Power Utilization)

872ba89cad/netbox/templates/dcim/powerfeed.html (L111)

and Racks (for Power Utilization)

4ce7dfa55e/netbox/templates/dcim/rack.html (L249)

There is another call for devices ("Power Utilization" panel)

872ba89cad/netbox/templates/dcim/device.html (L221)

Edit 1: I'm trying to understand the code of the current power calculation and noticed that the above "Power Utilization" panel of a device page is never shown, although they have both power ports and power outlets defined. A fixed issue (#5184) about this already exists, but it does not seem to work (anymore?). Am I misunderstanding something here or should I file a new issue about this?

I opt for reopening #3782 to prevent power loops (I can't see a valuable use case. Electrical power circuits should always be protected by corresponding fuses/switchgears. Building loops or interconnecting different circuits ends up in a mess and can get very dangerous in case of a fault. This is what devices with multiple PSUs are built for.) and use the existing function get_power_draw recursively for power ports connected to power outlets.

But I regret, I don't have sufficient python skills so far to do so either :-(

Edit 2: I apologize, I misunderstood the current point of this discussion. I did not read the two PRs related to this issue first of writing my comment. The last posts of this issue gave me the impression, that most of the work to fix this still has to be done. But wow, PR #4226 already contains a piece of very hard work!

It seems like this issue is currently stuck mainly because of loop and performance concerns. How can one help to solve these?

@Starkstromkonsument commented on GitHub (Jan 2, 2021): The function required for the calculation seems to be already implemented at https://github.com/netbox-community/netbox/blob/b2e05aafc1a99d14fea2ab9c446a8dd7b4cd6375/netbox/dcim/models/device_components.py#L327 It is called by Power Feeds (for Power Utilization) https://github.com/netbox-community/netbox/blob/872ba89cad976bca84fab1cbc9360ee63e4039eb/netbox/templates/dcim/powerfeed.html#L111 and Racks (for Power Utilization) https://github.com/netbox-community/netbox/blob/4ce7dfa55edc0ddc1229c22ad837bcb959c4ec60/netbox/templates/dcim/rack.html#L249 There is another call for devices ("Power Utilization" panel) https://github.com/netbox-community/netbox/blob/872ba89cad976bca84fab1cbc9360ee63e4039eb/netbox/templates/dcim/device.html#L221 _Edit 1: I'm trying to understand the code of the current power calculation and noticed that the above "Power Utilization" panel of a device page is never shown, although they have both power ports and power outlets defined. A fixed issue (#5184) about this already exists, but it does not seem to work (anymore?). Am I misunderstanding something here or should I file a new issue about this?_ I opt for reopening #3782 to prevent power loops (I can't see a valuable use case. Electrical power circuits should always be protected by corresponding fuses/switchgears. Building loops or interconnecting different circuits ends up in a mess and can get very dangerous in case of a fault. This is what devices with multiple PSUs are built for.) and use the existing function `get_power_draw` recursively for power ports connected to power outlets. But I regret, I don't have sufficient python skills so far to do so either :-( _Edit 2: I apologize, I misunderstood the current point of this discussion. I did not read the two PRs related to this issue first of writing my comment. The last posts of this issue gave me the impression, that most of the work to fix this still has to be done. But wow, PR #4226 already contains a piece of very hard work!_ _It seems like this issue is currently stuck mainly because of loop and performance concerns. How can one help to solve these?_
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2765