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

Drop port_speed and upstream_speed fields from CircuitTermination #4610

New Issue
Closed
opened 2025-12-29 18:38:14 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:38:14 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 1, 2021).

Proposed Changes

Remove the port_speed and upstream_speed fields from the CircuitTermination model (the first two fields pictured below).

Screenshot_2021-03-01 CenturyLink 1002840283 - Side A - NetBox

Justification

These fields predate NetBox's ability to track individual interfaces, and are largely obsolete. Their naming is also somewhat confusing. I'm curious to see whether anyone is still relying on them.

Originally created by @jeremystretch on GitHub (Mar 1, 2021). ### Proposed Changes Remove the `port_speed` and `upstream_speed` fields from the CircuitTermination model (the first two fields pictured below). ![Screenshot_2021-03-01 CenturyLink 1002840283 - Side A - NetBox](https://user-images.githubusercontent.com/13487278/109567539-81c77800-7ab3-11eb-9313-41a8b3290c16.png) ### Justification These fields predate NetBox's ability to track individual interfaces, and are largely obsolete. Their naming is also somewhat confusing. I'm curious to see whether anyone is still relying on them.
adam added the type: deprecation label 2025-12-29 18:38:14 +01:00
adam closed this issue 2025-12-29 18:38:15 +01:00
adam commented 2025-12-29 18:38:15 +01:00
Author
Owner
Copy Link

@arjenvri commented on GitHub (Mar 2, 2021):

We are relying on this field for QoS purposes, where the configuration requires circuits to be configured with a speed lower thah the interface speed.
I agree the naming is somewhat confusing, but hope we can keep this functionality.
Would renaming to Egress and Ingress speed be better?

@arjenvri commented on GitHub (Mar 2, 2021): We are relying on this field for QoS purposes, where the configuration requires circuits to be configured with a speed lower thah the interface speed. I agree the naming is somewhat confusing, but hope we can keep this functionality. Would renaming to Egress and Ingress speed be better?
adam commented 2025-12-29 18:38:15 +01:00
Author
Owner
Copy Link

@phurrelmann commented on GitHub (Mar 2, 2021):

This is commonly used to model asymmetric DSL or FTTH circuits. E.g. the physical interface is 1G but the circuit speeds are sth. like 100/40 or 500/100.

@phurrelmann commented on GitHub (Mar 2, 2021): This is commonly used to model asymmetric DSL or FTTH circuits. E.g. the physical interface is 1G but the circuit speeds are sth. like 100/40 or 500/100.
adam commented 2025-12-29 18:38:15 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Mar 2, 2021):

We use it (the port speed) for DSL based circuits as well. We have cases were the L1 speed of A- and Z-termination (up vs downstream) are bigger then the commit of the circuit.

To be honest in our use case the fields are abused according to the 'SoT way of thinking'. This is because we sync these L1 speeds based on the actual trained speed as reported by the DSL interface of the CPE, which we manage as a ServiceProvider. We should have these 'cached device facts' in some sort of TSDB instead to clearly distinct 'desired' (netbox) vs 'actual' (fancy tsdb cache product X) state.

@sdktr commented on GitHub (Mar 2, 2021): We use it (the port speed) for DSL based circuits as well. We have cases were the L1 speed of A- and Z-termination (up vs downstream) are bigger then the commit of the circuit. To be honest in our use case the fields are abused according to the 'SoT way of thinking'. This is because we sync these L1 speeds based on the actual trained speed as reported by the DSL interface of the CPE, which we manage as a ServiceProvider. We should have these 'cached device facts' in some sort of TSDB instead to clearly distinct 'desired' (netbox) vs 'actual' (fancy tsdb cache product X) state.
adam commented 2025-12-29 18:38:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 3, 2021):

Alright, seems like these fields are still in use then. An argument could be made to rename them, but I don't think it's strong enough to justify a breaking change. Appreciate the feedback!

@jeremystretch commented on GitHub (Mar 3, 2021): Alright, seems like these fields are still in use then. An argument could be made to rename them, but I don't think it's strong enough to justify a breaking change. Appreciate the feedback!
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 type: deprecation
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#4610
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?