Replies: 2 comments 8 replies
-
|
Looks like a caching problem.
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry, not helped at all. Still getting same error. There is need a lot of debugging, which i not familiar with |
Beta Was this translation helpful? Give feedback.
-
|
Did you try with 2.10.10? Can you show the backtrace from that please? Can you also try explicitly flushing the cache: and then run |
Beta Was this translation helpful? Give feedback.
-
|
yes. there is exactly same traceback |
Beta Was this translation helpful? Give feedback.
-
|
It seems to be accessing an attribute ".cable" that doesn't exist (an attribute of what object though, I don't know) As a band-aid, find this code in and try replacing the last two lines shown above with: (you're indenting the existing lines by 4 spaces, then adding the "try:" above and three lines below. Alignment is important.) If this works, it will log some "OOPS" messages and carry on - please can you post the content of those messages. |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing the same thing. (I'm not sure how to comment w/o answering.) I started to write an issue, but I can only reproduce it using my database backup, so I can't reproduce it per the 🐛 Bug Report issue template. Configuration:
When I bring up the new version. I see this in the I even completely wiped out my Redis volume to ensure there were no lingering cache elements. This error seems to be likely related to this, which I had wrestled with previously: #6945. Note that the suggestion to disable caching did not have any effect for me. (My comment about wiping out the Redis data seems to confirm that this is not a caching problem.) @jeremystretch Can you suggest any queries to run or additional debugging steps? I feel like a bug (either previous or unknown) has left some records in the DB in a partially-broken state. |
Beta Was this translation helpful? Give feedback.
-
|
I tracked this down in the netbox shell using the It looks like I have an >>> o = Interface.objects.filter(cable__isnull=False).filter(_path__isnull=True)[0]
>>> o
<Interface: GigabitEthernet1/0/24>
>>> o.id
86
>>> o.cable_id
83
>>> o.cable
Traceback (most recent call last):
File "/opt/netbox/venv/lib/python3.9/site-packages/django/db/models/fields/related_descriptors.py", line 173, in __get__
rel_obj = self.field.get_cached_value(instance)
File "/opt/netbox/venv/lib/python3.9/site-packages/django/db/models/fields/mixins.py", line 15, in get_cached_value
return instance._state.fields_cache[cache_name]
KeyError: 'cable'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/opt/netbox/venv/lib/python3.9/site-packages/django/db/models/fields/related_descriptors.py", line 187, in __get__
rel_obj = self.get_object(instance)
File "/opt/netbox/venv/lib/python3.9/site-packages/django/db/models/fields/related_descriptors.py", line 154, in get_object
return qs.get(self.field.get_reverse_related_filter(instance))
File "/opt/netbox/venv/lib/python3.9/site-packages/django/db/models/query.py", line 435, in get
raise self.model.DoesNotExist(
dcim.models.cables.Cable.DoesNotExist: Cable matching query does not exist.When I look at that interface in the web UI (
I was able to "fix" the problem by setting >>> o.cable_id=None
>>> o.cable
>>> o.save()Now I was able to trace cable paths (and even forced a full retrace to be sure): [root@docker2 netbox-docker]# ./manage.sh trace_paths
🧬 loaded config '/etc/netbox/config/configuration.py'
🧬 loaded config '/etc/netbox/config/extra.py'
🧬 loaded config '/etc/netbox/config/logging.py'
🧬 loaded config '/etc/netbox/config/plugins.py'
Found no missing console port paths; skipping
Found no missing console server port paths; skipping
Found no missing interface paths; skipping
Found no missing power feed paths; skipping
Found no missing power outlet paths; skipping
Found no missing power port paths; skipping
Finished.[root@docker2 netbox-docker]# ./manage.sh trace_paths --force
🧬 loaded config '/etc/netbox/config/configuration.py'
🧬 loaded config '/etc/netbox/config/extra.py'
🧬 loaded config '/etc/netbox/config/logging.py'
🧬 loaded config '/etc/netbox/config/plugins.py'
WARNING: Forcing recalculation of all cable paths.
This will delete and recalculate all 68 existing cable paths. Are you sure?
Type yes to confirm: yes
Deleting 68 existing cable paths...
Deleted 68 paths
Resetting database sequence for CablePath model
Found no missing console port paths; skipping
Found no missing console server port paths; skipping
Retracing 66 cabled interfaces...
[####################] 100%
Retraced 66 interfaces
Found no missing power feed paths; skipping
Retracing 1 cabled power outlets...
[####################] 100%
Retraced 1 power outlets
Retracing 1 cabled power ports...
[####################] 100%
Retraced 1 power ports
Finished.Again, I have no idea how this happens, but there must have been some missed corner case at some point. |
Beta Was this translation helpful? Give feedback.
-
Now that you say that, I remember that someone else had a similar problem: #8166 It seems some systems have missing foreign key constraint(s) which would have maintained this invariant. Once they've drifted, further Django schema migrations don't correct that drift. Reproducing this issue would be painful: it would involve installing old versions of Netbox and migrating them to new ones, until you find out what sequence caused the broken migrations. And then writing a correcting migration. |
Beta Was this translation helpful? Give feedback.
-
|
My path wasn't particularly long or complicated. My
I know this particular interface was played with a lot; it was connected to a circuit, and then moved to a front panel port on the dmarc where the back panel port was then connected to the circuit, and probably other iterations I can't remember. The changelog on the interface isn't helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting idea: someone can write a script to go through a sequence of docker installs and upgrades against the same postgres database, and then identify the minimum set of changes which introduce the problem. I think it could also be done with a sequence of "git checkout vX.X.X" commands with the appropriate migrate command; although in theory the venv needs updating at each step, it might be OK with one common one. One problem I've found before is that Netbox doesn't pin its dependencies (no "pip freeze"): these days you can get failures to install old versions of Netbox, because it pulls in new versions of dependencies which are incompatible. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
NetBox version
2.10.0
Python version
3.6
Steps to Reproduce
Expected Behavior
upgrade complete successfully
Observed Behavior
Beta Was this translation helpful? Give feedback.
All reactions