Upgrade from 4.3.7 to 4.4.3: django.db.utils.ProgrammingError: constraint "dcim_platform_name" of relation "dcim_platform" does not exist #20583
-
|
We just attempted to upgrade our netbox-docker based 4.3.7 to 4.4.3 and during fist container start the netbox-1 container is reported "unhealthy" and while examining the logs there is a Django backtrace concerning a missing constraint. However, the netbox instance is up and seems OK and a subsequent restarts do not show any issues. Is this a cosmetical issue due to an unhandled exception or should we be worried and roll back? The exception in question is:
We are running a customised (as in with plugin build enabled) netbox-docker, although with a bare metal postgres-14 instead of a containerised one. This is the output from "docker compose logs" during first boot of 4.4.3: Having a look at the suspect relation in Postgres shows: Any input will be greatly appreciated! /Erik |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
I proceeded to educate myself on how to check this and did |
Beta Was this translation helpful? Give feedback.
-
|
I’m not using the containerized setup of NetBox myself, so I might be mistaken, but one thing stands out: why do you have a container named If you’re building the image yourself, I’d recommend:
Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
Spot on. I was definitely unnecessarily running the housekeeping container which was deprecated. I had rather religiously read the netbox release notes and completely ignored the release notes for netbox-docker. Should I be able to trust what |
Beta Was this translation helpful? Give feedback.
Thanks for the follow‑up.
Should you trust
python manage.py showmigrations?Short answer: mostly yes, with caveats. Django records applied migrations in the
django_migrationstable, andshowmigrationsreflects that history for the database your command is connected to. If it reports everything as applied, that’s what Django will act on. However, it does not validate the live schema.Given the uncertainty - and the fact that the deprecated
housekeepingservice was previously running - I agree with your instinct: restore from your pre‑upgrade backup and redo the upgrade cleanly. It’s the safest way to ensure a consistent and supported state.