Netbox: Virtual chassis members cables not showing up consistently

[XioNoX]

Environment

• Python version: 3.7.3
• NetBox version: 2.8.9

Steps to Reproduce

1. Create a virtual chassis
2. Add cables to virtual chassis members
3. List all cables connected to the VC master

Expected Behavior

All the cables connected to all the virtual chassis members to be listed. The same way listing interfaces on the VC master shows VC members interfaces.

Observed Behavior

Only some cables attached to the non master members are showing up.

The 3 virtual chassis members:

The cables showing up when filtering for the VC master, see that it lists cable 1132 on asw2-oe14 only.

But for example this one cable is not showing up:

I already tried to delete/re-create the cable with no success. The same issue is happening on the API. I'm wondering if it's related to issue #4812.

[jeremystretch]

1. Create a virtual chassis
2. Add cables to virtual chassis members
3. List all cables connected to the VC master

You're going to need to provide more detail than that. Please specify a list of specific, discrete actions that someone else can take to reproduce the reported behavior, beginning with the creation of the virtual chassis and including each cable that you create. This doesn't need to replicate your entire installation, but it does need to be sufficient to reliably reproduce the behavior on a clean installation of the latest stable release. Additionally, be sure to specify exactly what you expect to see and what is happening instead.

[paravoid]

Colleague of @XioNoX's here. I think I made some progress here :)

First of all, unless I missed something from the code (CableListView, CableFilterSet etc.), the cable view is not supposed to show all the interfaces of all members of a virtual chassis, when one is filtering with just the master. So, for example, for a virtual chassis that includes asw2-oe14-esams, asw2-oe15-esams, asw2-oe16-esams, with oe16 being the master, when one is filtering cables for "device = asw2-oe16-esams" (/dcim/cables/?device=asw2-oe16-esams) no interfaces attached to oe14/oe15 should show up. The issue mentioned above is that _some_ interfaces of oe14 show up, and others (e.g. of oe15) do not. But the bug is the former behavior, not the latter.

So, why interfaces that are not oe16's show up when filtering with device=oe16? It seems like the issue here is that the cable model has a couple of caching fields (used for filtering among other things), and their values are stale:

>>> smf297._termination_a_device; smf297.termination_a.device
<Device: asw2-oe16-esams>
<Device: asw2-oe14-esams>

This shouldn't happen, and it's unclear why this happened in the first place.

The cable's last changed shows as Oct 31, 2019. The introduction of these caching fields, the code to set them on Cable's save(), as well as the respective migration (0075_cable_devices.py) seem to all have been added with v2.6.6, released on Oct 10th, 2019 (d2ab41abfba04036603c3958226e23e992d38dcd). In our environment, we went directly from v2.6.3 to v2.7.4 in February 2020 (and later to subsequent versions), so either something went with the migration, or the information became stale sometime after February 2020, but without the cable's changelog/last update having been modified, which is... puzzling. Any ideas here?

Obviously the short-term "fix" for our environment is to re-run the cache_cable_devices() code from 0075_cable_devices.py to bring back cache coherence in our database. It'd be nice if the root cause was less of a mystery, to feel a bit more assured that this won't happen again though!

[jeremystretch]

As this appears to relate to the caching of cable terminations, I'm marking it as blocked by #4900, which is a v2.10 initiative. When the first beta for v2.10 is released, please see if you're able to reproduce the reported issue on it and share your findings here.

[jeremystretch]

@XioNoX @paravoid Please see if you're able to recreate the reported problem on the v2.10 beta release.

[jeremystretch]

This is likely resolved in the v2.10 release, so I'm going to close the issue. However, if anyone can provide detailed steps to reproduce the reported problem, please comment here and I'll re-open the issue.