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

Allow to model / store circuit segments #6712

New Issue
Closed
opened 2025-12-29 19:44:23 +01:00 by adam · 9 comments
adam commented 2025-12-29 19:44:23 +01:00
Owner
Copy Link

Originally created by @BarbarossaTM on GitHub (Jul 25, 2022).

NetBox version

v3.2.7

Feature type

Data model extension

Proposed functionality

Storing circuit information in NetBox is great and provides a lot of value as of today! While thinking about storing Circuits of a large network into NetBox we came across one meta information of especially long haul circuits which might be interesting for a wider audience. I didn't find an issue similar to this idea yet, happy to close this as duplicate if that already exists.

Especially long haul, or even intercontinental circuits, often consists of multiple parts or segments which are chained together to provide the circuit service, being it a dark fiber, wavelength, etc. with a segment being a local-loop sub-contracted by another provider, a under sea cable or similar. Particularly for intercontinental circuits it would be beneficial to store the under sea cable this circuit is carried on to be able to asses the diversity of existing circuits and determine the blast radius if a maintenance is scheduled. The same is true for short circuits where you want to keep track of parts of the path lets say between Frankfurt and and Amsterdam and map that to some segments.

The idea is that segments can be freely created by the user and can mean anything from "under sea cable" to "left of the highway 42 between A and Z", so it's as generic as possible. It might be meaningful to add a Segment Type model as well to be able to differencialte between types of Segments.

Use case

Explained above :)

Database changes

This would introduce a new Segment or Circuit Segment model which I guess should be located within the Circuits section of the UI/API. The model would have a name and potentially slug and can have an n:m relationship with Circuits.

It might make sense to also add a Segment Type model to allow the user to model types of segments they care about, for example "under sea cables" or "path left of highway 42". This model would have a name and potentially slug and a 1:n relationship with Segments.

External dependencies

None

Originally created by @BarbarossaTM on GitHub (Jul 25, 2022). ### NetBox version v3.2.7 ### Feature type Data model extension ### Proposed functionality Storing circuit information in NetBox is great and provides a lot of value as of today! While thinking about storing Circuits of a large network into NetBox we came across one meta information of especially long haul circuits which might be interesting for a wider audience. I didn't find an issue similar to this idea yet, happy to close this as duplicate if that already exists. Especially long haul, or even intercontinental circuits, often consists of multiple parts or segments which are chained together to provide the circuit service, being it a dark fiber, wavelength, etc. with a segment being a local-loop sub-contracted by another provider, a under sea cable or similar. Particularly for intercontinental circuits it would be beneficial to store the under sea cable this circuit is carried on to be able to asses the diversity of existing circuits and determine the blast radius if a maintenance is scheduled. The same is true for short circuits where you want to keep track of parts of the path lets say between Frankfurt and and Amsterdam and map that to some segments. The idea is that segments can be freely created by the user and can mean anything from "under sea cable" to "left of the highway 42 between A and Z", so it's as generic as possible. It might be meaningful to add a Segment Type model as well to be able to differencialte between types of Segments. ### Use case Explained above :) ### Database changes This would introduce a new `Segment` or `Circuit Segment` model which I guess should be located within the Circuits section of the UI/API. The model would have a name and potentially slug and can have an n:m relationship with Circuits. It might make sense to also add a `Segment Type` model to allow the user to model types of segments they care about, for example "under sea cables" or "path left of highway 42". This model would have a name and potentially slug and a 1:n relationship with `Segments`. ### External dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:44:23 +01:00
adam closed this issue 2025-12-29 19:44:23 +01:00
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Jul 25, 2022):

If this is deemed useful I'm happy to work on a PR for this. :-)

@BarbarossaTM commented on GitHub (Jul 25, 2022): If this is deemed useful I'm happy to work on a PR for this. :-)
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Sep 13, 2022):

Ah, this is an interesting take on improving the modeling of the OSP parts of circuits. I see the value in this. At some point I'd like to think this through further and engage the community in a discussion for those of us that must manage or at least model, as you say, their OSP segments in greater details.

@eronlloyd commented on GitHub (Sep 13, 2022): Ah, this is an interesting take on improving the modeling of the OSP parts of circuits. I see the value in this. At some point I'd like to think this through further and engage the community in a discussion for those of us that must manage or at least model, as you say, their OSP segments in greater details.
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 13, 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 (Nov 13, 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:44:24 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Nov 13, 2022):

@jeremystretch Any thoughts on this? As stated before I'm happy to draft a PR for this :-)

@BarbarossaTM commented on GitHub (Nov 13, 2022): @jeremystretch Any thoughts on this? As stated before I'm happy to draft a PR for this :-)
adam commented 2025-12-29 19:44:24 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Dec 8, 2022):

@BarbarossaTM I'd say draft up a PR if you can to continue the conversation. From my perspective as a service provider, the large majority of circuits are nearly always handled as internal records between us and customer demarcs, so that gets completely modeled out.

If you're looking at a circuit as a connection into someone else's network, segments might not actually be as necessary, as I think about it. Perhaps if you can flesh out your concept in a PR it would help.

@eronlloyd commented on GitHub (Dec 8, 2022): @BarbarossaTM I'd say draft up a PR if you can to continue the conversation. From my perspective as a service provider, the large majority of circuits are nearly always handled as internal records between us and customer demarcs, so that gets completely modeled out. If you're looking at a circuit as a connection into someone else's network, segments might not actually be as necessary, as I think about it. Perhaps if you can flesh out your concept in a PR it would help.
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 29, 2022):

@BarbarossaTM I think the proposed implementation needs a lot more detail before a PR would be appropriate. You've made some high-level notes in the original FR above, but I'm still not clear on exactly how this is intended to operate. Perhaps a draft definition for the model classes would be the best place to start.

@jeremystretch commented on GitHub (Dec 29, 2022): @BarbarossaTM I think the proposed implementation needs a lot more detail before a PR would be appropriate. You've made some high-level notes in the original FR above, but I'm still not clear on exactly how this is intended to operate. Perhaps a draft definition for the model classes would be the best place to start.
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Feb 12, 2023):

Hey @jeremystretch I tried drawing up the idea as an ERM, does that make sense?

image

So a Circuit could be linked to n Segments, which each have a SegmentType assigned :-)

@BarbarossaTM commented on GitHub (Feb 12, 2023): Hey @jeremystretch I tried drawing up the idea as an ERM, does that make sense? ![image](https://user-images.githubusercontent.com/10324868/218319856-f2678d82-5f8f-4b0a-88c2-ec34a27987a4.png) So a Circuit could be linked to `n` `Segments`, which each have a `SegmentType` assigned :-)
adam commented 2025-12-29 19:44:25 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 14, 2023):

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 (May 14, 2023): 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:44:25 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 15, 2023):

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 15, 2023): 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 status: under review 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#6712
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?