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

Disallow creating power loops/cycles #3082

New Issue
Closed
opened 2025-12-29 18:25:28 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:25:28 +01:00
Owner
Copy Link

Originally created by @andrewcleveland on GitHub (Dec 22, 2019).

Environment

  • Python version: 3.7.5
  • NetBox version: 2.6.7

Proposed Functionality

It is currently possible to connect multiple devices in a way that creates a loop in the power flow. For example:

Device A power outlet <-> Device B power port
Device B power outlet <-> Device C power port
Device C power outlet <-> Device A power port

Disallowing creating a loop like this would accomplish the following:

  • Prevent user error- a physical device layout as above with power connected in a loop would be nonfunctional (effectively the same as plugging a PDU into itself), so a user would never intentionally create such a layout in Netbox.
  • Ease implementation of #3377 - calculating power utilization accurately with multiple chained downstream devices.

This could be implemented by adding a verification step when creating a cable between a power port and power outlet.
It would start at the power outlet to be connected and follow all upstream paths (power outlet -> device -> power port -> power outlet -> ...), verifying that the power port to be connected is not present in any of them.

Use Case

A user who inadvertently attempts to connect a power port and power outlet such that the connection would create a power loop would be prevented from doing so.

Database Changes

None.

External Dependencies

None.

Originally created by @andrewcleveland on GitHub (Dec 22, 2019). <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7.5 * NetBox version: 2.6.7 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality It is currently possible to connect multiple devices in a way that creates a loop in the power flow. For example: Device A power outlet <-> Device B power port Device B power outlet <-> Device C power port Device C power outlet <-> Device A power port Disallowing creating a loop like this would accomplish the following: * Prevent user error- a physical device layout as above with power connected in a loop would be nonfunctional (effectively the same as plugging a PDU into itself), so a user would never intentionally create such a layout in Netbox. * Ease implementation of #3377 - calculating power utilization accurately with multiple chained downstream devices. This could be implemented by adding a verification step when creating a cable between a power port and power outlet. It would start at the power outlet to be connected and follow all upstream paths (power outlet -> device -> power port -> power outlet -> ...), verifying that the power port to be connected is not present in any of them. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case A user who inadvertently attempts to connect a power port and power outlet such that the connection would create a power loop would be prevented from doing so. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None.
adam added the status: under review label 2025-12-29 18:25:28 +01:00
adam closed this issue 2025-12-29 18:25:28 +01:00
adam commented 2025-12-29 18:25:29 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 5, 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 (Jan 5, 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).
adam commented 2025-12-29 18:25:29 +01:00
Author
Owner
Copy Link

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

This seems to be needed in order to provide a viable solution for #3377
@jeremystretch what is your opinion on this?

@phurrelmann commented on GitHub (Jan 6, 2020): This seems to be needed in order to provide a viable solution for #3377 @jeremystretch what is your opinion on this?
adam commented 2025-12-29 18:25:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 6, 2020):

Please don't ping me simply because an issue has been marked as stale. The absence of discussion on a topic indicates that it is not currently a priority.

@jeremystretch commented on GitHub (Jan 6, 2020): Please don't ping me simply because an issue has been marked as stale. The absence of discussion on a topic indicates that it is not currently a priority.
adam commented 2025-12-29 18:25:29 +01:00
Author
Owner
Copy Link

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

I know I'm the one that initially suggested this, but I'm now opposed to the idea of preventing loops. Instead, I'm gonna work on the solution already proposed by @andrewcleveland and limit the iteration, like up to 8 (if there's a loop, the query will only recurse 8 times). Not sure about the number, but I figure 8 is fine.

Reason why I'm opposed (from #3897)

Please note that this is not necessarily something we'd want to do; I'm not the expert on power so I don't know if loops inherently exist out there. I created this PR as a potential solution to the ticket, but apart from #3377, it makes no difference if a loop is preset (AFAIK), so it might be worth to continue allowing power loops and just figure out a different way to solve #3377. To be honest, I'd like to keep power loops in case someone needs them.

@hSaria commented on GitHub (Jan 12, 2020): I know I'm the one that initially suggested this, but I'm now opposed to the idea of preventing loops. Instead, I'm gonna work on the solution already proposed by @andrewcleveland and limit the iteration, like up to 8 (if there's a loop, the query will only recurse 8 times). Not sure about the number, but I figure 8 is fine. Reason why I'm opposed (from #3897) > Please note that this is not necessarily something we'd want to do; I'm not the expert on power so I don't know if loops inherently exist out there. I created this PR as a potential solution to the ticket, but apart from #3377, it makes no difference if a loop is preset (AFAIK), so it might be worth to continue allowing power loops and just figure out a different way to solve #3377. To be honest, I'd like to keep power loops in case someone needs them.
adam commented 2025-12-29 18:25:30 +01:00
Author
Owner
Copy Link

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

Due to the solution to #3377 (#3916), this is not necessary anymore and you can continue creating loops to your heart's content.

@hSaria commented on GitHub (Jan 15, 2020): Due to the solution to #3377 (#3916), this is not necessary anymore and you can continue creating loops to your heart's content.
adam commented 2025-12-29 18:25:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 23, 2020):

I don't have a strong opinion on this either way. One of NetBox's core tenets is to closely model the physical world, and technically it may be possible e.g. to plug a PDU into itself. It's just pointless. I'd wager that there's more valuable in disabling the creation of loops than there is in allowing it, but we must also consider the cost of implementing and maintaining the logic to check for loops.

@jeremystretch commented on GitHub (Jan 23, 2020): I don't have a strong opinion on this either way. One of NetBox's core tenets is to closely model the physical world, and _technically_ it may be possible e.g. to plug a PDU into itself. It's just pointless. I'd wager that there's more valuable in disabling the creation of loops than there is in allowing it, but we must also consider the cost of implementing and maintaining the logic to check for loops.
adam commented 2025-12-29 18:25:30 +01:00
Author
Owner
Copy Link

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

In addition to the performance concerns, I can imagine a power topology where two power-sources backup-feed into each other for redundancy (no idea if it's actually out there in the real world, but it's a possibility). Plus, I can't think of a good way of breaking up any existing loops during a migration.

This issue was opened because of the original (recursive query) solution that was prune to infinite loops and I suggested that we addresses power loops first. Not only was the possible infinite loop fixed in the recursive query, but we decided to go with an ORM-based solution (also avoids loops).

Quite positive this isn't needed anymore.

@hSaria commented on GitHub (Jan 25, 2020): In addition to the performance concerns, I can _imagine_ a power topology where two power-sources backup-feed into each other for redundancy (no idea if it's actually out there in the real world, but it's a possibility). Plus, I can't think of a good way of breaking up any existing loops during a migration. This issue was opened because of the original (recursive query) solution that was prune to infinite loops and I [suggested](https://github.com/netbox-community/netbox/issues/3377#issuecomment-566031988) that we addresses power loops first. Not only was the possible infinite loop fixed in the recursive query, but we decided to go with an ORM-based solution (also avoids loops). Quite positive this isn't needed anymore.
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 status: under review
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#3082
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?