Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface Bridges in Device Type #8272

Closed
PaulR282 opened this issue Jan 7, 2022 · 2 comments
Closed

Interface Bridges in Device Type #8272

PaulR282 opened this issue Jan 7, 2022 · 2 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@PaulR282
Copy link

PaulR282 commented Jan 7, 2022

NetBox version

v3.1.4

Feature type

Change to existing functionality

Proposed functionality

Currently you can only bridge interfaces if the device already exists. It would be nice to "pre-bridge" interfaces in the device Type.

Use case

When you have devices like mediaconverter, currently you have to manually bridge the 2 interfaces after creating the device for every single device. It would be a lot easier to bridge the interfaces in the device type.

Database changes

No response

External dependencies

No response

@PaulR282 PaulR282 added the type: feature Introduction of new functionality to the application label Jan 7, 2022
@DanSheps DanSheps added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Jan 7, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Mar 9, 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. Please see our contributing guide.

@github-actions github-actions bot added the pending closure Requires immediate attention to avoid being closed for inactivity label Mar 9, 2022
@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation pending closure Requires immediate attention to avoid being closed for inactivity labels Apr 4, 2022
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed needs milestone Awaiting prioritization for inclusion with a future NetBox release labels Jan 5, 2023
@jeremystretch jeremystretch added this to the v3.5 milestone Jan 5, 2023
@sleepinggenius2
Copy link
Contributor

Just wanted to add that it would be nice to be able to do the same for Parent interface and LAG interface. I've run into both situations recently. On our aggregation switches, we create a LAG for the uplink and it would certainly save a step to have that already set up in the device template. The bigger issue I had recently was with the parent/child relationship, as we have some devices with bulk connectors that we currently model as a physical connector with virtual child interfaces under it and it's cumbersome having to remember to create those relationships each time a new device is added. Please let me know if I need to open a separate FR or if it's sufficient to update this one to include all the interface relationship types. I assume the implementation for one should be almost identical for the others, but maybe I'm missing something.

@kkthxbye-code kkthxbye-code self-assigned this Feb 22, 2023
jeremystretch added a commit that referenced this issue Mar 10, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

5 participants