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

Keystone passthrough type #2538

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

Originally created by @jermudgeon on GitHub (Apr 21, 2019).

Environment

  • Python version: 3.6
  • NetBox version: 2.5.10

Proposed Functionality

I can create a 24-port passthrough patch bay, but not of the modular keystone variety. Netbox could benefit from this port type, with modular membership, as each port's module can be of a different type — 8P8C in both shielded and unshielded varieties, and many other types in AV environments.

Use Case

It's important to know which slots are empty, and what type of module fills slots that are full. My primary use case is modular 8P8C, but I also use empty slots as a literal cable passthrough.

Database Changes

Not known.

External Dependencies

None.

Originally created by @jermudgeon on GitHub (Apr 21, 2019). ### Environment * Python version: 3.6 * NetBox version: 2.5.10 ### Proposed Functionality I can create a 24-port passthrough patch bay, but not of the modular keystone variety. Netbox could benefit from this port type, with modular membership, as each port's module can be of a different type — 8P8C in both shielded and unshielded varieties, and many other types in AV environments. ### Use Case It's important to know which slots are empty, and what type of module fills slots that are full. My primary use case is modular 8P8C, but I also use empty slots as a literal cable passthrough. ### Database Changes Not known. ### External Dependencies None.
adam closed this issue 2025-12-29 18:19:46 +01:00
adam commented 2025-12-29 18:19:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2019):

NetBox doesn't track any additional characteristics of the pass-through port itself, only the actual termination types. It being a Keystone modular versus doesn't have any bearing on the termination type, so it wouldn't make sense to add this as a different termination type. I personally don't see much value in denoting modular versus fixed ports (via the introduction of a new field) but I'll leave this open for discussion.

@jeremystretch commented on GitHub (Apr 22, 2019): NetBox doesn't track any additional characteristics of the pass-through port itself, only the actual termination types. It being a Keystone modular versus doesn't have any bearing on the termination type, so it wouldn't make sense to add this as a different termination type. I personally don't see much value in denoting modular versus fixed ports (via the introduction of a new field) but I'll leave this open for discussion.
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jermudgeon commented on GitHub (Apr 22, 2019):

I'm not sure I need a new field. I note that I am not allowed to leave a port type blank on, say, a front port; am I missing something obvious about the passthrough idea? Currently, my options for new port types are Console Ports, Console Server Ports, Power Ports, Power Outlets, Interfaces, Front Ports, Rear Ports, and Device Bays.

@jermudgeon commented on GitHub (Apr 22, 2019): I'm not sure I need a new field. I note that I am not allowed to leave a port type blank on, say, a front port; am I missing something obvious about the passthrough idea? Currently, my options for new port types are Console Ports, Console Server Ports, Power Ports, Power Outlets, Interfaces, Front Ports, Rear Ports, and Device Bays.
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2019):

There are only two pass-through port types in NetBox: front and rear. The others are different types of device components with different purposes. Only pass-through ports would be used to model patch panel ports.

It's important to know which slots are empty, and what type of module fills slots that are full.

Only create ports for the ports that actually exist. If you have device of type "24-port Keystone Panel" but only have ports 1-12 created, for example, you know that 13-24 are empty.

@jeremystretch commented on GitHub (Apr 22, 2019): There are only two pass-through port types in NetBox: _front_ and _rear_. The others are different types of device components with different purposes. Only pass-through ports would be used to model patch panel ports. > It's important to know which slots are empty, and what type of module fills slots that are full. Only create ports for the ports that actually exist. If you have device of type "24-port Keystone Panel" but only have ports 1-12 created, for example, you know that 13-24 are empty.
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jermudgeon commented on GitHub (Apr 22, 2019):

I considered creating ports for only the modules that exist, as you
suggested. However, part of the purpose of tracking these patch panels at
all in netbox is to be able to run reports. If I can't differentiate
between an empty port and a nonexistent port, the reporting is of less
utility. It's fine for visual inspection of a device, so not entirely
without merit; but not a scalable solution. I'd have to overload a port
component with some other meaning, as I can't choose "empty" as the
sub-component of a front or rear port.

On Mon, Apr 22, 2019 at 3:26 AM Jeremy Stretch notifications@github.com
wrote:

There are only two pass-through port types in NetBox: front and rear.
The others are different types of device components with different
purposes. Only pass-through ports would be used to model patch panel ports.

It's important to know which slots are empty, and what type of module
fills slots that are full.

Only create ports for the ports that actually exist. If you have device of
type "24-port Keystone Panel" but only have ports 1-12 created, for
example, you know that 13-24 are empty.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/3096#issuecomment-485396173,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACEPLEZCGZ57WQYXHZR56HDPRWOFDANCNFSM4HHKSFDA
.

--
Jeremy Austin
jhaustin@gmail.com

(907) 895-2311 office
(907) 803-5422 cell

@jermudgeon commented on GitHub (Apr 22, 2019): I considered creating ports for only the modules that exist, as you suggested. However, part of the purpose of tracking these patch panels at all in netbox is to be able to run reports. If I can't differentiate between an empty port and a nonexistent port, the reporting is of less utility. It's fine for visual inspection of a device, so not entirely without merit; but not a scalable solution. I'd have to overload a port component with some other meaning, as I can't choose "empty" as the sub-component of a front or rear port. On Mon, Apr 22, 2019 at 3:26 AM Jeremy Stretch <notifications@github.com> wrote: > There are only two pass-through port types in NetBox: *front* and *rear*. > The others are different types of device components with different > purposes. Only pass-through ports would be used to model patch panel ports. > > It's important to know which slots are empty, and what type of module > fills slots that are full. > > Only create ports for the ports that actually exist. If you have device of > type "24-port Keystone Panel" but only have ports 1-12 created, for > example, you know that 13-24 are empty. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/digitalocean/netbox/issues/3096#issuecomment-485396173>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACEPLEZCGZ57WQYXHZR56HDPRWOFDANCNFSM4HHKSFDA> > . > -- Jeremy Austin jhaustin@gmail.com (907) 895-2311 office (907) 803-5422 cell
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2019):

If I can't differentiate between an empty port and a nonexistent port

The device type dictates whether the panel will accommodate a port (e.g. 24- vs. 48-port panels).

@jeremystretch commented on GitHub (Apr 22, 2019): > If I can't differentiate between an empty port and a nonexistent port The device type dictates whether the panel will accommodate a port (e.g. 24- vs. 48-port panels).
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jermudgeon commented on GitHub (Apr 23, 2019):

Is it possible to query a device instantiation against its type?

@jermudgeon commented on GitHub (Apr 23, 2019): Is it possible to query a device instantiation against its type?
adam commented 2025-12-29 18:19:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2019):

You can filter devices by type if that's what you mean, using ?device_type_id=<id>. Let's move to the mailing list for any further discussion.

@jeremystretch commented on GitHub (May 2, 2019): You can filter devices by type if that's what you mean, using `?device_type_id=<id>`. Let's move to the mailing list for any further discussion.
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
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#2538
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?