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

Increased power topology size computation and attribution of loads #6362

New Issue
Closed
opened 2025-12-29 19:39:49 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:39:49 +01:00
Owner
Copy Link

Originally created by @ESIC-DA on GitHub (Apr 15, 2022).

NetBox version

v3.2.1

Feature type

Change to existing functionality

Proposed functionality

Increase the available power topology height from the example tree height of:

panel -> feed -> PDU -> Device

Which I believe is more generically described as

panel -> feed -> device -> device

To something like:

panel -> feed -> UPS -> pdu -> breakers -> pdu-outlet-bank -> Server

Which I think really just means increasing the number of devices looked at at the end of the power topology as it is now from 2 devices to... 5ish? Someone may have a usecase for more, but 5 would fully handle all our usecases

which to state my example more generically would be:

panel -> feed -> UPS -> device -> device -> device -> device

It's also unclear to me from testing if modules are considered device for the purposes of this traversal, but if they're not, then that would be great too

Use case

This would allow netbox to support a wider variety of use cases where power is concerned. Ours is in-rack UPSes combined with metered and multi-breakered PDUs, but I'm certain others exist.

So far, at the very least, the issue is that the power used is not propagated beyond the first device (i.e. PDU) above the end device (i.e. server) unless that non leaf device is attached to a feed...so far as I can tell. I would hope that the rack-usage would be summed and attributed to the highest level device in the tree that exists within the rack, to support the case that a UPS could be mounted elsewhere (such as the next rack over from the equipment rack) but, I'm not specifically requesting this at this time, it's just a usecase other people may be interested in (example: all equipment in rack 1, UPS for rack 1 is a UPS rack called rack 2, or something to that effect).

If this feature request is rejected, I'd at least propose that the limitations of the existing system be noted in the documentation, as I wasnt certain it was a known issue until engaging with the netbox slack community.

Database changes

I do not believe this would require any changes to how the data is stored, just to how it is evaluated when computing loads in the tree. The only change I could think that might exist would be in the config, if you wanted to make it specifically settable (i.e. you could set the max evaluated depth to N to ensure possible CPU usage spent computing topologies is bounded)

External dependencies

So far as I'm aware, no new external dependencies.

Thanks,
-Dave

Originally created by @ESIC-DA on GitHub (Apr 15, 2022). ### NetBox version v3.2.1 ### Feature type Change to existing functionality ### Proposed functionality Increase the available power topology height from the example tree height of: panel -> feed -> PDU -> Device Which I believe is more generically described as panel -> feed -> device -> device To something like: panel -> feed -> UPS -> pdu -> breakers -> pdu-outlet-bank -> Server Which I think really just means increasing the number of devices looked at at the end of the power topology as it is now from 2 devices to... 5ish? Someone may have a usecase for more, but 5 would fully handle all our usecases which to state my example more generically would be: panel -> feed -> UPS -> device -> device -> device -> device It's also unclear to me from testing if modules are considered device for the purposes of this traversal, but if they're not, then that would be great too ### Use case This would allow netbox to support a wider variety of use cases where power is concerned. Ours is in-rack UPSes combined with metered and multi-breakered PDUs, but I'm certain others exist. So far, at the very least, the issue is that the power used is not propagated beyond the first device (i.e. PDU) above the end device (i.e. server) unless that non leaf device is attached to a feed...so far as I can tell. I would hope that the rack-usage would be summed and attributed to the highest level device in the tree that exists within the rack, to support the case that a UPS could be mounted elsewhere (such as the next rack over from the equipment rack) but, I'm not _specifically_ requesting this at this time, it's just a usecase other people may be interested in (example: all equipment in rack 1, UPS for rack 1 is a UPS rack called rack 2, or something to that effect). If this feature request is rejected, I'd at least propose that the limitations of the existing system be noted in the documentation, as I wasnt certain it was a known issue until engaging with the netbox slack community. ### Database changes I do not believe this would require any changes to how the data is stored, just to how it is evaluated when computing loads in the tree. The only change I could think that might exist would be in the config, if you wanted to make it specifically settable (i.e. you could set the max evaluated depth to N to ensure possible CPU usage spent computing topologies is bounded) ### External dependencies So far as I'm aware, no new external dependencies. Thanks, -Dave
adam added the type: featurepending closure labels 2025-12-29 19:39:49 +01:00
adam closed this issue 2025-12-29 19:39:50 +01:00
adam commented 2025-12-29 19:39:50 +01:00
Author
Owner
Copy Link

@ESIC-DA commented on GitHub (Apr 15, 2022):

If i need to clarify or expand on anything, please let me know, and thanks for considering this feature request!

Thanks,
-Dave

@ESIC-DA commented on GitHub (Apr 15, 2022): If i need to clarify or expand on anything, please let me know, and thanks for considering this feature request! Thanks, -Dave
adam commented 2025-12-29 19:39:51 +01:00
Author
Owner
Copy Link

@czarnian commented on GitHub (Apr 22, 2022):

I believe this is a ressurection of https://github.com/netbox-community/netbox/issues/3377
There were some code changes since then, so I wonder if the problem is still too complicated to address. It would be very nice to see a working power calculation.

@czarnian commented on GitHub (Apr 22, 2022): I believe this is a ressurection of https://github.com/netbox-community/netbox/issues/3377 There were some code changes since then, so I wonder if the problem is still too complicated to address. It would be very nice to see a working power calculation.
adam commented 2025-12-29 19:39:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 22, 2022):

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 (Jun 22, 2022): 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 19:39:51 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 22, 2022):

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.

@github-actions[bot] commented on GitHub (Jul 22, 2022): 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.
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 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#6362
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?