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

Add Type and 'Service Parameter' fields to Virtual Circuits model #10541

New Issue
Closed
opened 2025-12-29 21:32:55 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:32:55 +01:00
Owner
Copy Link

Originally created by @samk-acw on GitHub (Dec 4, 2024).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.2-beta1

Feature type

Data model extension

Triage priority

N/A

Proposed functionality

Add the Install/Termination date and commit rate fields, which are currently on Circuits model, to the Virtual Circuit model.

Type would also be useful as in my case (ISP context) we have different types of virtual circuits, though it could be up for debate that type could be inferred from the Provider Network. For simplicity's sake I would propose Virtual Circuits be able to use the same types as regular Circuits.

Use case

These fields are relevant to virtual circuits, not just physical ones

Database changes

add install date, terminate date, commit rate, and type fields to Virtual Circuit model

External dependencies

No response

Originally created by @samk-acw on GitHub (Dec 4, 2024). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.2-beta1 ### Feature type Data model extension ### Triage priority N/A ### Proposed functionality Add the Install/Termination date and commit rate fields, which are currently on Circuits model, to the Virtual Circuit model. Type would also be useful as in my case (ISP context) we have different types of virtual circuits, though it could be up for debate that type could be inferred from the Provider Network. For simplicity's sake I would propose Virtual Circuits be able to use the same types as regular Circuits. ### Use case These fields are relevant to virtual circuits, not just physical ones ### Database changes add install date, terminate date, commit rate, and type fields to Virtual Circuit model ### External dependencies _No response_
adam added the status: acceptedtype: featurecomplexity: mediumbeta labels 2025-12-29 21:32:55 +01:00
adam closed this issue 2025-12-29 21:32:55 +01:00
adam commented 2025-12-29 21:32:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 23, 2024):

For simplicity's sake I would propose Virtual Circuits be able to use the same types as regular Circuits.

This doesn't make sense IMO; I see very little, if any, overlap between physical & virtual circuit types. I'd rather see it implemented as a separate model, or maybe take an approach similar to what we do for device roles (where a role can optionally also apply to VMs).

@jeremystretch commented on GitHub (Dec 23, 2024): > For simplicity's sake I would propose Virtual Circuits be able to use the same types as regular Circuits. This doesn't make sense IMO; I see very little, if any, overlap between physical & virtual circuit types. I'd rather see it implemented as a separate model, or maybe take an approach similar to what we do for device roles (where a role can optionally also apply to VMs).
adam commented 2025-12-29 21:32:56 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Dec 30, 2024):

I would vote for the separate model. The way device roles are done today has always been a little clunky, as there is no way to make a role available to only VMs and not devices, so we have a number of roles that start with "VM - " clogging up the role dropdown on devices and a custom validator to make sure someone doesn't accidentally pick one. I agree that there should be almost no overlap between the types, ex. EPL would only be for physical and EVPL would only be for virtual.

The other "Service Parameters" fields from the Circuit model are critical to be on the Virtual Circuit model as well, as establishing a new OVC almost always has different dates and rate compared to the underlying ENNI.

@sleepinggenius2 commented on GitHub (Dec 30, 2024): I would vote for the separate model. The way device roles are done today has always been a little clunky, as there is no way to make a role available to only VMs and not devices, so we have a number of roles that start with "VM - " clogging up the role dropdown on devices and a custom validator to make sure someone doesn't accidentally pick one. I agree that there should be almost no overlap between the types, ex. EPL would only be for physical and EVPL would only be for virtual. The other "Service Parameters" fields from the Circuit model are critical to be on the Virtual Circuit model as well, as establishing a new OVC almost always has different dates and rate compared to the underlying ENNI.
adam commented 2025-12-29 21:32:56 +01:00
Author
Owner
Copy Link

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

I've enabled the assignment of circuit types (via the introduction of a new dedicated model) in PR #18300, but have not addressed any of the other proposed fields. If anyone would like to propose detailed use cases for these fields relating to virtual circuits, please do so in a new feature request.

@jeremystretch commented on GitHub (Jan 6, 2025): I've enabled the assignment of circuit types (via the introduction of a new dedicated model) in PR #18300, but have not addressed any of the other proposed fields. If anyone would like to propose detailed use cases for these fields relating to virtual circuits, please do so in a new feature request.
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 beta complexity: medium status: accepted 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#10541
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?