-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
API call shows termination_z["connected_endpoint"] of null when the connected endpoint exists. #4925
Comments
Thank you for the thorough bug report! I'm going to use this as an example from now on. 😄 This hits on an issue that I feel like we've been chasing for a long time: When do we consider a circuit part of the path? Here's what's happening:
This is valid in a scenario where a circuit has only one termination defined (e.g. to model an Internet access circuit, where the far end is unknown).
You can confirm this by viewing the interface on ATL-RT01: it shows the opposite interface as its connected endpoint (and vice versa). This is why termination Z doesn't have its What we end up with is one complete path and one partial path:
So, there are two issues here. First, the one-way end-to-end path above is a bug no matter how you look at it, and needs to be resolved. The second issue is determining and documenting the expected behavior for this scenario. There are (at least) two choices: Choice A: Establish two separate paths, each from a circuit termination to its connected interface. Choice B: Establish a path only across circuit terminations, and never to them. (Essentially, treat them like front/rear pass-through ports.) I believe this is the root issue for which #4812 was opened (currently a work in progress). #4519 also touches on this issue, though in a different context. All of these will need to be considered in parallel to make a decision. |
Choice A isn't currently possible because there may be a rear port with multiple front ports connected to the circuit termination. In that case there may be many interfaces whose path traverses the circuit. The path from the circuit termination can only go as far as the rear port. At that point the paths split. A possible solution for that scenario is to store the rear port as the connected endpoint for the circuit termination. Something to think about. |
Hopefully temporary until upstream issues are fixed see also: netbox-community/netbox#4812 netbox-community/netbox#4925 Change-Id: I4e5d7d0fcbee3f71e500880c0cfbfc12efe4992a
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. |
Blocked by #4900 (due to be implemented in v2.10) |
This has been addressed under #4900. |
Environment
Steps to Reproduce
http://localhost:8000/circuits/circuits/1/
null
, so I thought it the best way to describe the bug in this report.Expected Behavior
The UI shows a connected cable on the termination - Z side of the connection. I expected the API to also show this connected endpoint in the structure of a dictionary as the value of termination_z["connected_endpoint"] for the circuit returned from an API call.
Observed Behavior
The value of termination_z["connected_endpoint"] from the API call for the circuit in question has a value of "null" rather than a dictionary describing the connected endpoint.
The text was updated successfully, but these errors were encountered: