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

Remove the dedicated views and REST API endpoints for console/power/interface connections #5223

Closed
jeremystretch opened this issue Oct 8, 2020 · 4 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: deprecation Removal of existing functionality or behavior
Milestone

Comments

@jeremystretch
Copy link
Member

Proposed Changes

NetBox currently has dedicated view and REST API endpoints for listing console, power, and interface connections. This proposal seeks to remove these completely, and merge their functionality into the new views and endpoints dedicated to each model.

Justification

The connection lists, being necessarily decoupled somewhat from their related models, don't offer as much flexibility with regard to ordering, filtering, etc. They are also limited, for instance, in that the power connections list will not display connections from power ports to power feeds.

Attaching connection information to the individual component lists should fully replicate their existing functionality. The only caveat is the interface connections list, which applies filtering to avoid showing both directions of a connection between interfaces. However, we should be able to replicate this by adding a boolean filter to the interfaces list.

@jeremystretch jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation type: deprecation Removal of existing functionality or behavior status: blocked Another issue or external requirement is preventing implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Oct 8, 2020
@jeremystretch
Copy link
Member Author

Blocked by #4999

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: blocked Another issue or external requirement is preventing implementation labels Oct 30, 2020
@jeremystretch jeremystretch added status: blocked Another issue or external requirement is preventing implementation and removed status: accepted This issue has been accepted for implementation labels Oct 30, 2020
@jeremystretch jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation and removed status: blocked Another issue or external requirement is preventing implementation labels Mar 29, 2021
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Apr 13, 2021
@jeremystretch jeremystretch added this to the v2.12 milestone Apr 13, 2021
@ryanmerolle
Copy link
Contributor

No objections here if views can replicate "similarish" sort of output.

@minitriga
Copy link
Contributor

As long as we can get the data for console, power and interface connections via other API calls that should be fine.

@jeremystretch jeremystretch self-assigned this Jul 8, 2021
@jeremystretch
Copy link
Member Author

I'm going to remove the REST API endpoints for these connections since they're largely redundant, but leave the UI views in place as I can see how having them separate from the component views is convenient. Maybe we'll revisit the UI views once we have a more robust mechanism around table preferences in place (to remember/re-apply saved configurations).

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 7, 2021
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: deprecation Removal of existing functionality or behavior
Projects
None yet
Development

No branches or pull requests

3 participants